[FFmpeg-devel] [PATCH] Interlaced encoding for ProRes

Boris Maksalov boris.maksalov at yandex.ru
Tue Aug 14 11:35:33 CEST 2012

13.08.2012, 17:01, "Michael Niedermayer" <michaelni at gmx.at>:
> ...
> so id say anatolies encoder does quite well without threads
I am surprised it's that much faster. Had I known that before, I would probably add interlaced support to that one. Too late now though, as I don't feel like doing the same work twice.

> Can you compare this to a progressive file from apples encoder
> Whatever it uses, we should do the same.
> If we are wrong with what we store currently it should be fixed in a
> seperate patch, it has nothing to do with interlaced support.
Progressive is hard to analyze, as you don't have any landmark byte sequence following picture data that you can look for. I can confirm that for interlaced FinalCutPro-encoded clip, picture_size is the distance in bytes from the first picture header to the second picture header. So, it's picture_header_size + picture_data_size. Anatoly's encoder agrees with this interpretation.
Therefore, I am attaching 2 patches. The first one just fixes the picture_size field and the second one implements interlaced encoding.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-prores_kostya-fix-incorrect-picture_size-field.patch
Type: text/x-diff
Size: 859 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120814/955250d1/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-prores_kostya-implement-interlaced-encoding.patch
Type: text/x-c
Size: 14520 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120814/955250d1/attachment.c>

More information about the ffmpeg-devel mailing list