[FFmpeg-devel] [PATCh] aac parser: Don't write channels, sample rate, and frame size each frame

Michael Niedermayer michaelni
Tue Mar 2 11:55:46 CET 2010


On Tue, Mar 02, 2010 at 05:13:15AM -0500, Alex Converse wrote:
> On Tue, Mar 2, 2010 at 5:03 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Mon, Mar 01, 2010 at 08:31:42PM -0500, Alex Converse wrote:
> >> On Mon, Mar 1, 2010 at 8:23 PM, Michael Niedermayer <michaelni at gmx.at>wrote:
> >>
> >> > On Mon, Mar 01, 2010 at 08:16:48PM -0500, Alex Converse wrote:
> >> > > They are part of the invariant header and shouldn't change each frame
> >> > > anyway. This prevents them from overwriting information provided by
> >> > > backwards compatible extensions.
> >> >
> >> > what you attached does not match the description
> >> >
> >> > besides "shouldn't change" gives me a strange feeling ...
> >> > if we can support it changing it would be a nice "wish/feature request"
> >> >
> >>
> >> According to the AAC specification they changing these vales from frame to
> >> frame is forbidden. They are part of the fixed header.
> >
> > these are written in every spec, it seems not to stop the broadcast crowd
> > from switching channels and such between programs/commercials/...
> >
> > Also if ffmpeg doesnt support X and another application does support X
> > people switch applications instead of reporting bugs. (path of least
> > work ...).
> 
> I've found several times that people report bugs for things X does
> that FFmpeg does not. People complained that the sample rate and
> channel count of pure LC streams was wrong because we didn't match
> libfaad2.

they often do not
how many things can mplayer do that ffplay cannot, how many where
reported to us?
and then there are projects that serve no other purpose than to
workaround issues in ffmpeg. Nothing of this is reported to us
rather one finds it by luck in forum posts or irc that theres
yet another fork hoarding hacky workarounds ...
If these people would instead of hackitis-forkitis report the issues
they have with ffmpeg and work together with us on ffmpeg-dev we would have
them fixed in no time.
One should fork when one disagrees with us not when one found 3 bugs


> 
> > Do other players support changing samplerate/channels in aac?
> >
> 
> I have no idea if other players support changing frequency, channel
> count, or frame size midstream. Even if we wanted to support it the
> decoder still gets the full ADTS headers. Just blindly spitting out
> values from the parser into the codec context every frame doesn't seem
> like the proper solution here.

i agree on that part

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- 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/20100302/f0cb95f9/attachment.pgp>



More information about the ffmpeg-devel mailing list