Here is a new version. Some of the already sent patches were slightly modified: The first patch now removes two unused variables and "Improve length check" has been rewritten. Furthermore, some new patches not directly needed in order to fix the garbage error message have been added:
1. The generic seeking code sometimes relies on the data_offset to seek to in order to begin parsing from this point on. For the Matroska demuxer, this field has usually been set to the beginning of the size field of the first cluster. This is wrong, instead it should be set to the beginning of the first cluster. This fixes a "Truncating packet of size 21061679 to 17740959" error that one gets when using Michael's sample with the commandline he provided. 2. Attachments are already read into a suitably padded refcounted AVBuffer, so that one can directly reuse this AVBuffer in case this attachment contains an attached picture. 3. The error messages in ebml_read_num were quite suboptimal and have been fixed. My idea to make the incremental parsing of clusters level compliant is that levels are an EBML concept and so this should be handled internally by the EBML functions, not the Matroska functions. So ebml_parse itself takes care of correctly opening/closing the levels. This has been coupled with the length checks that are done before reading an element's payload in order to reduce the amount of checks needed. Furthermore, a special return value is returned whenever a level is ended so that one can use this to determine whether to perform whatever action is necessary at the end of a level. (In the end, the actual parsing of clusters turned out not to need this.) 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. 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. 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). 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... - Andreas Andreas Rheinhardt (21): avformat/matroskadec: Remove unused variables avformat/matroskadec: Don't zero unnecessarily avformat/matroskadec: Get rid of cluster size field assumption avformat/matroskadec: Use generic size check for signed integers avformat/matroskadec: Set offset of first cluster avformat/matroskadec: Don't copy attached pictures avformat/matroskadec: Remove redundant initialization avformat/matroskadec: Improve error messages avformat/matroskadec: Remove non-incremental parsing of clusters avformat/matroskadec: Don't keep old blocks avformat/matroskadec: Treat SimpleBlock as EBML_BIN avformat/matroskadec: Remove redundant variable declaration avformat/matroskadec: Improve length check avformat/matroskadec: Use proper levels after discontínuity avformat/matroskadec: Redo level handling avformat/matroskadec: Make cluster parsing level compatible avformat/matroskadec: Don't reset cluster position avformat/matroskadec: Combine two arrays avformat/matroskadec: Add SilentTracks to cluster syntax avformat/matroskadec: Redo EOF handling avformat/matroskadec: Typos and cosmetics libavformat/matroska.h | 1 + libavformat/matroskadec.c | 537 ++++++++++++++++++++------------------ 2 files changed, 280 insertions(+), 258 deletions(-) -- 2.19.2 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
