GNOME Bugzilla – Bug 681605
[tsdemux/udp] Playback quality degrades over time (timestamp issues ?)
Last modified: 2013-08-13 14:36:24 UTC
This seems to be repeatable and with roughly the same pattern so it's quite interesting. Could be the new TS demuxer at fault. I was playing a BBC THREE DVB-T stream (so MPEG-2 video and mp2 audio) from the network (UDP, localhost unicast). Playback initially starts OK with some QOS messages (dropped frames) from various elements for a few seconds right after startup (it was like this even with the old TS demuxer) but then it completely fine for approx. 26 minutes. At 26-27 minute mark since start of playback a single QOS message appears with xvimagesink dropping a frame. Then between 35-37 minute mark we get more dropped frames every couple of seconds, or a couple of times per seconds, in clusters with some clean time in between. Then between 40-45 minute mark dropped frames become frequent and constant. Something like one to three times per seconds, almost on every second. Component versions in use are roughly: gstreamer-0.10.36.1-git120808.955693fc36ac38dc604e1e616e1c441cc3c25e1c -ffmpeg-0.10.13.1-git120808.1db8779252afa264996e59c18430f70cc5582b28 -base-0.10.36.1-git120808.12ef907f8a3762685da0b96391edc30a78d31805 -bad-0.10.23.1-git120808.e3b09c25b16c42ca7a83472c61054f34a31f572c -ugly-0.10.19.1-git120808.afeffcdb44135c04c5767bba8b10fab82ec9a9df -good-0.10.31.1-git120808.c1f1b62ca26106fba30fca65b0945c31da0ffe22
I wonder if the demuxer retimestamps based on the input timestamps from udpsrc and the in-stream timestamps to make up for source/receiver drift.
hi, I am using gstreamer version 1.0.4. I am also seeing similar kind of symptoms in my pipeline. Any updates on this bug. my pipeline is given below. gst-launch-1.0 udpsrc port=<in port> ! decodebin ! deinterlace mode=0 fields=1 method=4 tff=0 ! tee ! queue ! videoconvert ! videoscale ! video/x-raw,width=640,height=360 ! x264enc ! mpegtsmux ! udpsink host=<hostip> port=<port> I have given clear details of the input stream I am getting. Hope I will get some ideas on this bug. TS FILE DETAILS: ======================================================== Format : MPEG-TS Overall bit rate : 8 237 Kbps VIDEO ------------------------------------------------------- ID : 1002 (0x3EA) Menu ID : 1200 (0x4B0) Format : AVC Format/Info : Advanced Video Codec Format version : Version 2 Format profile : Main@L4.0 Format settings, CABAC : Yes Format settings, ReFrames : 4 frames Codec ID : 27 Bit rate : 7 312 Kbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 25.000 fps Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Interlaced Scan order : Top Field First Bits/(Pixel*Frame) : 0.141 Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177 Transfer characteristics : BT.709-5, BT.1361 Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177 Audio #1 ------------------------------------------------------- ID : 1003 (0x3EB) Menu ID : 1200 (0x4B0) Format : MPEG Audio Format version : Version 1 Format profile : Layer 2 Codec ID : 4 Bit rate mode : Constant Bit rate : 128 Kbps Channel(s) : 2 channels Sampling rate : 48.0 KHz Compression mode : Lossy Delay relative to video : -630ms Language : English Audio #2 ------------------------------------------------------- ID : 1004 (0x3EC) Menu ID : 1200 (0x4B0) Format : AC-3 Format/Info : Audio Coding 3 Format profile : Layer 2 Mode extension : ME (music and effects) Format settings, Endianness : Big Codec ID : 6 Bit rate mode : Constant Bit rate : 384 Kbps Channel(s) : 6 channels Channel positions : Front: L C R, Side: L R, LFE Sampling rate : 48.0 KHz Bit depth : 16 bits Compression mode : Lossy Delay relative to video : -781ms Stream size : 4.65 MiB (5%) Language : Hindi Thanks in advance JasonP
JasonP, please open a separate bug for this, you're using a completely different GStreamer version, and you also have an encoder and muxer in your pipeline, and stream things out again..
Hi Tim, I agree your point. But even in my case I am seeing similar kind of behaviour. So I thought of putting it here. And for your information I am getting this issue without muxer also. Thanks for your reply. regards JasonP
This is indeed most likely related to the "remote-clock estimation and correction" code in mpegtspacketizer. It would help if someone could provide some long running logs with only the debug sections related to clock evaluation in it. I.e. bump all debug statements in mpegtspacketizer calculate_skew to GST_WARNING, recompile and run it with GST_DEBUG=2 (so we also get the messages from when the sink/clocks are complaining). That should result in a log file containing all the relevant information to debug this further. (Note 0.10 or 1.0 shouldn't change anything, that code hasn't changed afaik)
I've left a DVB stream go on for over an hour and got some logs. While I don't get the visual artefacts mentionned, there are indeed baseaudiosink warnings around 34-37mins. I'll investigate them to see if something obvious comes up.
Actually, after looking at my logs again, I cannot see anything wrong ... except that the remote sending rate changed (from a slope (local clock vs remote clock) of 0.999993 to 0.999997 within a few seconds). That being said, the channel changed between from a movie to a "live" tv show around that time, so my guess is that was the reason. Anyway, I didn't observe the consistent dropping frame issue mentionned in comment #1. I wasn't watching the stream all the time (listening to it in the background) but whenever I looked at it I didn't see any loss, stream looked fine. So I still need some other logs as mentionned in comment #5.
A thought occured .... ... is that intermediary DVB=>UDP machine doing anything fancy/weird with the PCR ? :)
Created attachment 250748 [details] mpegpacketizer dump Hi, Here is the dump that I could get. Here is my pipeline gst-launch-1.0 --gst-debug=mpegtspacketizer:2 udpsrc uri=udp://239.0.0.11:9920 multicast-iface=eth1 ! decodebin ! video/x-raw ! checksumsink I see video timestamp having an issue right from the beginning. And it is a multicast stream. Same stream when I play through VLC or capture it elsewhere, they play perfectly fine. Let me know if I can get more dumps ~BO
Created attachment 250749 [details] Mpegpacketizer logs Hi, Here is the dump that I could get. Here is my pipeline gst-launch-1.0 --gst-debug=mpegtspacketizer:2 udpsrc uri=udp://239.0.0.11:9920 multicast-iface=eth1 ! decodebin ! video/x-raw ! checksumsink I see video timestamp having an issue right from the beginning. And it is a multicast stream. Same stream when I play through VLC or capture it elsewhere, they play perfectly fine. Let me know if I can get more dumps ~BO
Baby Octopus: No idea where that stream comes from ... but it's busted (or rather the producer is). Essentially PCR received at any given point in time varies way too much, which makes me think the sender is wrong (i.e. data is not pushed out at a PCR constant rate). Tvrtko Ursulin: Any chance you can provide one from your device ?
Closing bug. Tvrtko, if you can reproduce the logs with gstreamer 1.x, please include them and re-open the bug.