GNOME Bugzilla – Bug 587680
rtp/ts does not repackage cleanly to rtp; mpegvideoparse/rtpmpvpay: timing issues
Last modified: 2009-07-17 10:50:18 UTC
Please describe the problem: The video is received from a RTP/TS source and is repackaged to a RTP: Converting RTP/TS to RTP: gst-launch udpsrc multicast-group=226.255.0.34 port=50100 caps="application/x-rtp,clock-rate=(int)90000" ! gstrtpjitterbuffer ! gstrtpptdemux ! rtpmp2tdepay ! mpegtsdemux ! queue2 ! mpegvideoparse ! rtpmpvpay pt=32 ! udpsink host=226.226.120.226 port=2266 Listening to RTP: gst-launch udpsrc -v multicast-group=226.226.120.226 port=2266 caps="application/x-rtp,clock-rate=(int)90000" ! gstrtpjitterbuffer ! gstrtpptdemux ! rtpmpvdepay ! mpeg2dec ! ffmpegcolorspace ! autovideosink The video is very jerky. When using e.g. VLC it spews errors: [00000409] main decoder warning: decoder synchro warning: pts != current_date (-160267) [00000415] main video output warning: late picture skipped (76259) [00000409] main decoder warning: decoder synchro warning: pts != current_date (120011) [00000409] main decoder warning: backward_pts != current_pts (79989) [00000409] main decoder warning: decoder synchro warning: pts != current_date (-199989) [00000409] main decoder warning: decoder synchro warning: pts != current_date (120000) [00000415] main video output warning: late picture skipped (30419) [00000409] main decoder warning: backward_pts != current_pts (120000) Steps to reproduce: cf. supra Actual results: cf.supra Expected results: cf. supra` Does this happen every time? yes Other information:
Skipping the RTP header provides clean video: gst-launch udpsrc uri=udp://226.226.221.226:2266 skip-first-bytes=16 ! queue2 ! mpegvideoparse ! decodebin ! autovideosink
got some improvement; still not perfect working on a patch for rtpmpvpay.c.
Created attachment 138337 [details] [review] Rework timestamping Using the original gstrtpmpvpay.c and VLC 0.9.8a (Grishenko); streaming from a networked source and payloading it as described; produces a 'jerky' image: the decoded order is off. By modeling the timestamping on gstrtpmp4vpay.c; the decoded images are more smooth; especially the correction in: if (gst_basertppayload_is_filled (basepayload, packet_len, rtpmpvpay->duration + duration)) { ret = gst_rtp_mpv_pay_flush (rtpmpvpay); rtpmpvpay->first_ts = timestamp; rtpmpvpay->duration = 0; }
commit 7484b631b7dc7f181bc014702cb9967745241436 Author: Marc Leeman <marc.leeman at gmail.com> Date: Mon Jul 13 17:53:25 2009 +0200 mpvpay: Rework the timestamping Rework the timestamping in the mpv payloader so that the timestamps are more accurate. Fixes #587680
Created attachment 138581 [details] gst-plugins-good0.10-0.10.15 modified file For some reason (probably me using a git from february), the patch I sent applied against 0.10.15 good plugins produced a bogus/corrupt file. I am attaching the (full) correct 0.10.15 modified C file (tested to work). You might have caught this during integration of my patch this week. br.