I am looking forward to using Cloudinary for my present project. And cloudinary recently added proper support for videos, which is god-send.
I am a little confused about the bandwidth limit:
Will the net bandwidth limit imposed by Cloudinary be effected by the uploading of content (image/videos)? Or is it only applicable while I view (download) them?
Also, does Cloudinary charge the developer for automatic transcoding of videos?
Cloudinary only charges bandwidth for downloading content from your account.
Regarding video transformations, Cloudinary charges for each newly transformed video according to the following policy:
For SD videos every second equals 2 transformations,
While for HD videos it equals as 4.
Related
I am developing an Video-on-demand mobile application. Videos are converted using AWS Elastic media converter and stored in S3 bucket. It will be streamed using Cloudfront.
The problem I'm facing is to stream the video on different quality(720p,360p..)
If user has less data then they wish to watch video in low quality. So how to change the video quality manually ?
You can combine the solution with Lambda#Edge and request the video resolution via GET parameters in this manner (copied from AWS Blog):
Read More here .
As you stated that you need multiple resolution videos so user can switch the quality based on their internet connection and you are using AWS media convert.
You need to convert the multiple resolution videos first using the trascoding services that you are using AWS then need to pass these multiple resolution files on media player so it will show the quality section features.let me know if you need more clarification or help on that.
If I was to embed a short video into a webpage of a website, but the actual video itself resided on a 3rd party server, would the website that has the embedded code use a small amount of its allocated bandwidth to play the video (because the video is actually located on another server) or would it use a larger amount of allocated bandwidth because you are still effectively watching the video through that website?
The only bandwidth required by the viewed webpage would be whatever code is being used to direct the browser viewing that webpage to the third party.
For example if you embed a youtube video on your webpage all your server send the browser viewing the webpage is your html file.
All the actual video and video player data is either browser side or on the part of the third party.
Tl;Dr
no bandwidth used to play the video, negligible amount of bandwidth used to send the extra line of html to tell the browser to play it.
Facebook appears to have changed its video upload policies recently. Can anyone advise where this might be documented?
I've got a FB app that publishes two types of videos to a FB page from a museum exhibition. One of these types - recorded on iPods - are still publishing fine. The other, server generated video from a single image and recorded audio is not being accepted this month but was working last month.
I've ruled out software errors - the files in question are no longer accepted via manual upload.
The spec of the videos being rejected are
H.264, 512 × 512, Millions
AAC, Mono, 44.100 kHz
FPS 15 or 30
Any suggestions? The spec is identical to files that are accepted so my hunch is that FB has changed some policy and disallowing video that does not contain any moving image to cut out audio copyright infringements. In this instance, the audio is all legally collected, there is no information provided on why the files are being rejected and we can't find any stated guideline or policy that would justify why this is happneing.
Any advice?
The accepted video types are listed here:
https://developers.facebook.com/docs/graph-api/reference/v2.2/user/videos/#publish
Check if your video matches the specs.
I have an app that is playing archived *.mov files from a server. Some of them are longer than 10 minutes. Is this ok? Can anyone point me to the guidelines for playing video?
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/UsingHTTPLiveStreaming/UsingHTTPLiveStreaming.html#//apple_ref/doc/uid/TP40008332-CH102-SW5
Requirements for Apps
If your app delivers video over cellular networks, and the video exceeds either 10 minutes duration or 5 MB of data in a five minute period, you are required to use HTTP Live Streaming. (Progressive download may be used for smaller clips.)
If your app uses HTTP Live Streaming over cellular networks, you are required to provide at least one stream at 64 Kbps or lower bandwidth (the low-bandwidth stream may be audio-only or audio with a still image).
These requirements apply to iOS apps submitted for distribution in the App Store for use on Apple products. Non-compliant apps may be rejected or removed, at the discretion of Apple.
Apache webserver setup
added:
AddType application/x-mpegURL .m3u8
AddType video/MP2T .ts
to "httpd.conf" file.
Movie file preparation
I have 3 movie files (9mb - 25mb each).
Used QuickTime to convert movies into iPhone format.
Used mediafilesegmenter to convert .m4v into 10-second segments of .ts files, with an accompanying .m3u8 file.
Placed these in a folder on webserver.
iPhone App implementation
Created UIWebView whose URL points to http://71.190.235.29/~yujean/stream.html
Simulator accesses the site and streams the movie-files just fine.
Question
Will I still get rejected by apple for bandwidth issues over the 3G and/or Edge network?
Do I need to somehow check which network the end-user is on first? And then provide a different movie accordingly? If so, how do I do that ...?
Thank you in advance,
Eugene
We were rejected when we first submitted our mp3 streamer to the app store for excessive bandwidth use. Then we hobbled the app to limit its downloads to 4.5 meg in 5 min, which was accepted by Apple.
You can review that thread for more info on the issue.
To answer your second bullet-point first, the SDK does that all for you. Determining what quality to stream is not the concern of the developer.
To answer your first bullet-point, I haven't submitted my Live Streaming app so I don't know for sure, but I believe you will be rejected if you don't have a 64k stream. To be sure, check out Requirements for Apps, which is as definitive a list of requirements that you could probably get.