[FFmpeg-devel] Suspected incorrect negative cts_offset handling in mp4 trun box muxing

[Matthew Wolenetz]

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)