[FFmpeg-devel] [PATCH 00/21] New Version

[Steve Lhomme]

Hi,

On 3/27/2019 12:18 PM, Andreas Rheinhardt wrote:
> This also changed the handling of unknown-sized elements: They are now
> ended whenever an element not known to be allowed in them is
> encountered. If we are already on level 1 and encounter an element not
> known to be allowed in an unknown-sized segment, this is treated as an
> indication that an error might have occured. I hope this is fine.

I haven't looked at the code yet, but an unknown element doesn't mean 
it's an upper level element. I think it should be either skipped or 
considered as bad data. If it's a known element but complitely misplaced 
it should not be going upper in the hierarchy. Only when a valid upper 
element it should go up in the hierarchy.

>
> Dale's sample "bear-320x240-live.webm" btw has cues at the end that use
> unknown-sized elements (wastefully coded on eight bytes) for CuePoints and
> CueTrackPositions which is spec-incompliant. They are not referenced by
> a SeekHead and so can't be used for seeking, but if they were, neither
> current FFmpeg nor FFmpeg with my patches applied would be able to use
> them. Are such files common (this is the first such file I ever saw)?
> If so, I could probably make it work.

If CuePoints are not referenced by the SeekHead at the front of the file 
(or the indirect SeekHead) they are useless anyway.

>
> I have cced Steve for this (I didn't the first time, because I
> thought that he (as a maintainer) would also be a subscriber to this
> list).

I am subscribed but not the maintainer. In fact I know little about this 
code.

> Oh, and I did not check with Valgrind that the new lacing code doesn't
> read uninitialized data. I don't even know how to use Valgrind. I just
> read the code. If someone more knowledgeable than I could please test
> it...

You might also use LLVM with ASAN (address sanitizer) it's helpfull for 
this (or so I have been told).