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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4