[FFmpeg-devel] [PATCH]Add little-endian G726 decoder and use it for Sun AU files

Paul B Mahol onemda at gmail.com
Fri Aug 2 17:42:08 CEST 2013


On 8/2/13, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Fri, Aug 02, 2013 at 12:30:48PM +0000, Paul B Mahol wrote:
>> On 8/1/13, Michael Niedermayer <michaelni at gmx.at> wrote:
>> > On Thu, Aug 01, 2013 at 09:59:10PM +0000, Paul B Mahol wrote:
>> >> On 8/1/13, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
>> >> > Paul B Mahol <onemda <at> gmail.com> writes:
>> >> >
>> >> >> > whats the status of this patch & thread ?
>> >> >>
>> >> >> I already did posted patch for g726
>> >> >
>> >> > Maybe I misremember, but your patch does not
>> >> > work or do I miss something?
>> >> >
>> >> >> and I'm the one who originally found solution.
>> >> >
>> >> > To some degree, yes.
>> >> > (Roman explained it several years ago and I pointed
>> >> > out the German Wikipedia article iirc.)
>> >> >
>> >> >> If I did not posted patch,
>> >> >
>> >> >> also if I never commited get_bits_le
>> >> >
>> >> > If you remember correctly, I had implemented a
>> >> > solution before you implemented get_bits_le.
>> >> > (But I of course prefer the solution with
>> >> > get_bits_le very much.)
>> >>
>> >> Your solution was just giving noise.
>> >>
>> >> I will repeat once last time:
>> >>
>> >> Adding another codec is wrong and is hack.
>> >>
>> >
>> >
>> >> Proper solution is implementing code that
>> >> trys both paths and picks one with more sensible output, which I
>> >> already mentioned in another thread.
>> >
>> > compressing the data with DCT (vbr mp3)
>> > (this uses the asf file we have)
>> >
>> > -rw-r----- 1 michael michael  32040 Aug  2 00:00 le.mp3
>> > -rw-r----- 1 michael michael  31608 Aug  2 00:00 be.mp3
>> >
>> > the difference is just about 1% over the whole file
>> >
>> > and heres flac instead for a non dct variant
>> > -rw-r----- 1 michael michael 149954 Aug  1 23:45 le.ogg
>> > -rw-r----- 1 michael michael 149499 Aug  1 23:46 be.ogg
>> >
>> >
>> > also if you encode noise a fft/dct style detection will fail,
>> > a movie would likely  sound bad if parts that supposed to sound like
>> > noise get decoded with the wrong endianness
>> >
>> > also the first packets quite commonly could be totally silent and
>> > that maybe wont be distingishable le vs be like
>>
>> That would be easy to detect.
>>
>
>> Also what stops you muxing be variant into containers you think
>> are using le variant?
>
> nothing stops you if thats what you want to do
>
> but then
> what stops you from muxing vp9 under the name wmv2 in asf ?
> also nothing, still we dont try to decode the first frame of vp9/wmv2
> and analyze by 2d fft to detect it.
> Because this simply is hypothetical and (luckily) no such wmv2/vp9
> mixup files exist.
>
> If there exists a container that allows storing le and be g726 with
> the same codec tag then a solution for that has to be found. Maybe
> your FFT suggestion, maybe such container provides another way to
> identify the endianness (like muxer version maybe) and one could then
> check how other players deal with it.
> Its neccessary to actually have such files to really support them
> and make sure they really work and are detected correctly
>
> Do such unidentifyable / mixed LE/BE files exist in the wild ?

Just apply this and forget about it.

>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
>


More information about the ffmpeg-devel mailing list