[PATCH]Add little-endian G726 decoder and use it for Sun AU files
Hi! Attached patch fixes ticket #1955 as suggested by Roman. Please comment, Carl Eugen
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Hi!
Attached patch fixes ticket #1955 as suggested by Roman.
Please comment, Carl Eugen
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score. This is actually used in reality for at least one case I can't remember right now. This one we can avoid having another decoder. Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Paul B Mahol <onemda <at> gmail.com> writes:
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Wouldn't that brake remuxing? Carl Eugen
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Wouldn't that brake remuxing?
Extradata should be keept when remuxing.
Carl Eugen
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Paul B Mahol <onemda <at> gmail.com> writes:
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Wouldn't that brake remuxing?
Extradata should be keept when remuxing.
And how will WMP (or any other player) know that the FFmpeg developers decided to define extradata for a 20-year old codec? Apart from the fact that I don't understand what the problem is having an additional codec I think the FFmpeg architecture requires an additional codec if different riff tags are used for two variants of the "same" codec (as in this case). Carl Eugen
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Wouldn't that brake remuxing?
Extradata should be keept when remuxing.
And how will WMP (or any other player) know that the FFmpeg developers decided to define extradata for a 20-year old codec?
Apart from the fact that I don't understand what the problem is having an additional codec I think the FFmpeg architecture requires an additional codec if different riff tags are used for two variants of the "same" codec (as in this case).
IIRC wasn't there also some le variant in mov demuxer too? Or its another codec...
On 7/11/13, Paul B Mahol <onemda@gmail.com> wrote:
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
Wouldn't that brake remuxing?
Extradata should be keept when remuxing.
And how will WMP (or any other player) know that the FFmpeg developers decided to define extradata for a 20-year old codec?
Apart from the fact that I don't understand what the problem is having an additional codec I think the FFmpeg architecture requires an additional codec if different riff tags are used for two variants of the "same" codec (as in this case).
IIRC wasn't there also some le variant in mov demuxer too?
Or its another codec...
Actually I think it was asf and was same codec as in mov but different endian format.
Paul B Mahol <onemda <at> gmail.com> writes:
On 7/11/13, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
Hi!
Attached patch fixes ticket #1955 as suggested by Roman.
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score.
Afaict this has to happen in the demuxer and is orthogonal to this patch. Carl Eugen
Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:
Attached patch fixes ticket #1955 as suggested by Roman.
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score.
Afaict this has to happen in the demuxer and is orthogonal to this patch.
Ping. If there are no comments, I would like to push. Carl Eugen
On 7/29/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:
Attached patch fixes ticket #1955 as suggested by Roman.
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score.
Afaict this has to happen in the demuxer and is orthogonal to this patch.
Not at all.
Ping.
If there are no comments, I would like to push.
I commented already, but it looks like you like to ignore/cut things you do not like.
Paul B Mahol <onemda <at> gmail.com> writes:
Attached patch fixes ticket #1955 as suggested by Roman.
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score.
Afaict this has to happen in the demuxer and is orthogonal to this patch.
Not at all.
Please elaborate how this would fix remuxing if implemented in the decoder. Carl Eugen
On 7/29/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Attached patch fixes ticket #1955 as suggested by Roman.
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score.
Afaict this has to happen in the demuxer and is orthogonal to this patch.
Not at all.
Please elaborate how this would fix remuxing if implemented in the decoder.
Please elaborate how your patch would handle asf files.
Paul B Mahol <onemda <at> gmail.com> writes:
Please elaborate how this would fix remuxing if implemented in the decoder.
Please elaborate how your patch would handle asf files.
I don't remember a failing asf G726 file, do we have one? The patch is meant to fix G726 in au and aiff. Carl Eugen
On 7/29/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Please elaborate how this would fix remuxing if implemented in the decoder.
Please elaborate how your patch would handle asf files.
I don't remember a failing asf G726 file, do we have one?
Sure, look at samples.
The patch is meant to fix G726 in au and aiff.
What about mov? Fixing it for au and aiff is suboptimal as such formats are less popular.
Paul B Mahol <onemda <at> gmail.com> writes:
On 7/29/13, Carl Eugen Hoyos <cehoyos <at> ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
Please elaborate how this would fix remuxing if implemented in the decoder.
Please elaborate how your patch would handle asf files.
I don't remember a failing asf G726 file, do we have one?
Sure, look at samples.
I did (several times) and was unable to find one, please elaborate.
The patch is meant to fix G726 in au and aiff.
What about mov?
Do you have a G726 mov sample? I would be very interested.
Fixing it for au and aiff is suboptimal as such formats are less popular.
I may misunderstand but these are the formats for which tickets were opened, fixes for hypothetical bugs are less optimal than fixes for reproducible issues imo. Carl Eugen
On Thu, Jul 11, 2013 at 12:57:00PM +0000, Paul B Mahol wrote:
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Hi!
Attached patch fixes ticket #1955 as suggested by Roman.
Please comment, Carl Eugen
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score. This is actually used in reality for at least one case I can't remember right now.
This one we can avoid having another decoder.
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
whats the status of this patch & thread ? The way i understand it is that carls patch is implemented in line with a suggestion from roman (who is maintainer of g726) but he didnt explicitly approve this patch though. It was suggested (above) that extradata could be used to avoid the 2nd dummy AVCodec, I see advantages and disadvantages of such approuch and dont really mind which way its done but i do mind if neither solution is pushed. If roman makes an explicit statement about this patch vs extradata then i will follow his choice if he does not i will eventually push one solution as either is better than having no support. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
On 8/1/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Thu, Jul 11, 2013 at 12:57:00PM +0000, Paul B Mahol wrote:
On 7/11/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Hi!
Attached patch fixes ticket #1955 as suggested by Roman.
Please comment, Carl Eugen
There is way to check if given decoded audio is sane enough, using fft one can inspect first be variant and then le one and pick one with higher score. This is actually used in reality for at least one case I can't remember right now.
This one we can avoid having another decoder.
Anyway having another decoder is really ugly, you could make use of extradata to have/force same funcionality.
whats the status of this patch & thread ?
I already did posted patch for g726, and I'm the one who originally found solution. If I did not posted patch, also if I never commited get_bits_le, Carl would never come to this "original" solution. There are other containers which have g726 and are not correctly currently decoded.
The way i understand it is that carls patch is implemented in line with a suggestion from roman (who is maintainer of g726) but he didnt explicitly approve this patch though.
It was suggested (above) that extradata could be used to avoid the 2nd dummy AVCodec, I see advantages and disadvantages of such approuch and dont really mind which way its done but i do mind if neither solution is pushed. If roman makes an explicit statement about this patch vs extradata then i will follow his choice if he does not i will eventually push one solution as either is better than having no support.
As proven numerous times in past.... worse solution is prefered than no solution at all.
Thanks
[...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
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.)
Carl would never come to this "original" solution.
There are other containers which have g726 and are not correctly currently decoded.
As said, please elaborate, I searched for a very long time and was unable to find more samples. (Although I am sure g726le in wav exists.) Carl Eugen
On 8/1/13, Carl Eugen Hoyos <cehoyos@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.)
Carl would never come to this "original" solution.
There are other containers which have g726 and are not correctly currently decoded.
As said, please elaborate, I searched for a very long time and was unable to find more samples. (Although I am sure g726le in wav exists.)
There is asf sample.
Paul B Mahol <onemda <at> gmail.com> writes:
As said, please elaborate, I searched for a very long time and was unable to find more samples. (Although I am sure g726le in wav exists.)
There is asf sample.
My patch does not affect asf samples, they work both with and without the patch (as you know very well). Carl Eugen
On 8/1/13, Carl Eugen Hoyos <cehoyos@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.
Paul B Mahol <onemda <at> gmail.com> writes:
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.
The original solution was bit-exact to the current posted one, the patch was just bigger.
I will repeat once last time:
Adding another codec is wrong and is hack.
Why?
Proper solution is implementing code that trys both paths and picks one with more sensible output
How would that help in a third-party application using lavf that wants to use a different decoder? Carl Eugen
On 8/1/13, Carl Eugen Hoyos <cehoyos@ag.or.at> wrote:
Paul B Mahol <onemda <at> gmail.com> writes:
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.
The original solution was bit-exact to the current posted one, the patch was just bigger.
I will repeat once last time:
Adding another codec is wrong and is hack.
Why?
Proper solution is implementing code that trys both paths and picks one with more sensible output
How would that help in a third-party application using lavf that wants to use a different decoder?
Code for checking be/le should not be in lavf at first place.
On Thu, Aug 01, 2013 at 09:59:10PM +0000, Paul B Mahol wrote:
On 8/1/13, Carl Eugen Hoyos <cehoyos@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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
On 8/1/13, Michael Niedermayer <michaelni@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@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?
[...]
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
On Fri, Aug 02, 2013 at 12:30:48PM +0000, Paul B Mahol wrote:
On 8/1/13, Michael Niedermayer <michaelni@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@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
On 8/2/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Fri, Aug 02, 2013 at 12:30:48PM +0000, Paul B Mahol wrote:
On 8/1/13, Michael Niedermayer <michaelni@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@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
On Fri, Aug 02, 2013 at 03:42:08PM +0000, Paul B Mahol wrote:
On 8/2/13, Michael Niedermayer <michaelni@gmx.at> wrote:
On Fri, Aug 02, 2013 at 12:30:48PM +0000, Paul B Mahol wrote:
On 8/1/13, Michael Niedermayer <michaelni@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@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.
On Thu, Jul 11, 2013 at 02:06:20PM +0200, Carl Eugen Hoyos wrote:
Hi!
Attached patch fixes ticket #1955 as suggested by Roman.
Please comment, Carl Eugen
Is there something i can help with so you would post git patches that can be applied without manual amending ? :) git-send-email should be able to use a smtp server directly or with a lightweight MTA like msmtp (no true sendmail is required)
libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h | 1 + libavcodec/codec_desc.c | 7 +++++++ libavcodec/g726.c | 25 +++++++++++++++++++++++-- libavformat/au.c | 14 +++++++++++++- 5 files changed, 45 insertions(+), 3 deletions(-) 979166cfe6a78086edd80ed14ecb7a119b1b7dd6 patchaug726.diff
should be split between demuxer and decoder changes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
participants (3)
-
Carl Eugen Hoyos -
Michael Niedermayer -
Paul B Mahol