[FFmpeg-devel] [PATCH] fix speex sample
Thu Apr 9 20:18:17 CEST 2009
On Thu, Apr 09, 2009 at 10:16:27AM -0700, Baptiste Coudurier wrote:
> I'll try to be more calm and clear this time.
> On 4/8/2009 7:46 PM, 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:
> >>>>>> On 4/8/2009 3:46 PM, Michael Niedermayer wrote:
> >> 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.
> > iam not ts maintainer nor are these my patches i tried to keep track
> > of them long time ago and occasionally pinged them as mans was
> > missing or forgeting about the patches. there where some that i did
> > pick up and rewrote so they passed mans review but as your oppinion
> > on maintainership is that the maintainer will fix patches thats
> > clearly not needed anymore.
> Well, if you don't mind pointing me to the patches, I'll try to review
> them and apply them.
[FFmpeg-devel] [PATCH] minor update to MPEGTS to handle yet another DCA stream type
[FFmpeg-devel] [PATCH] another AC3 descriptor for MPEG-TS
[FFmpeg-devel] [RFC] additinal desc_type for dtshd mpeg-ts demuxer
[FFmpeg-devel] [PATCH] fixup mpegts_get_pcr to be more reliable
[FFmpeg-devel] [PATCH] fix infinite loop in?mpegts_read_header() / pmt_cb()
[FFmpeg-devel] [PATCH] Proper parsing of DTS-HD MA streams -?Patch to TS Parser
note, i did not recheck that these are still "open" issues
> >> Why aren't ac3 decoder tests enabled for rm ?
> > all written in the source:
> > if [ -n "$do_ac3" ] ; then do_audio_encoding ac3.rm "" -vn # gcc
> > 2.95.3 compiled binaries decode ac3 differently because of missing
> > SSE support #do_audio_decoding #$tiny_psnr $pcm_dst $pcm_ref 2 1024
> > >> $logfile fi
> > or in 3 words, float rounding differences fix is welcome
> Ok, I guess this was discussed before, but why didn't we disable this
> specific sse function for gcc 2.95 ? Would it polute the source code too
> much ?
i belive the issue is that SSE != plain float and thus
x86+SSE != anything else, gcc 2.95 just had SSE disabled due to alignment
> > [...]
> >>>>> 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 sample_rate
> >> No it's not broken, it always set sample for speex to 16khz, this
> >> is _right_, no matter how much you twist the spec.
> > there are 2 things
> > 1. the sample rate of speex
> > 2. the patch
> >>>> 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 ?
> > i have no plans to fix this, but i certainly will review and comment
> > on a patch fixing it.
> >> 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.
> > bugs should be entered in roundup i mean you complain that i dont fix
> > bugs but i never saw these bugreports. How can i if mike sends them
> > to you via private mail?
> To be honest, I thought this was trivial enough to not cause so many
> I thought that jumping in, fixing it and submitting a patch was more
> We all lack motivation, sometimes preparing patches and submitting them
> is boring.
> I find that comiting and then receiving peer review in -cvslog
> is often more convenient and it seems you and Reimar in particular
> always do review in -cvslog.
> Now it seems that flv demuxer will need some cleanup before getting this
> issue fixed. To be honnest, right now, I just don't have the motivation
> to do it by submiting patches.
> Some time ago, people raised the possibility to be more flexible
> concerning maintainership between FFmpeg active official developers.
for trivial issues by all means commit directly
but the samplerate stuff and zero sized packet droping seem contriversal
to me, thats why i would like to see patches for this first
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel