[FFmpeg-devel] [PATCH] fix speex sample
Thu Apr 9 03:30:56 CEST 2009
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
>>>> On 4/8/2009 3:46 PM, Michael Niedermayer wrote:
>>>>>> The multiple stsd feature is implemented, and I submited a
>>>>>> patch, it depends on one seeking fix in aviobuf.c, for
>>>>>> which I also sent a patch.
>>>>>> Not mentioning that it takes me approximately 1 day to
>>>>>> address issues on roundup relative to mov/mp4. Btw you are
>>>>>> listed as maintainer for mov as well ;)
>>>>>> This is effectively a different kind of maintainership.
>>>>> it is not, you can look at avidec/enc and its also pretty bug
>>>>> free, or msmpeg4 or the mpeg1/2 decoder ...
>>>> msmpeg4 that should be true.
>>>> 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
IMHO you clearly shouldn't treat your users this way.
>>>>> flv is a little worse but not much and then there is mpeg-ts
>>>>> & ffserver for which i belive you are maintainer now, they
>>>>> are not even remotely close to bugfree not even close to
>>>>> flvdecs bugfreeness.
>>>> AFAIK I'm not official maintainer of mpeg-ts, but I don't mind
>>>> being maintainer and fixing bugs.
>>> i see, so i will suspent all my work on mpeg-ts now
>> I didn't know you were working on TS, may I see the patch ?
> There where plenty of patches on the ML that received no real review
> or no suggestions on how to make them acceptable IIRC. I did not mean
> i have some unfinished patch for TS
Well you'd better start working on them, then.
>>>> FFserver is certainly not bug free, however all roundup issue
>>>> were closed and fixed AFAIK, and it's working quite ok for me.
>>> issue238 and 797 have ffserver in the title and are open
>> Humm right, it seems issue 238 is way old, I was not maintainer
>> back in the days, and the version is damn old, I will close it.
>> About 797, user should use AVOption ab now anyway so this is not an
>> issue :)
>> Thanks for helping me closing roundup issues.
> its not hard to close issues while asking the user if its still
> buggy, one could close anything that way
Definitely not, if the issue is still present, user will reopen. I
believe the issue is fixed, but if not, I'll fix it.
I think basing debugging and work on a report that is more than one year
old, considering work that has been done on FFserver recently will not
>>> also there is no working ffserver regression test, you might have
>>> closed all issues but as long as ffserver cant produce non random
>>> output its not too usefull or did you fix this?
>> I produces stable results here, however I'd be happy to receive
>> feedback on failures.
> if its stable, why is it not enabled in make test ?
Ask make test maintainer. Why aren't ac3 decoder tests enabled for rm ?
>>>>>>>> but that's all right with me. Let's wait a few months
>>>>>>> you dont need to wait a few month before you fix your
>>>>>>> patch ;)
>>>>>> Well, like you said pretty well, I can spend my time on
>>>>>> something else than something maintainer is able to fix ;)
>>>>>> I don't have problem with this file personally, someone
>>>>>> submited this file. I just don't like bugs.
>>>>>> If I were maintainer, I would have fixed it already, that's
>>>>>> the whole point. I would even have addressed your comments
>>>>>> on -cvslog and changed my original commit ;)
>>>>> well, but you are not maintainer, and you will not become
>>>>> maintainer either if that prevents you from fixing flvdec,
>>>>> thats a pitty, cant be helped i guess.
>>>> Yes it can be helped, and you know it.
>>>> But that's no problem for me, it's just that I will have hard
>>>> time excusing you for refusing to let it go while you keep
>>>> saying you don't have time for it.
>>>> You just cannot reasonably refuse to share maintainership and
>>>> say that you don't have time to do it.
>>> dont twist the truth i do have time to review patches to flvdec.c
>>> i do not have the time nor interrest to rewrite patches.
>> I don't twist the truth IMHO. IMHO you do not have enough time to
>> be the only maintainer for flv.
>> _Only_ reviewing patch is not my idea of "maintainership".
>> Maintainership is about reviewing _and_ coding by _enhancing_ and
>> _fixing_ bugs.
> iam not stoping others from enhancing and fixing, they dont need to
> be "maintainer" for this. What i insist on is reviewing changes
> before they are commited to flvdec.c
The point is having you the _only_ maintainer is not efficient and
prevent the FLV code to be enchanced and fixed.
I claim that letting me co-maintaining it will improve vastly the situation.
>>> and i refuse you to take co maintainership because you commited
>>> broken code already
>> No, it's not broken. It fixed the issue and I'm still waiting for
>> your "correct" fix since your last proposition does _not_ work.
>> Furthermore you guessed something which was wrong since flv demuxer
>> could not even return empty packets. How good is this ?
>> Then I gave you the sample.
>>> and submited a broken patch to flvdec thats 2 bad out of 2.
>> No patch is _perfectly_ fine, and it actually fixes the problem.
>> You just twisted specs to fit your arguments here, even Mike
>> acknowledged my argument.
> what argument? your patch is broken no matter which way you define
No it's not broken, it always set sample for speex to 16khz, this is
_right_, no matter how much you twist the spec.
>> Please stop the FUD.
> please accept that you are not and will not be flvdec maintainer or
> co maintainer. This decisson is final.
Btw your so well FLV demuxer output packet with different codec in the
same stream. Do you plan to fix this or will you wait for 6 months ?
Btw I added H264/AAC/SPEEX demuxing to flv demuxer, I added h264 and AAC
to flv muxer. This is why Mike forwards me bugs.
You deliberately ignore this. I'm very much offended, and I won't be
calming down any time soon.
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel