[FFmpeg-devel] [PATCH] fix speex sample

[Baptiste Coudurier]

On 4/9/2009 7:06 AM, Michael Niedermayer wrote:
> On Thu, Apr 09, 2009 at 09:39:24AM +0200, Diego Biurrun wrote:
>> On Thu, Apr 09, 2009 at 04:46:34AM +0200, Michael Niedermayer wrote:
>>> On Wed, Apr 08, 2009 at 06:30:56PM -0700, Baptiste Coudurier wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Wed, Apr 08, 2009 at 05:26:11PM -0700, Baptiste Coudurier wrote:
>>>>>> On 4/8/2009 5:02 PM, Michael Niedermayer wrote:
>>>>>>> On Wed, Apr 08, 2009 at 04:21:32PM -0700, Baptiste Coudurier wrote:
>>>>>>>> Mpeg2 decoder has an important bug IMHO since some time. I
>>>>>>>> reported it, and libmpeg2 does not have this bug and decodes
>>>>>>>> correctly the first 2 frames. I lack some knowledge of the
>>>>>>>> surrounding code, but I tried to work on it at least. It should
>>>>>>>> not take you much time to figure out the problem I guess.
>>>>>>> thats a feature request not a bug, its something very well known
>>>>>>> since the code was written.
>>>>>> What was your argument about other implementation supporting it ? 
>>>>>> Oh yes, users will stop using yours to use the one supporting it.
>>>>>>
>>>>>> FYI, many of my samples use this mechanism, I just didn't really
>>>>>> realize it, I thought it was just broken link but finally, I
>>>>>> discovered that libavcodec deliberately _skip_ 2 frames, even
>>>>>> without telling you !
>>>>>>
>>>>>> Solution is simple, until fixed I will use libmpeg2.
>>>>> poor libmpeg2
>>>> I'd say poor libavcodec, loosing one heavy user because of lousy
>>>> maintainership.
>>> not implementing all feature requests != lousy maintainership
>>> if you want this feature, you can implement it.
>> So I will rephrase the question: What will it take for you to implement
>> this so that FFmpeg can be a complete libmpeg2 replacement?
> 
> I honestly have no interrest in implementing this. This is not a feature
> that should affect any ones decission of which decoder to use.

I'm not sure but loosing these 2 frames is really annoying for me, I
basically loose frame accuracy.

> I might change my mind if enough people ask politely or if someone
> provides an explanation of why the 2 frames after seeking matter (and
> one has to keep in mind that this only works with a subset of mpeg2
> files, and i would guess them to be a minority of mpeg2 files)
> [at least mpeg2 files generated by ffmpeg by default will not fall
>  in this category]

I'm don't think the seeking support is needed. I believe seeking should
seek happen to the keyframe before, and it should be fine.

I just would love to get these 2 frames decoded, that's it. For a quick
solution it will really improve the situation.

> besides supporting this also means that frame exact seeking will
> behave in an unexpected way that will cause alot more users to cry
> than there are for 2 frames that occasionally can be decoded.
> or how many people complained about these 2 frames so far?

They probably didn't see it, since there is was the way to see it was
not obvious.

> Also if someone considers this feature to be so critical to him, he
> can implement it, its simple "patch welcome"

Well, I'm not disagreeing here, I tried to fix it myself and submitted a
patch. I'm not sure to understand everything though.
Like I don't clearly understand why closed_gop and broken_link would
matter if we get error-concealment in this case.
Like you said these flags might be wrongly set.

Do you mean that If broken_link is set, then these 2 frames cannot be
decoded and should be discarded ?

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org