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 709415 - mp4mux: Expects and needs DTS on h264 but happily muxes streams without
mp4mux: Expects and needs DTS on h264 but happily muxes streams without
Status: RESOLVED DUPLICATE of bug 659489
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.2.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-10-04 08:31 UTC by Hans Månsson
Modified: 2013-10-10 13:13 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GST_DEBUG=*:5 (1.56 MB, application/x-gzip)
2013-10-04 08:31 UTC, Hans Månsson 		  Details
potential fix (940 bytes, patch)
2013-10-08 14:49 UTC, Hans Månsson 		needs-work Details | Review

Description Hans Månsson 2013-10-04 08:31:31 UTC 
Created attachment 256450 [details]
GST_DEBUG=*:5

I'm using the following pipeline to mux an h264 stream in to mp4,
./gst-launch-1.0 -e rtspsrc location="rtsph://..." ! rtph264depay ! h264parse ! mp4mux faststart=true ! filesink location=...
the resulting file ends up without duration, if i use matroskamux i get a druation.

This pipeline used to work in GStreamer 1.0.

I investigated the problem and it seems that all buffer handled by the mp4mux has DTS = -1 and a correct PTS. This yields gst_qt_mux_add_buffer () will set the buffer DTS = 0 and hence no duration.
Comment 1 Hans Månsson 2013-10-08 14:48:35 UTC 
I upload a possible fix, I do not know the correctness of the patch. I leave that up to you.
Comment 2 Hans Månsson 2013-10-08 14:49:17 UTC 
Created attachment 256741 [details] [review]
potential fix
Comment 3 Sebastian Dröge (slomo) 2013-10-09 17:21:39 UTC 
I don't think this is correct. For h264 you want DTS set on the buffers, otherwise you can't properly mux the stream into an MP4 container. In the worst case you'll have to invent DTS.
Comment 4 Hans Månsson 2013-10-09 18:59:47 UTC 
I suspected that, but the files turns out fine.

In Gstreamer 1.0 there was a property called dts-method which is deprecated in 1.2, do we need that again or just a way of inventing DTS? Any hints on how to achieve this?

Or is this a bug in some of the upstream elements since they do not set DTS on the buffers? Only the first buffer received by the rtph264depay sink pad has DTS all others has -1.

Well a lot of questions and rambling on my part but any help is much appreciated.
Comment 5 Sebastian Dröge (slomo) 2013-10-10 10:49:57 UTC 
I think h264parse should put proper DTS on the h264 buffers. I'm sure there's a bug about that already but I can't find it right now ;)
Comment 6 Hans Månsson 2013-10-10 13:04:50 UTC 
Found it: h264parse: Calculate PTS from DTS (and vice-versa) https://bugzilla.gnome.org/show_bug.cgi?id=659489
Comment 7 Sebastian Dröge (slomo) 2013-10-10 13:13:03 UTC 
Thanks!

*** This bug has been marked as a duplicate of bug 659489 ***