Avoiding stall in a transcoding pipeline - how?

Graham Leggett minfrin at sharp.fm
Wed Jun 14 09:58:24 UTC 2017


On 14 Jun 2017, at 6:19 AM, Baby Octopus <jagadishkamathk at gmail.com> 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
—

-------------- 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/eb36ba0f/attachment.bin>


More information about the gstreamer-devel mailing list