On Sat, 8 Aug 2020 12:15:01 +0200 "Andreas Rheinhardt" <andreas.rheinha...@gmail.com> wrote:
> The version fields in the structure mimic the way the header is set up: > They are uint16_t. Yet the fields will be written with a pointer to int > (that's a consequence of using AV_OPT_TYPE_INT). This means that (most > likely) an unaligned pointer will be used to write one of them (most > likely the minor version) which is undefined behaviour. Furthermore this > won't work on big endian systems: When you write the major version, the > actual lower 16 bits (that matter) will be put into the minor version > (assuming no padding between the two versions) which will afterwards be > overwritten by the upper 16 bits of the minor version. The actual minor > version will be written into the upper 16 bits of the number of chunks > (again, assuming no padding). And finally, even on little-endian systems > it only works if the minor version is specified after the major version: > If you provide a major version via av_opt_set() (or via the ffmpeg > command line), it will zero the minor version even on little-endian > systems. In case no options are provided, this furthermore only works if > av_opt_set_defaults() applies options earlier in the AVOptions first. I > don't think such a dependency should exist. > > This is of course another reason to use a separate context for the muxer. ...I remember catching this when I had separate structures. I mustn't have updated it when I merged them. *sigh*, well done Zane. _______________________________________________ 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".
