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

[Boris Maksalov]

12.08.2012, 19:09, "Michael Niedermayer" <michaelni at gmx.at>:
> Hi
>
> On Fri, Aug 10, 2012 at 03:30:51PM +0200, Boris Maksalov wrote:
>
>>  Hi,
>>
>>  I've implemented interlaced encoding for ProRes.
>>  To activate interlaced mode, pass -flags +ildct
>>
>>  The first patch fixes a pre-existing bug where incomplete macroblocks were partially filled with memory read past the end of frame buffer. This can be verified with valgrind. The second patch actually implements interlaced encoding.
>>
>>  I do realize 'prores_kostya' encoder originates from libav and I did contact its author first, but things are moving quite slow on the libav side, so I am submitting my patches here.
>
> interlaced prores encoding support is welcome on the ffmpeg side.
> I would have preferred it in anatolies encoder though as i dont want to
> compete with kostya in maintaining his encoder but that wont stop me
> from applying a patch that adds an important feature.
I chose to modify Kostya's version as it has (some) multithreading support unlinke Anatoly's version.

> What stoped me though is that
> your patch breaks "make fate", this is a problem and has to be fixed
> first.
I checked with a hex editor and found where the difference is. It's in picture_size field of picture header. My patch makes it 7 bytes more.
If you change the following line in patched version:
picture_size = buf - (picture_size_pos - 1);

to the following line from the original code:
picture_size = buf - picture_size_pos - 6;

you'll be getting identical files in progressive mode but unplayable files in interlaced mode.
I believe original code tried to compute picture data size excluding picture header (though it would still be 1 byte off), which seems to be wrong. In fact it turns out in progressive mode you can get away with writing an arbitrary value into that field and still end up with a playable file.