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

Michael Niedermayer michaelni at gmx.at
Tue Aug 14 17:10:03 CEST 2012

On Tue, Aug 14, 2012 at 11:35:33AM +0200, Boris Maksalov wrote:
> 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.

patches applied

Please submit a patch that adds a regression test too



Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120814/376e568e/attachment.asc>

More information about the ffmpeg-devel mailing list