Avoiding stall in a transcoding pipeline - how?

[Graham Leggett]

On 11 Jun 2017, at 10:15 PM, Graham Leggett <minfrin at sharp.fm> wrote:

> I have a transcoding pipeline that consists of a decodebin that is dynamically wired into an encodebin. When there is only video accepted by encodebin, the pipeline works fine. When both video and audio are accepted by encodebin, the pipeline stalls.
> 
> Sometimes the stall is almost immediate, sometimes the stall happens after minutes, rarely the pipeline will stall after some hours.
> 
> The source for the pipeline is a live DVB stream, complete with errors, discontinuities, glitches, you name it - real life dirty data.
> 
> Can anyone explain to me what elements need to be in the audio and video pipelines that will prevent the pipeline from stalling when dirty data is being processed?
> 
> What specifically do these elements do that causes the stall to be prevented?
> 
> (I am specifically after the HOW to avoid anti-stall. Google is crammed full of recommendations of various pipelines to try, but none of them explain how they work, or even if they’re correct).

I created two patches to improve this.

The first allows you to get a dot file snapshot of the pipeline state by sending a SIGHUP to the gst-launch-1.0 process. This allows you to see the pipeline during the hang, not just during the state changes. In my case the branch handling audio had successfully linked but refused to negotiate, and this was obvious from the snapshot, but not obvious from the logs.

https://bugzilla.gnome.org/show_bug.cgi?id=783661

The second patch exposes the PTS/DTS value of the beginning and the end of a queue, a parameter called the “position”. The difference between these values is the size in time of the queue. By seeing these values directly, you can tell the difference between a queue that has seen data and is currently empty, a queue that has never seen data ever because it is starved, and is currently empty. You can also tell the difference between a queue that has had data successfully flow through it but it is currently full, and a queue that has never had data come out of it because of a stall, and is currently full.

https://bugzilla.gnome.org/show_bug.cgi?id=783667

Regards,
Graham
—

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3240 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170614/11efd8a2/attachment.bin>