I've authored some 4k videos and to my surprise it seems that Adobe Media Encoder won't let me export using various common formats at 4k resolutions.
For example mpeg2 won't go above HD 1920 resolution if you manually try to change the video size parameters. A little reading online seems to indicate this may be a technical limitation of the file format rather than anything specific with the AME software. I won't post links here as this was just talk on forums.
I then tried the same thing with AVI's and had the same issue of not being allowed to enter a resolution this high.
Is it really the case that formats such as mpeg2 and avi have some basic limitation that means they can't support resolutions as high as 4k ?
I've been using mp4 so far as an output format but just wondered if I should be aware of other formats that have this technical limitation and are not going to work.
The MPEG2 standard does not specify an encoding level for video at 4k resolution.
You can see a summary of what's available here:
https://en.wikipedia.org/wiki/H.262/MPEG-2_Part_2#Video_profiles_and_levels
Related
I have a Roku app and some of the videos come from Youtube. I have no problem retrieving the videos but if I select a video with HD it wants to automatically stream the Dash version. I can prevent Dash if I force a non HD version but who wants to watch a SD version..
SO I am wondering is there any way to force the mp4 stream opposed to a Dash stream?
I have read that XP does not play Dash and so I tried using Windows NT 5.1 as the user-agent but that did not work.
Any help would be greatly appreciated.
DASH and MP4 are not mutually exclusive - they perform different functions in the video delivery.
In simple terms you can view it like this:
Camera captures frames - 'raw video'
The 'raw video' is encoded in some way to store it, generally in a way that balances video size vs the quality. The video is then sometimes refereed to by the encoder used (the codec) - for example if a h.264 codec is used the video may be called a h.264 video.
The video stream, i.e. all the individual frames that make up the video, is packaged into a container. This container may contain video and audio streams, and it may even have multiple video streams. The video is then often referred to by the container format - for example if our h.264 encoded video above is packaged into an MP4 container it is often referred to as an MP4 video, even though the MP4 'container' may contain several video and audio tracks.
To improve the quality of video streaming, a video may also use a streaming protocol like MPEG DASH. The theory here is simple: multiple copies of the video are created with different bit rates, and hence different size and quality. Each of these copies is broken up into, for example, 10 second chunks. An index file is created, called a manifest, and a pointer to each video and audio stream is included. A client playing the video, for example a browser, requests each 10 second chunk as it needs it. It chooses which copy of the video it selects the next chunk from depending on the current network conditions. This means if the network is good it can switch to higher quality copy for the next chunk and if there is a problem it can switch down to a lower quality chunk. If we take our example video encoded by h.264 and put into a MP4 container, we can now package it using DASH streaming format. A video packaged like this is often referred to as a DASH video.
The above is a simplified overview, but it hopefully highlights that your videos may be actually MP4 and DASH, and in fact commonly are.
As an additional note, different devices may support different codecs (and even codec profiles), packaging formats and streaming formats - for example iOS devices tend to support HLS rather than DASH at the time of writing. This changes frequently as devices and standards evolve and is one of the reasons it can be tricky to find a single format that will play on all devices and clients - for this reason servers often will provide the same video in multiple codec and streaming formats to support as many devices and clients as possible.
I am developing an app and I am quite hesitant on allowing my users to share videos.
Mainly due the space that videos can take up in the server which adds a huge maintainance cost.
I have been reading around and I can see that there are lots of different libraries that allow me to compress video on iOS to make it easy to share.
After much researching I couldn't find any estimate on file size / second after compressed.)
I was wondering if anyone could share their experience with what file size / second I could expect with your preferred library in a video quality setting that is reasonable for mobile (I guess medium).
Based on the 2 following URL, you should be able to do what you want:
I suppose that you plan to use H264, and as the video is the major issue, First look at the following to choose the resolution & fps and the recommended bit-rate.
http://www.billhung.net/single_pages/video.encoding.resolution.vs.bitrate.by.experience.html#mozTocId728778
After follow the formula describe in:
Video bitrate and file size calculation
to compute the file size based on the maximum video duration you choose.
I've got an app that enables end-users to upload their audio files. Mostly songs/music. Currently, I am using Zencoder for my encoding service, which allows .mp3, .m4a, .mp4 or .ogg
When a user uploads an audio file, it will be available for other users to listen too via the app as well. Would the mp3 format be suitable enough for this?
The licensing should be a major concern here. mp3 has some interesting licensing conditions based on whether your service is free to the end-user. Too complicated to go into length here, you can look it up on the web or contact Frauenhofer for more details.
The second obvious concern is bandwidth and audio quality. The sampling has to be high enough that the end-user cannot tell the audio has been limited or compressed, but the file still needs to be small enough that the file can be downloaded or streamed quickly. Any broadband connection these days can handle a 320kbps mp3 fairly easily.
Hopefully this will give you some good starting points for research:
wikipedia:Comparison_of_audio_formats
mp3 would suffice, mp4 would be better as it offers improved sound quality and compression over mp3. Ogg is a good format but has less broad support on players.
To state the obvious, the quality of the sound is very much dependent on the original file uploaded by the user. You will never improve on that quality, and each time you transcode between formats, you will degrade the quality.
If you ask people to compare between mp3, AAC (m4a, mp4) and ogg - they will give you different answers. Different codecs with different bit rates produce different audio print. Some claim that for certain specific music types you should prefer one format over another.
You can google different bit rates and comparisons easily - technical part is easy.
I would go for ogg. Here's why:
1) It's easily good enough for the job
2) It's an Open Source
3) You don't get into trouble (legally) using it together with upload encodings.
I want to find out if I can get some data on the percentage wise distribution of video content, for different video codecs currently used for video encoding. I know there are different applications/use-case scenarios which have different encoder used but i want to consdier all that and have a overall usage number(%)
My guess is(highest to lowest % of content) -
H.264(AVC)
DivX
MPEG2
VP6
Where do H.263, MPEG4, VC-1, RV, Theora, etc. fit in here.
How may this look like in future?
PS:I would like this to be community wiki to have get wider range of inputs, if someone with privileges can do it for me please.
thank you.
-AD
I am guessing that WebM format (which is actually VP8) which is part of the WebM Project will see a rise since YouTube is encoding all of the videos in WebM format as an alternative.
I vote for WebM as a better quality and freer alternative to H.264
I'm putting together a site that will include some instructional videos that will be 1 to 3 minutes long. The users will be accessing these through standard and mobile browsers. I'm particularly concerned with users of i-devices, such as iPhone/iPod Touch/iPad.
To deliver the videos, I'm will probably use videojs.com player - it seems like a pretty robust choice. Unfortunately, I don't know first thing about what file formats and standards to use for encoding files. H.264 Baseline profile seems to be a good choice, but I really need some direction on where to read up on what might be the best choice.
Please help :)
The best resource I've found for this information is Dive Into HTML 5. They have a very concise breakdown of which formats will work with each of the browsers.
The long and short of it, however, is that h264 baseline is the way to go, especially if your HTML5 video player has Flash failover.
While HTML5 video is currently the standard in the mobile space, a back of the envelope calculation reveals that only about 40% of desktop browsers users can view it as compared to Flash's 99%+ market penetration. Moreover, you'd have to encode and store your videos twice (h264 and Theora) in order to reach all HTML5 video capable browsers.
However, by using h264 video and a Flash failover, you can cover all iDevices plus all browser that either don't support HTML5 video, or support HTML5 video for a format other than h264.
One word of warning: iDevices only support the h264 baseline up to level 3.0, so make sure to stay within these specs.
Hopefully that helps.