[FFmpeg-devel] [PATCH 00/21] New Version
robux4 at ycbcr.xyz
Sun Apr 7 09:05:15 EEST 2019
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
I am subscribed but not the maintainer. In fact I know little about this
> 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
You might also use LLVM with ASAN (address sanitizer) it's helpfull for
this (or so I have been told).
More information about the ffmpeg-devel