Per spec, if cts_offset is negative, the trun box version needs to be set to 1. Yet I see no corresponding condition around this in libavformat/movenc.c; version is hardcoded to 0 and the *signed int32* typed value (track->cluster[i].cts) is written out (with a conversion to unsigned int32 with same underlying bits in call to avio.wb32()).
This can cause issues in players if they follow the spec and expect a version 0 box to contain unsigned int32 cts_offset values. If ffmpeg had a negative track->cluster[i].cts value, a conformant player will interpret that value as a huge positive value (due to version 0 logic). Does ffmpeg somehow guarantee that trun cts_offsets are always positive? If not, this looks like a bug in ffmpeg mp4 muxing. (Reference https://bugs.chromium.org/p/chromium/issues/detail?id=650584#c7) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
