[FFmpeg-devel] [RFC] Error concealment for B-frames/fixing issue 824
Baptiste Coudurier
baptiste.coudurier
Wed May 6 04:56:39 CEST 2009
On 5/5/2009 5:17 PM, Michael Niedermayer wrote:
> On Tue, May 05, 2009 at 02:08:33PM -0700, Baptiste Coudurier wrote:
>> Baptiste Coudurier wrote:
>>> On Fri, Apr 10, 2009 at 06:50:08PM -0700, Baptiste Coudurier wrote:
>>>> Hi Reimar,
>>>>
>>>> On 4/9/2009 3:13 PM, Reimar D?ffinger wrote:
>>>>> On Thu, Apr 09, 2009 at 10:52:32PM +0200, Michael Niedermayer wrote:
>>>>>> there are 2 very seperate things
>>>>>> 1. errors
>>>>>> 2. b frames without reference frames after seeking
>>>>>>
>>>>>> normal users dont want to see randomly trashed frames after seeking
>>>>>> in undamged files
>>>>> I think I agree... Is there a counter somewhere that could be used to
>>>>> find out which frame in the GOP we are at?
>>>> Yes temp_ref in pic structure.
>>>>
>>>>> Some options I can think of:
>>>>> 1) change code to not skip a B-frame if it is the second frame in a closed GOP
>>>>> 2) only skip B-frames if they directly follow the first I-frame of a non-closed GOP
>>>>> 3) (without really knowing what "broken link" means) only skip B-frames if "broken
>>>>> link" is set
>>>> From what I understand, broken link explicitly state that the 2 next b
>>>> frames cannot be decoded because the stream was cut at the preceding I
>>>> frame, therefore the original reference I frame is no more available.
>>>>
>>>> And I think your strategy should be ok :)
>>> Here is another attempt.
>>>
>>> It will decodes them only is closed gop is set.
>>> I got a sample with open gop and B frames before the I frame, it
>>> works, also, decoding them anyway does not crash when dummy picture is
>>> allocated some block are gray.
>>>
>>> Patch attached.
>>>
>> New patch attached, more correct.
>
> looks ok
I've tested it more to be sure and I've encountered this problem during
seeking with ffplay:
[mpeg2video @ 0x223f6a0]pic->data[0]!=NULL in avcodec_default_get_buffer
[mpeg2video @ 0x223f6a0]get_buffer() failed (-1 2147483647 8 0x3269950)
[mpeg2video @ 0x223f6a0]pic->data[0]!=NULL in avcodec_default_get_buffer
[mpeg2video @ 0x223f6a0]get_buffer() failed (-1 2147483647 8 0x3269950)
Seek to 63% ( 0:01:23) of total duration ( 0:02:12)
[mpeg2video @ 0x223f6a0]pic->data[0]!=NULL in avcodec_default_get_buffer
[mpeg2video @ 0x223f6a0]get_buffer() failed (-1 2147483647 8 0x3140e30)
[mpeg2video @ 0x223f6a0]pic->data[0]!=NULL in avcodec_default_get_buffer
[mpeg2video @ 0x223f6a0]get_buffer() failed (-1 2147483647 8 0x3140e30)
So I guess allocating last_picture this way was not correct.
I think copying next picture to last picture is better then.
Also I reset closed_gop to 0 in ff_mpeg_flush to avoid wrong state.
What do you think ?
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mpeg2_bframes_closed_gop2.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090505/ea7044bd/attachment.asc>
More information about the ffmpeg-devel
mailing list