[FFmpeg-devel] [PATCH 04/12] avformat/mxfdec: compute both essence_offset and essence_length in mxf_compute_essence_containers

[Marton Balint]

On Thu, 14 Jun 2018, Tomas Härdin wrote:

[...]

>> > > +        } else {
>> > > +            int64_t op1a_essence_offset =
>> > > +                p->this_partition +
>> > > +                round_to_kag(p->pack_length,       p->kag_size) +
>> > > +                round_to_kag(p->header_byte_count, p->kag_size) +
>> > > +                round_to_kag(p->index_byte_count,  p->kag_size);
>> > 
>> > Is this really always the case? I guess with OP1a it isn't a huge
>> > concern since the demuxer will find the next essence packet anyway. But
>> > still..
>> > 
>> > I'm also fairly sure this is my code originally so.. :)
>> 
>> I think this tends to work well, if kag_size is not guessed. However, if 
>> it _is_ guessed, then there might be problems, and having a 0 kagsize is 
>> valid (only means an unknown KAG). So I am inclined to simply 
>> use p->first_essence_klv.offset unconditionally, as you suggested in
>> 
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225629.html
>
> Yes, past me seems to have the right idea :)
>
>> See the attached patch.
>
> I think we should still parse kag_size even if we don't end up using it
> for much. Especially since there's special cases for Sony files in
> there. Did we have a sample for that? I forget.

fate-suite/mxf/C0023S01.mxf

>
> Are there cases where we might not run across an essence KLV during
> scanning but where there would be one anyway? I suspect not, not even
> if we're reading an unseekable file

No, I don't think so either.

Regards,
Marton