<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>I'm sorry this is another long post. There are some questions at the bottom that may be answerable without reading the whole post so just answering them would help me a bit.<br></div><div><br>Pipeline:<br><br></div>udpsrc -> queue -> rtpMP2TDepay -> TSDemux -> split into video and audio<br><br></div>video -> queue -> decodebin (H264Parse -> avdec_h264 -> deinterlace -> -> x264Enc -> rtph264pay -> rtpbin -> multiudpsink<br><br></div>audio -> queue -> decodebin (AacParse -> avdec_aac_latm) -> audioconvert -> audioresample -> VoAacEnc -> rtpMP4GPay -> rtpbin -> multiudpsink<br><br></div>The problem is that after many hours the audio rtp packets are ahead of the video rtp packets. (i.e. when a client connects the video and audio are immediately out of sink).<br><br></div>I added pad probes between the following elements:<br><br></div>VPad1: tsdemux video src pad -> video queue<br></div>VPad2: video queue -> decodebin<br></div>VPad3: rtpbin -> video multiudpsink<br><br></div>APad1: tsdemux audio src pad -> audio queue<br></div>APad2: audio queue -> decodebin<br></div>APad3: rtpbin -> audio multiudpsink<br><br></div>Each pad callback records the timestamp of the current buffer (relative to the segment start time) and every 30 seconds I dump the last recorded timestamp of each pad to a file.<br><br></div><div>The input is a TS stream so the TSDemux is being fed with synchronised audio and video.<br></div><div><br></div>When video and audio are in sink the timestamps look like this (all times in ms and the latency at the two sinks is 900ms):<br></div><span style="font-family:monospace,monospace">Clock time 90321<br></span></div><span style="font-family:monospace,monospace">VPad1: 91157     APad1: 90333<br></span></div><span style="font-family:monospace,monospace">VPad2: 89677</span>          <font face="monospace,monospace">APad2: 89437<br></font></div><font face="monospace,monospace">VPad3: 89437     APad3: 89416<br><br></font></div><font face="monospace,monospace"><font face="arial,helvetica,sans-serif">I don't know why VPad1 and APad1 are ~800ms apart as I would have thought the timestamps coming out of TSDemux would be the same, however it works so we'll ignore that.<br><br></font></font></div><div><font face="monospace,monospace"><font face="arial,helvetica,sans-serif">The timestamp of the video buffer coming out of the queue (VPad2) is later than the timestamp of the audio buffer coming out of the audio queue (APad2) which is expected as the video transcoder has more latency than the audio transcoder.<br><br></font></font>The time between VPad2 and VPad3 is around 240ms and between APad2 and APad3 is around 21ms suggesting it takes 240ms to transcode a video buffer and 21ms to transcode an audio buffer (to be expected as video takes more work and audio).<br></div><font face="monospace,monospace"><font face="arial,helvetica,sans-serif"><br></font></font></div><font face="monospace,monospace"><font face="arial,helvetica,sans-serif">Adding the latency to VPad3 and APad3 gives the current clock time (near enough) and the buffers are due for dispatch to the network.<br><br></font></font></div><font face="monospace,monospace"><font face="arial,helvetica,sans-serif">Several hours later the audio and video are out of sync and the times are as follows:<br></font></font><span style="font-family:monospace,monospace">Clock time 81390143<br></span><span style="font-family:monospace,monospace">VPad1: 81390803     APad1: 81390154<br></span><span style="font-family:monospace,monospace">VPad2: 81389483 </span>        <font face="monospace,monospace">APad2: 81390026<br></font><font face="monospace,monospace">VPad3: 81389243     APad3: 81389237<br></font><br>Now things have switched around and the buffer coming from the audio queue (APad2) is much later than the buffer coming out of the video queue (VPad2). This is weird as we know the latency of the video transcoder is about 10x larger than the audio transcoder.<br><br></div><div>Now between pads APad2 and APad3 there appears to be a latency of 789ms compared to 21ms before suggesting it is now taking 789ms to transcode an audio buffer.<br><br></div><div>However, I don't believe this is the case. My theory is that the audio transcode is still taking just 21ms to transcode the packet but for some reason is modifying the timestamp i.e. it takes a buffer has a timestamp 789ms in the future, transcodes it in 21ms and then deducts the 768ms from buffer causing the sink to send the packet immediately. The audio is now 768ms <i>ahead</i> of the video at the client which is about what I see at VLC.<br><br></div><div>The input TS stream is an on-air broadcast and so is subject to errors. I have GST_DEBUG=2 and do see some errors in both the video and audio. The audio errors are in gstavauddec so I guess it fails to decode some packets and then one of the downstream elements fails to detect a missing audio packet and rather than checking the buffer timestamp it starts sucking future packets from the audio queue.<br><br></div><div>***News just in***<br><br></div><div>I've left the whole pipeline running since I noticed it was out of sync (about 3 hours ago) and while writing this that video and audio synchronisation has restored itself. Looking in the statistics I noticed that 24 minutes ago the audio queue (between tsdemux and the transcoder) emptied completely (0 buffers in the queue). After that the buffer timestamps are back to the expected values (e.g. like my first example above).<br><br></div><div>This may suggest a way to solve it:<br></div><div>When I detect the timestamps are out of sync, could I put a blocking pad probe on the audio then send an EOS through the transcoder elements, then unblock the pad again? But when would I unblock the pad again? And would this put the downstream elements in the wrong state?<br><br></div><div>Does anyone have a better way to solve it?<br><br></div></div>