[FFmpeg-devel] Suspected incorrect negative cts_offset handling in mp4 trun box muxing
wolenetz at chromium.org
Thu Dec 15 02:33:37 EET 2016
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.
More information about the ffmpeg-devel