[FFmpeg-devel] [PATCH]lavf/matroskadec: Parse stsd atom in mkv with the appropriate mov function

[Mats Peterson]

On 12/14/2015 12:21 PM, Mats Peterson wrote:
> On 12/14/2015 12:16 PM, Mats Peterson wrote:
>> On 12/14/2015 12:15 PM, Carl Eugen Hoyos wrote:
>>> On Monday 14 December 2015 12:10:48 pm Hendrik Leppkes wrote:
>>>> On Mon, Dec 14, 2015 at 12:03 PM, Carl Eugen Hoyos wrote:
>>>>> On Monday 14 December 2015 09:37:22 am Hendrik Leppkes wrote:
>>>>>> On Mon, Dec 14, 2015 at 3:40 AM, Carl Eugen Hoyos wrote:
>>>>>>> Hi!
>>>>>>>
>>>>>>> Attached patch based on 3ece3e4c by Martin Storsjö fixes
>>>>>>> ticket #5071 for me. I can't see how duplicating the code
>>>>>>> from mov.c could be acceptable.
>>>>>>
>>>>>> Personally I found toying with st->priv_data to make it look
>>>>>> like being in the MOV demuxer not acceptable.
>>>>>
>>>>> Given that ff_mov_read_stsd_entries() is already used outside
>>>>> of the mov demuxer and we generally avoid code duplication and
>>>>> the (very short) specification of the structure only mentions
>>>>> it is identical to stsd, I consider my patch the more
>>>>> acceptable solution.
>>>>>
>>>>>> It has the potential for unpredicatble side-effects in the
>>>>>> long run.
>>>>>
>>>>> If this potential exists, it also exists without this patch.
>>>>
>>>> Just because its already used elsewhere doesn't make it a good
>>>> idea.
>>>
>>> So how should we read the stsd atom from non-mov input?
>>>
>>> Carl Eugen
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> Are you ignoring me completely? Not that I'm surprised. I already
>> explained what I've been doing in my patch. Read it.
>>
>> Mats
>>
>
> The contents of the stsd atom IS ALREADY IN THE PRIVATE DATA.
>
> Mats
>

And "how should we read it", well, exactly what I've been doing, by 
using offsets into the private data to get at the various values.

Mats

-- 
Mats Peterson
http://matsp888.no-ip.org/~mats/