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, 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. If someone wants to try... -- Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA SMARTJOG S.A. http://www.smartjog.com Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA Phone: +33 1 49966312
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