On 19.08.2014, at 15:46, Clément Bœsch <u...@pkh.me> wrote:
> On Tue, Aug 19, 2014 at 01:41:49PM +0000, Carl Eugen Hoyos wrote:
>> Clément Bœsch <u <at> pkh.me> writes:
>>
>>> On Mon, Aug 18, 2014 at 11:39:26PM +0000, Carl Eugen Hoyos wrote:
>>>> Clément Bœsch <u <at> pkh.me> writes:
>>>>
>>>>> + { AV_CODEC_ID_PCM_S24BE, MKTAG('n', 'i', '2', '4') },
>>>>> BBC typo */
>>>>> + { AV_CODEC_ID_PCM_S24LE, MKTAG('n', 'i', '2', '4') },
>>>>> /* BBC typo */
>>
>>> I'm sorry, I don't understand what you mean.
>>
>> I believe that FFmpeg would not be able to
>> decode "ni24" samples with your patch above.
>> If I understand the patch from Elemental
>> correctly, all ni24 files they encountered
>> are PCM_S24LE, while your patch would identify
>> such files as PCM_S24BE.
>> Or do I misunderstand?
>>
>
> There is an endianess chunk which is used to swap BE <-> LE if necessary
> (see lavf/mov.c:mov_read_enda()). If you look into the array, I'm
> changing, there are a bunch of similar occurences around.
Considering that they got ni/in wrong, is there any particular reason to
believe they got that one right?
It would be kind of silly if we added a workaround/hack that hasn't been tested
by anyone and in the end doesn't even work, especially if the risky version is
the one with (trivially) more code...
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
