This discussion is locked
-
All replies
-
Helpful answers
-
May 10, 2010 12:46 PM in response to snohomishdavidby Jon Walker,What uses might that be for?
One use might be for very fast action sequences.Is that an intermediate format used for editing?
No intermediate format is required using relatively new Apple video editor applications. (I.e., H.264/AAC content can now be edited natively.)What is the base compression in a h264 key frame? Is it jpeg or something more advanced?
H.264 aka MPEG-4/AVC aka MPEG-4 Part 10 is the video compression format. Key frames simply contain "all" frame data as opposed to "difference" (i.e., changed) data between frames. Think of a keyframe as a "refresh" frame.Is this better than photoJPEG?
Depends on what you are trying to do with the content. Motion JPEG and Photo JPEG are medium quality formats typically having a data rate in the 8-10 Mbps range foe VGA/SD content. H.264 has a much wider range of use in the 1-18 Mbps range depending on the quality to file size demands of your project. H.264 is typically used in the 8-12 Mbps range for HD content of QT Movie Trailer quality content and in the 1.5-3.0 range for TV VGA/Anamorphic quality content. It is basically a more efficient codec with greater scalability than either Motion JPEG or Photo JPEG which can be considered "all key frame" or all I-frame (intraframe) codecs.
-
May 10, 2010 12:59 PM in response to Jon Walkerby snohomishdavid,You're close to my question.
We're looking into do a H264 with just key frames (no B/Iframe stuff) for use with live projection. Some of the advantages would be precise frame control: forwards, backwards, different speeds, smooth transitions between videos; all live.
There is that little radio button in the QT settings that I've always ignored because it seems opposite to H264 & its optimization for smaller video sizes with a pretty decent appearance.
I was wondering why the QT/H264 team put that option in there to begin with.
What uses did they expect?
In this world of only key frames, are you getting equivalent (or better it seems) video quality than had you done photo-jpeg?
So. To rephrase the last paragraph: H264 is able to operate efficiently & produce better quality across a wider range of bit-rates. While the jpg/mpegs are oriented at the lower bit rates. -
May 10, 2010 5:30 PM in response to snohomishdavidby Jon Walker,I was wondering why the QT/H264 team put that option in there to begin with. What uses did they expect?
Only they would know for sure. Anything else would be a guess on my part.In this world of only key frames, are you getting equivalent (or better it seems) video quality than had you done photo-jpeg?
Assuming the source quality is the same for both codecs, I would normally assume the H.264 all key frame route would have a better potential for higher quality. As with all codecs the quality is primarily controlled by the efficiency of the codec, the limit on the data rate and how that data is distributed using the frame rate and key frame frequency. Since both Photo JPEG and an all key frame H.264 file can be considered essentially equal. And, since you can give both the same frame rate, you can say that they can be equivalent in this area also. With a Photo JPEG, this leaves the quality setting to control both data rate and, thus, the quality. On the other hand, with H.264 you can set a specific target date rate, set a quality level to control certain recursive actions during the encoding process, and also set multiple encoding passes which essentially provide a constant level of quality between various types of scene content which, in turn, usually translates to smaller target files. So between the two, my personal opinion is that you have more control of the encoding process and a better chance to either create a better quality product of one of the same quality using less files space/narrower bandwidth, whichever is your primary goal. There are, of course, other considerations like motion prediction, quantization, entropy algorithms, color consistency, etc. In most cases I lean more towards the H.264 than Photo JPEG (with the possible exception of the question of color and this even can change with the use of higher H.264 profiles which I normally don't use in my standard QT work flows. Frankly, I tend to prefer the Apple Animation codec for many things where date rate, file size, and certain recent editing issues are not a concern in a specific work flow. My normal advice is to test both realistically in the work flow you plan to use and see which works best for you specific needs.So. To rephrase the last paragraph: H264 is able to operate efficiently & produce better quality across a wider range of bit-rates. While the jpg/mpegs are oriented at the lower bit rates.
I tend to look at it as a tradeoff between quality and efficiency in terms of time, space, and complexity. With H.264 you simply have more facets which you can very and, by "playing" with these variables, have more options as to how you can encode for specific project goals dependent on/in relationship to the content with which you are starting. As to a specific efficiency comparison between Photo JPEG and H.264, I've never tried to make one. As a "rule of thumb", I normally consider H.264 to be 2.0 to 2.5 times as efficient as MPEG-4 meaning I would normally start with an MPEG-4 data rate 2-2.5 times as great as an H.264 file in an attempt to achieve the same level of quality. This of course, would be subject to refinement as needed depending on the source content -- its complexity and/or consistency.
-
May 11, 2010 7:54 AM in response to snohomishdavidby snohomishdavid,Thanks.
I had heard of this h264 I-Frame only format as a replacement for photo-jpeg (video projection & VJing).
And that seems to be true.
The concept is something Apple (iFrames format 960x540) and Panasonic (AVC-Intra for the high-end) have been proposing for video capture formats.
It appears h264 has more head room when you give it more of a bitrate. JPEG seems to top out and is quite as close to the original. Even if you pump jpeg up to 100% at which point the file becomes large anyway.