Michael Niedermayer: > On Mon, Mar 11, 2019 at 12:36:08PM +0100, Andreas Rheinhardt wrote: >> The earlier version didn't really check that the 'p' of a "p\0" is >> actually part of a user_data section, instead it treated the first >> "p\0" after the start of a user_data section as end of a user_data >> section if it is close enough to the beginning of the user_data section; >> it actually needn't be part of a user_data section at all. >> >> Furthermore, the code worked under the assumption that there is a 0x00 >> after the 'p' although this might not be true for extradata if the >> user_data unit is at the end of the extradata. >> >> Both of these flaws have been fixed. >> >> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@googlemail.com> >> --- >> The earlier version was inspired by the check for packed bitstreams in >> decode_user_data() in mpeg4videodec.c where the "DivX" is mandatory, >> too. > >> Note that this new version relies on there being no binary zero inside >> the user data. > > Is this based on anything from the spec ?
No. According to the spec, a user_data ends upon the next occurence of a byte-aligned 0x000001 (and it may not contain a non-byte-aligned 0x000001), so it is allowed to have a binary zero in there. But I thought that a user_data for indicating a packed bitstream is a string, so shouldn't contain a binary zero. I can modify this if desired. (If so, does a "p\0" where the 'p' is part of the user_data be taken to indicate a packed bitstream or does the 'p' have to be the last nonzero character of the user_data?) (And shouldn't the same logic also be applied to the decoder (that currently requires the "DivX" to conclude that a stream is a packed bitstream)?) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel