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

Michael Niedermayer michaelni at gmx.at
Fri Aug 2 15:39:34 CEST 2013


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 ?

[...]
-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130802/a6b6877a/attachment.asc>


More information about the ffmpeg-devel mailing list