After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759615 - DTS > PTS creates invalid mp4 files
DTS > PTS creates invalid mp4 files
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.7.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-12-18 04:57 UTC by Jan Schmidt
Modified: 2016-01-27 10:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
qtmux: Don't write invalid edit list start time. (1.20 KB, patch)
2015-12-18 04:57 UTC, Jan Schmidt
committed Details | Review

Description Jan Schmidt 2015-12-18 04:57:00 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.
Comment 1 Jan Schmidt 2015-12-18 04:57:29 UTC
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.
Comment 2 Nicolas Dufresne (ndufresne) 2015-12-18 13:40:10 UTC
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.
Comment 3 Nicolas Dufresne (ndufresne) 2015-12-18 13:40:52 UTC
Review of attachment 317601 [details] [review]:

Good.
Comment 4 Jan Schmidt 2015-12-18 16:49:09 UTC
Thanks, pushing.