Qlab 3 ProRes vs h264 codecs

[micpool]

Starting this as a new thread as this is more complex than I thought and potentially might lead to discovering the optimum video codec to use with Qlab3

I compared a Canon 7D file 25fps h264 long GoP with a ProRes (LT) file of the same footage and was surprised to find that the h264 had  better performance in Qlab3 than the ProRes which was the opposite of what was expected from experience with Qlab2.

It was suggested that this was due to the hardware acceleration on the GPU that h264 utilises in AVFoundation.

However my attempts to encode a h264 file in Apple Compressor have so far failed to produce anything that has the same performance as the h264 off the camera. In particular using the preset for encoding for vimeo (data rate limited to 20000bps) produces h264 files which have the worst performance of any codec I have tested.

There are so many variables in the h264 encoding: key frames (all, every x frames , automatic) Frame reordering (on, off) Data Rate (Automatic, restricted to x) Optimization(download, streaming, CD) and none of them seem to equate to anything in the literature about how long GOP codecs are specified. 25fps, Keyframe every 5 frames, 40000kbits/sec, download optimised is my best attempt, but what is really surprising is how small variations in the encoding settings impact performance so much.

I don't really know how best to continue this investigation. Is there some analysis software that would allow me to see the GOP patterns and try and work out what the differences are. The software h264 analysers I have found seem to be some of the most expensive software on the planet, some costing 4000 dollars or more.

I think it's really important to get to the bottom of this, particularly as the ProRes performance in Qlab3 under AVFoundation  seems to allow less simultaneous videos  than Qlab2.

Anyone got any ideas?

Mic

[micpool]

I have now retested with files of animation generated within After Effects and exported directly from AE in the default settings for h264 and ProRes(LT). Again h264 seems to be the better performing codec in Qlab3. The data rates are similar and the picture quality when the footage is playing seems practically identical.

If you have a very fast internet connection you can download a 3GB bundle from here and replicate the test.

http://we.tl/puv3Q4iH7Y

Mic

[Pierre-Luc Brunet]

Very interesting. Especially because you had very different result using Compressor and After Effects.

On the subject, here is a very informative video that just came out (which you might be interested in) that explains a lot about Codecs and related terms.

http://philipbloom.net/2014/09/02/everything-you-need-to-know-about-codecs/

It's not very technical or mathematical so it's easy to follow.

The man who made it, David Kong, also plans on making another video about the practical side of this theory and exporting.

I look forward to it.

[Pierre-Luc Brunet]

The world of compression is deep and dark. But it certainly would be great to have a some known results.

My initial thoughts when you said that the H.264 performed better than ProRes was file size vs hard drive capacity. Do you have a regular HDD rather than SDD? If so what speed? You also mentioned similar data rate later on but i'm still curious.

Perhaps GPU accelerated decoding does have en effect but I don't know the details on that subject.

-----------------

Some good information can be retrieved form the Adobe help website. Here are 2 links with good info. The snipets below are from these links.

http://helpx.adobe.com/after-effects/using/basics-rendering-exporting.html

QuickTime (MOV) encoding and compression settings

Frame Reordering

Some codecs allow for frames to be encoded and decoded out of order for more efficient storage.

Key Frame Every

In QuickTime terminology, the term key frames refers to something different from the change-over-time keyframes placed in the After Effects Timeline panel. In QuickTime, key frames are frames that occur at regular intervals in the movie. During compression, they are stored as complete frames. Each intermediate frame that separates them is compared to the previous frame, and only changed data is stored. Using key frames greatly reduces movie size and greatly increases the memory required to edit and render a movie. Shorter intervals between key frames enable faster seeking and reverse playback, but can significantly increase the size of the file.à

http://helpx.adobe.com/media-encoder/using/export-settings-reference.html#video_exports_settings

Some of it is useful, some brings more questions that would lead to more research.

[Pierre-Luc Brunet]

I've longed search for a way to see, in real time, what parts of a computer are being used when playing back different codecs.

If there was a way to determine the CPU usage (of a couple or specified process maybe) vs GPU vs Hard drive usage vs Frame rate (display frame rate and video playing frame rate) in one display that is always visible, it might give us insights to find the best codec for a particular machine or for a particular content.

In any case, could it be possible to make such a tool? 

*Winks toward the good people of Figure 53.

[micpool]

To be clear, both AE and compressor are capable of producing h264 files that outperform ProRes with Qlab3 . It's only the default presets which differ.

