GNOME Bugzilla – Bug 758932
RTSP server not compatible with mp4mux over TCP connection
Last modified: 2015-12-02 11:50:47 UTC
So I *think* this has to do with DTS not being carried over the stream *and* outstanding issues with missing DTS in qtmux/h264parse. This bug is about the former. So, my setup. I built the gst-rtsp-server with recipe with the examples enabled. Setting up the server as follows: ./test-launch "( videotestsrc is_live=true ! x264enc ! video/x-h264,width=1296,height=972,framerate=25/1 ! h264parse ! rtph264pay pt=96 name=pay0 )" And then, same machine, the client (using git master): ./gst-launch-1.0 -e rtspsrc location=rtspt://127.0.0.1:8554/test ! rtph264depay ! h264parse ! mp4mux ! filesink location=~/Downloads/localtest1.mp4 With location=rtspt://127.0.0.1:8554/test I get an unplayable mp4 file. With location=rtsp://127.0.0.1:8554/test the mp4 plays fine. I need to debug further whether DTS is the issue for sure. But at least this is hopefully a reproducible bug for you.
Check after h264parse in gst-launch-1.0 if the buffers have timestamps. You could e.g. use a fakesink right after the parser, set silent=false on it and use -v with gst-launch-1.0. You'll then see each buffer metadata printed on stdout. There you'll see that a DTS is provided, and also a PTS. The DTS in the case of RTP is the capture timestamp of the packet, the PTS the calculated presentation time. Sometimes PTS > DTS with this. What exactly is the problem you're observing here?
Thanks for the filesink tip. As I suspected - with TCP the DTS is none and on UDP it is slightly higher than the pts, but basically identical. UDP: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (10415 bytes, dts: 0:00:05.200720931, pts: 0:00:05.195787233, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fb4bb8360a0 TCP: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = chain ******* (fakesink0:sink) (10189 bytes, dts: none, pts: 0:00:05.454835028, duration: none, offset: -1, offset_end: -1, flags: 00002000 delta-unit ) 0x7fdd7413f0a0 The problem I'm observing is that I get a corrupted mp4 file. Which would be fixed by any of: 1. rtsp over TCP carries DTS 2. h264parse handles missing DTS (a known, non-trivial bug) 3. qtmux handles missing DTS This bug is about (1).
After speaking to Sebastian, I've established that this isn't a bug because over UDP it doesn't actually pass the timestamp: > for UDP it's just the packet capture timestamp. for TCP we only set that for the very first packet we receive as TCP is not a "live" protocol So I'm closing this and focussing on the qtmux problem