[Ffmpeg-devel] [PATCH] lpcm 20 and 24 bit support in MPEG PS

[Michael Niedermayer]

Hi

On Tue, Jan 30, 2007 at 07:10:33PM +0100, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Tue, Jan 30, 2007 at 02:38:09PM +0100, Baptiste Coudurier wrote:
> >> Hi
> >> 
> >> Michael Niedermayer wrote:
> >>> Hi
> >>> 
> >>> On Fri, Jan 26, 2007 at 10:24:29AM -0000, M?ns Rullg?rd wrote:
> >>>> Baptiste Coudurier said:
> >>>>> Baptiste Coudurier wrote:
> >>>>>> Baptiste Coudurier wrote:
> >>>>>>> Baptiste Coudurier wrote:
> >>>>>>>> Hi
> >>>>>>>> 
> >>>>>>>> M?ns Rullg?rd wrote:
> >>>>>>>>> Baptiste Coudurier said:
> >>>>>>>>>> Diego Biurrun wrote:
> >>>>>>>>>>> Baptiste, patch forgotten?  :)
> >>>>>>>>>>> 
> >>>>>>>>>> Not really, Mans did not comment on it, and Michael
> >>>>>>>>>> said that it should use AVBitStreamFilter. Atm
> >>>>>>>>>> AVBitStreamFilter API has no support for demuxing,
> >>>>>>>>>> nor demuxer activation cap, so ....
> >>>>>>>>> I'm enjoying the California sun for a few more days.
> >>>>>>>>> I'll look at and think about this and other things
> >>>>>>>>> when I get back home.
> >>>>>>>>> 
> >>>>>>>> Any update about that patch ? It fixes a broken
> >>>>>>>> behaviour and add feature. If it's not ok, I'll fix it
> >>>>>>>> using another way.
> >>>>>>>> 
> >>>>>>> Ping. Ok solution is not beautiful, can we at least add
> >>>>>>> the bits_per_sample check and error when not 16 bit ?
> >>>>>>> 
> >>>>>>> Applying and mentioning "XXX: use AVBistreamFilter" is a
> >>>>>>> solution too and would add support for those streams.
> >>>>>>> 
> >>>>>> Ping....
> >>>>>> 
> >>>>> We did had a bug report today because of that issue.
> >>>> I'm still waiting for Michael to implement or approve some
> >>>> means of actually using the bitstream filter he says is the
> >>>> proper way to handle this.
> >>> i cant approve a way if noone suggests a way ... :)
> >>> 
> >>> and if you prefer this can also be implemented at the decoder
> >>> side ... or you could even approve the patch which adds it into
> >>> the demxuer but i dont think this is where the code should be
> >>> 
> >> if you want to wait for someone to implement AVBitstreamFilter
> >> automatic insertion, that's fine by me.
> > 
> > i dont see why this should be delayed until automatic bitstream
> > filter insertion is supported, rather the total opposite ... the more
> > bitstream filters we have the more people will want them to be
> > activated automatically so it would speed up the auto insert
> > implementation :)
> > 
> 
> actually there isn't any support at all for bitstream filters after
> demuxing, and before decoding.
> 
> >> IMHO a decoder is not a good idea until good support for >16 bit
> >> per sample audio is provided.
> > 
> > well and that will never be provided if there is no decoder which
> > outputs 32bit or 24 bit ... its a chicken and egg problem one needs
> > the other so why not write a decoder which outputs 32 or 24 bit?
> 
> First set avctx->sample_fmt in every decoder, 

no 16bit is default only non 16bit decoders needs to set this


> then change output buffer
> system because it can't reasonably be int16_t * anymore.
> That should not require a decoder which outputs 32 or 24 bit per sample.

it does, iam not aware of any part of the output buffer system which doesnt
support other formats, so a decoder is needed to find out which parts break

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070131/c1b50062/attachment.pgp>