The main thing is that it is very easy to produce a h264 file that performs worse than ProRes (for instance exporting from QuickTime Player 7) and it was a complete fluke that the h264 I chose for testing was a direct transfer from a camera, and led me to investigate further. 

Mic

[Paul Gotch]

On 5 Sep 2014, at 18:31, Pierre-Luc Brunet <pierrelu...@gmail.com> wrote:
> In any case, could it be possible to make such a tool?

Such tools already exist in the Apple developer tools. However making sense of what the tools tell you is an entirely different matter.

-p

[micpool]

I have been messing around with this all day and have come to a simple solution based on the following:

Life is too short to be constantly testing codecs

In Qlab2 h264 doesn't work very well

In Qlab 3 h264 can produce good results but it's quite easy to produce a h264 file that doesn't play well depending on your choice of compression options

A good aim is to get any recent mac to play the maximum number of simultaneous video files possible with good picture quality on projector output.

My suggestion for a one size fits all rule for which codecs to use is this:

The first codec to try when encoding files for Qlab is ProRes 422 (proxy) which gives good video quality on projector output under most circumstances.

If you require higher picture quality then use ProRes 422 (LT) but be aware this may halve  the number of simultaneous videos Qlab can handle.

If you need transparency use ProRes 444 but be aware the data rate for this codec is extremely high.

I think this covers it for Qlab2 and Qlab3 common usage. Comments?

Mic

[micpool]

My testing also makes me think that the following statement is true:

h264 can, properly optimised, produce the same image quality of ProRes 422 (LT) in half the data rate. For advanced users this may mean it is possible to run twice as many videos in Qlab3 at exactly the same video quality using h264 instead of ProRes 422 (LT).

Mic

[micpool]

1 more observation.

h264 is far more CPU intensive than ProRes when using effects.

Mic

[Pierre-Luc Brunet]

Good to know.

This maybe due to the fact that generally:

-h.264 is a long GOP codec (Though it could be made to have all the full frames as well)

-ProRes is not. 

Meaning that every frame is stored in full with ProRes where as with h.264 it may only be 1 full frame every 30. (Depending on how it's compressed) 

So in theory:

-ProRes should have a higher file size but should be easier on the CPU

-h.264 should have a lighter file size but should be harder on the CPU

So I guess it's harder to apply effect on a codec that does not have all the full frames in it. But that's a guess right now.

Mic, when you were doing your tests and found that less ProRes files could be played at the same time (than h.264) were you able to see if the bottleneck was coming from the Hard Drive or the CPU?

Thank you for all this information.

[micpool]

On Sunday, September 7, 2014 4:57:41 AM UTC+1, Pierre-Luc Brunet wrote:

Mic, when you were doing your tests and found that less ProRes files could be played at the same time (than h.264) were you able to see if the bottleneck was coming from the Hard Drive or the CPU?

h264 is far more CPU intensive than ProRes when using effects.

I think the bottlenecks are generally Hard Drive related on my system. I misled you earlier. The data rates for ProRes (LT) are double that of a h264 file with similar visual quality. The data rate of h264 at it's optimum setting for Qlab is similar to ProRes proxy but the picture quality is markedly better than ProRes proxy.  

I have redone the tests in a more exhaustive and accurate  manner and the results are in the thread: Qlab3 Video Codec Data rates and quality comparisons 

I find it difficult to analyse CPU bottlenecks in AV foundation as there are 2 processes, Qlab and the decoder, in play. In AV foundation  on some codecs the loads fly around all over the place. I'm also unsure what CPU loads over 100 percent mean or how to determine how many cores are in use at any time. Its easy to spot big differences like an effect on a h264 video having a far larger CPU overhead than  the same effect on a ProRes video but it's very difficult to actually get a number from activity monitor. I suppose what I really want is something that will graph the CPU load for different processes.

Mic

[Christopher Ashworth]

Hmm, this puzzles me. Video effects are applied to frames of video agnostically to how they were generated. Perhaps since effects may have a high CPU hit it would be cumulatively more noticeable on a codec that has a higher CPU decoding cost?

But by the time video effects are applied all decoding is done and it's just a buffer of complete video frames which we feed (or don't feed) to effects processing.

(mobile)

[Angus Turner]

@Mic 

CPU loads over 100% means the process is using two cores. ie: 100% is 100% of 1 core, 200% is 100% of two cores etc  if that makes sense.

It also gets confusing because in most modern intel machines for every physical core there is actually two software cores (see Hyper-Threading).

So in my quad-core MBP retina I can have 800% worth of processes running.

Hope that makes more sense!

Thanks
Angus Turner
angus...@gmail.com

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53

---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.