[FFmpeg-devel] [PATCH] H.264: fix decoding of plain still images (broken since revision 14289)
Mon Jan 5 23:15:22 CET 2009
Michael Niedermayer schrieb:
> On Sun, Jan 04, 2009 at 09:58:18PM +0100, Reinhard Nissl wrote:
>> Mike Melanson schrieb:
>>> Reinhard Nissl wrote:
>>>> Carl Eugen Hoyos schrieb:
>>>>> Reinhard Nissl <rnissl <at> gmx.de> writes:
>>>>>> Sorry to bother you further, but this trial and error strategy
>>>>>> doesn't look promising. Can I do those conformance tests myself?
>>>> Thanks for the files. What's the recommended command line to to
>>>> the test?
>>> Here's an automated way to test it:
>>> Email me privately for more advice on setting it up.
>> Thanks, worked out of the box.
>> But I must give up on this issue. Still cannot find any other
>> condition to get the sample files play without breaking any
>> other. Only a hack which sets a separate variable in sequence end
>> nal and uses it in the previously patched code location to force
>> the output of the frame worked for my samples and didn't break
>> the others. But I didn't want to send this patch in for obvious
> can i see that patch please, because i think thats the only way the
> decoder could handle it, also the variable should be reset immedeatly
> afterwards to return the condition to the normal variant.
Well, I haven't sent in the patch as I just added a static int
xxxx; for testing. The attached patch is now in a releasable
state. It works regarding the still images and doesn't break the
Some thoughts about the change: actually, it pulls just one
picture from delayed_pics when a sequence end has been detected.
One could go on and implement that for consecutive calls no bytes
are consumed until all delayed_pics have been drained. This is
similar to calling decode with a zero sized buffer, but works in
the case where for example two or more sequences have simply been
catted together but separated by a sequence end code. Finally,
idr() should be called too to initialize the decoder into a state
where a next sequence which doesn't start with an idr can be
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1837 bytes
Desc: not available
More information about the ffmpeg-devel