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

[Michael Niedermayer]

On Mon, Aug 13, 2012 at 11:13:46AM +0200, Boris Maksalov wrote:
> 
> 
> 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.

hmm

ffmpeg -i matrixbench_mpeg2.mpg -y -vcodec prores_kostya -threads 1 test.mov
results in 24fps encoding

ffmpeg -i matrixbench_mpeg2.mpg -y -vcodec prores_kostya -threads 12 test.mov
results in 66fps encoding

ffmpeg -i matrixbench_mpeg2.mpg -y -vcodec prores -threads 1 test.mov
results in 84fps encoding

so id say anatolies encoder does quite well without threads


> 
> > 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.

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.

Thanks

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle
-------------- 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/20120813/c91a9f78/attachment.asc>