GNOME Bugzilla – Bug 759615
DTS > PTS creates invalid mp4 files
Last modified: 2016-01-27 10:08:39 UTC
I think there are other bugs related to this, but not sure where - feel free to dup. When running a pipeline like this: rtspsrc location=... ! rtph264depay ! h264parse ! mp4mux name=mux ! filesink it seems common that at the start there's a packet with DTS > PTS, possibly due to udpsrc DTS timestamping stuff, I'm not sure. When it happens, the logic inside mp4mux for collecting first_ts and first_dts ends up with first_dts > first_ts, and the in gst_qt_mux_update_edit_lists() it does ctts = qtpad->first_ts - qtpad->first_dts and then writes a very large uint32 into the media_start time for the edit list - creating a file that GStreamer doesn't play (although other apps VLC/mplayer that I guess don't handle edit lists work). Attaching a patch that makes it work, but I think ignores a more fundamental problem that needs addressing.
Created attachment 317601 [details] [review] qtmux: Don't write invalid edit list start time. Avoid writing a negative number as a large positive integer in an edit list when the first_ts is smaller than the first_dts - which can happen when the first packet received has a PTS but no DTS.
I believe it's safe (and good idea) to protect the code here. Though, it indicates that the RTP stack allow an invalidly timestamped stream to flow. We should try and prevent this higher in the stack.
Review of attachment 317601 [details] [review]: Good.
Thanks, pushing.