Methodology of timing codecs.

[mitsubishi]

What I wanted to do was compare the lossless video codecs in the context of the pre-rendering stage of a two-pass encode to see which gave the best gains in time. I could run the whole process, but I thought I'd try to time just the encoding and decoding of the codec. My method was to time how long the encode took and time the decode with timecodec (using AVI decompressor + null ).

However right away I came across a problem. I took a base decoding time of just the source and it was slightly slower than the encoding of some of the codecs. How come? Am I missing something or is the method flawed?

[Dark Shikari]

There are many codecs that can end up decoding slower than encoding. Arithmetic coding (i.e. Lagarith) is one lossless example.

[Manao]

There are many codecs that can end up decoding slower than encodingErm, no. There are many codecs that decodes slower than other codecs encodes, but usually, a codec decodes faster than it encodes. Usually, everything that is done at the decoding side must be done during the encoding, so it's difficult for the encoder to be faster. CABAC is symetrical ( same encoding/decoding difficulty ).

[Dark Shikari]

Erm, no. There are many codecs that decodes slower than other codecs encodes, but usually, a codec decodes faster than it encodes. Usually, everything that is done at the decoding side must be done during the encoding, so it's difficult for the encoder to be faster. CABAC is symetrical ( same encoding/decoding difficulty ).
Usually, yes, but there are still many situations in which what you stated is not true, Lagarith being a prime example. Mostly its due to the algorithm used. Most algorithms are either symmetrical (such as PPMD) or asymmetrical with more encoding time (LZMA), but there exist others (like Lagarith's arithmetic coding) that are asymmetric towards increased decoding time.

[mitsubishi]

Yeah, the fact that decoding and encoding are different speeds is my motivation for testing. Most comparisons only seem to test the encoding side, but if you are using the intermediate stage to speed up a 2 pass encode on a slow source (ie a hardcore avisynth script etc) then decoding needs to be done twice and is actually twice as important as the encoding.

So to save time, the CPU time needed to encode once and decode twice needs to be less than one decode of the source. I'm going to have to rethink the test anyway as there are other flaws. But the thing that was getting me was running the source through timecodec took 42-45 seconds and the encoding from source in VDub was 40-41 seconds. Sure CPU use on decode is 60%, so there is spare capacity in a dual core to make it hit the same time if the encoder is super efficient, but the fact it is quicker means timecodec is slower than it should be....