[FFmpeg-devel] [PATCH] fix speex sample

[Michael Niedermayer]

On Wed, Apr 08, 2009 at 10:51:02AM -0700, Baptiste Coudurier wrote:
> Hi Michael,
> 
> On 4/2/2009 8:46 PM, Michael Niedermayer wrote:
> > On Thu, Apr 02, 2009 at 08:08:41PM -0700, Baptiste Coudurier wrote:
> >> On 4/2/2009 7:11 PM, Michael Niedermayer wrote:
> >>> On Thu, Apr 02, 2009 at 06:09:15PM -0700, Baptiste Coudurier wrote:
> >>>> Michael Niedermayer wrote:
> >>> [...]
> >>>
> >>>>>> Then I guess you noticed how many bugs are rotting in roundup ? This is
> >>>>>> becoming a nightmare and is really frightening. Nobody jumps in, and
> >>>>>> this was proved by the last 2 attempts to organize a bug fixing weekend.
> >>>>> i know and agree, you also remember i did occassionally in the past fix a
> >>>>> bunch of bugs but ATM i lack the motivation, i know thats my problem and
> >>>>> i should go and bang my head against the wall ;)
> >>>> Well, yes, but it's not only your problem, I believe it is our problem,
> >>>> and it would be nice if everybody could participate in the effort.
> >>> fine but i have to check this with the insurance first, if they cover damage
> >>> from a bunch of madman banging their heads against the walls
> >>>
> >>>
> >>>> I was motivated yesterday night.
> >>>>
> >>>>>> Now I do care and I proved it, so I claim that yes some changes my
> >>>>>> introduce regression but these will be fixed quickly, I engage myself.
> >>>>> i think the proposed fix is wrong and a correct one will not introduce a
> >>>>> regression
> >>>> Well, I still don't really see how and why, I've explained more below.
> >>> iam not talking about "SoundRate UB[2]" but that:
> >>>             else if(!strcmp(key, "audiosamplerate") && acodec && num_val >= 0) {
> >>>                 //some tools, like FLVTool2, write consistently approximate metadata sample rates
> >>>                 if (!acodec->sample_rate) {
> >>>                     switch((int)num_val) {
> >>>                         case 44000: acodec->sample_rate = 44100  ; break;
> >>>                         case 22000: acodec->sample_rate = 22050  ; break;
> >>>                         case 11000: acodec->sample_rate = 11025  ; break;
> >>>                         case 5000 : acodec->sample_rate = 5512   ; break;
> >>>                         default   : acodec->sample_rate = num_val;
> >> Yes, however I'm sorry, I don't see how this relates to the patch.
> >>
> >> The patch makes the demuxer always set speex and nellymoser to their
> >> correct _codec_ value IMHO, this "audiosamplerate" is a metadata thing
> >> according to the specs, defined with onMetadata mechanism.
> > 
> > I agree but then there would be no point to even decode audiosamplerate
> > and i suspect there was some sense in this, i just dont remember it now
> > 
> 
> Any update on this ? It would be nice to fix bugs ;)

no update, iam still waiting for someone to post a corrected patch

The samplerate as set a few lines above is incorrect, i suspect fixing that
will fix the problem
also a function with the name "flv_set_audio_codec" has no business setting
the samplerate, this should be split out and run seperately when needed

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090408/d08abedc/attachment.pgp>