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

[Michael Niedermayer]

On Fri, Aug 02, 2013 at 03:42:08PM +0000, Paul B Mahol wrote:
> 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.

ok, applied

thanks

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

There will always be a question for which you do not know the correct answer.
-------------- 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/20131018/71e61b02/attachment.asc>