[FFmpeg-devel] [PATCH] H.264: fix decoding of plain still images (broken since revision 14289)

[Reinhard Nissl]

Hi,

Michael Niedermayer schrieb:
> On Sun, Jan 04, 2009 at 09:58:18PM +0100, Reinhard Nissl wrote:
>> Hi,
>>
>> Mike Melanson schrieb:
>>> Reinhard Nissl wrote:
>>>> Hi,
>>>>
>>>> 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?
>>>>> http://samples.mplayerhq.hu/fate-suite/h264-conformance/
>>>>> http://wftp3.itu.int/av-arch/jvt-site/draft_conformance/
>>>> Thanks for the files. What's the recommended command line to to
>>>> the test?
>>> Here's an automated way to test it:
>>>
>>> http://multimedia.cx/eggs/fate-testers-wanted/
>>>
>>> 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
>> reasons.
> 
> 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
other samples.

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

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg_fix_stills3.patch
Type: text/x-patch
Size: 1837 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090105/4bf11c98/attachment.bin>