Avoiding stall in a transcoding pipeline - how?
Locked
Avoiding stall in a transcoding pipeline - how?
 
|
Hi all,
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). Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
smime.p7s (4K)
Re: Avoiding stall in a transcoding pipeline - how?
|
|
On 11 Jun 2017, at 10:15 PM, Graham Leggett <[hidden email]> 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). 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 — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Avoiding stall in a transcoding pipeline - how?
|
Administrator
|
Re: Avoiding stall in a transcoding pipeline - how?
|
|
On 14 Jun 2017, at 6:19 AM, Baby Octopus <[hidden email]> wrote:
> There is no hard and fast rule to make the pipeline bullet proof! It entirely > depends on the type of stall that you see and the reason for it, whether it > is internal issue due to the pipeline itself, or caused by dirty input that > you are referring to Obviously, however seeing the state of the pipeline and where the data is stuck will lead you right to the problem, and then you can fix it and move on. > Can you explain the scenarios where you the stall and sample input with the > pipeline on how to reproduce it? The pipeline consists of a decodebin wired into an encodebin, which transcodes an mpegts containing video and audio at 44.1khz. The pipeline is successfully linked, but 44.1k audio refuses negotiation and the pipeline stalls. Ignoring the 44.1khz audio and transcoding a parallel 48khz stream works. I have not got to the bottom of that problem yet, but I now know it exists and can avoid it for now. There was also an attempt to dump a subtitle stream to fakesink, and that was blocking due to the length-in-time of the queue. Making that queue leaky unblocked that part of the pipeline. Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: Avoiding stall in a transcoding pipeline - how?
|
Administrator
|
Pipeline negotiation issue should be easy to debug. Have you enabled -v verbose mode. Do you see a particular element exposing caps which the next element may not support? ~BO On Wed, Jun 14, 2017 at 3:27 PM, Graham Leggett [via GStreamer-devel] <[hidden email]> wrote: On 14 Jun 2017, at 6:19 AM, Baby Octopus <[hidden email]> wrote: |
smime.p7s (4K)
Re: Avoiding stall in a transcoding pipeline - how?
|
|
On 14 Jun 2017, at 1:32 PM, Baby Octopus <[hidden email]> wrote:
When you have a trivial static pipeline, sure. When you have a complex dynamic pipeline that is constructed on the fly based on the contents of the stream (and each stream has a different structure), and you end up with a pipeline of 69 elements in total, no, it is not easy to debug. Yes, we have used and have been completely swamped by the debug mode. What worked was to to analyse the status of the queues. As soon as we could see which queues were seeing data but empty, which queues were stuck, which queues had never seen data at all, the problem became obvious. Anyway, for the purposes of people arriving here in future from Google, use the patches I posted to see the status of the queues, you will in turn be able to explain whether a pipeline is legitimately stuck and why. Regards, Graham — _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
| Free forum by Nabble | Edit this page |