[FFmpeg-devel] [PATCH] use correct colorspace in Cinepak decoder

[u-bo1b at 0w.se]

On Sun, Feb 17, 2013 at 06:40:07PM +0000, Carl Eugen Hoyos wrote:
> > >If not: Did you measure if there is a 
> > >performance difference with your patch 
> > >when encoding cinepak into png-in-mov?
> > >(and how big the difference is when 
> > >transcoding to mpeg4?)

> I wanted to ask about decoding speed / performance:
> I assume that the following command line takes 
> (significantly) longer with your patch:
> $ ffmpeg -i cinepak.avi -qscale 2 -vcodec mpeg4 out.avi
> This is expected due to the nature of the change, 

I wouldn't expect Cinepak decoding to be comparable in complexity to mpeg4
encoding, even given an additional color conversion step.

> but I believe it would be interesting to know if the 
> following is slower or faster with your patch:
> $ ffmpeg -i cinepak.avi -vcodec png -an out.mov
> or simpler:
> $ ffmpeg -i cinepak.avi -vf format=rgb24 -f null -

Here follow the results of the old incorrect and the new correct decoder
(after the optimization fixes suggested by Michael) on a video sample
of 5850 frames compressed with the proprietary binary encoder:

(fps numbers: average of 5 runs in each case, rounded to the nearest integer)

 ffmpeg -i cinepak.avi -f null -

yuv (incorrect) : fps = 4012
rgb (correct)   : fps = 3478

 ffmpeg -i cinepak.avi -vf format=rgb24 -f null -

yuv (incorrect) : fps = 2618
rgb (correct)   : fps = 3481

Hope this answers your question?

I still can not see the point of measuring this difference given that we
compare incorrect to correct.

This suggests though that Cinepak color space actually makes decoding
to rgb about

(1-2618/3481)*100% = 24.8%

cheaper than with yuv420p in the same situation
(which yields (3481/2618-1)*100% = 33% higher codec throughput)

Was it this comparison which you aimed for?

I am curious how much quality/PSNR is being lost due to this colorspace
(due to partial subsampling of the actual luma) but I have no plans to
measure this.

Regards,
Rl