1

i've written a custom QtGStreamer appsink which is working fine. I'm in trouble trying to split with a tee the pipeline to process recording of the stream because the pipeline starts to preroll but never goes in playback state.

My pipeline:

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! appsink name="mysink"

If i comment any of the two tee branches anything works as expected.

This is also working:

souphttpsrc location="%1" ! queue ! tee name=tp tp.! queue ! tsdemux ! h264parse ! splitmuxsink muxer=mpegtsmux location=/tmp/rec/video%02d.mov max-size-time=60000000000 max-size-bytes=100000000 tp.! queue ! decodebin ! autovideosink

Why is my AppSink working just alone?

Gianks
  • 63
  • 1
  • 15

1 Answers1

0

Too big for comment..

How do you process appsink buffers? Its in main thread and you are getting the buffers by blocking calls or are you waiting on new-sample/new-preroll signals (which are non blocking - sort of push style)?

Check this for what I mean(the appsink chapter):

https://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/section-data-spoof.html

Is your application blocked?

I suspect(I may be wrong) that the appsink is blocked because it is flooded by many buffers.. the tee is very tricky element.. if one branch after tee wants to preroll for example 100 buffers then it causes the 100 buffers go to the other branch as well which may block for example appsink which blocks whole pipeline as you are waiting for playing state (or I dont know what you are doing in your app logic)..

You may try few things to get this sorted out:

  1. add drop=true to the appsink
  2. try adding queue parameter leaky=2 to test if it helps (very similar to 1, just different technique)
  3. Analyze debug logs as of which queue is first blocked. Use this env variable upon running your stuff GST_DEBUG=3,queue_dataflow:5 (I think it was 5 and I hope I remember the debug category for this correctly)
  4. Try changing splitmuxsink for fakesink which should never block - just to test who is the culprit.. if it helps it can also mean that the splitmuxsink is the one that is requesting so many buffers.
  5. In any case if I am all wrong you can debug with GST_DEBUG and setting levels 3,4,5 untill you find something interesting..
nayana
  • 3,787
  • 3
  • 20
  • 51
  • Hi and thanks for the reply. I'm using the newSample signal in my sink and since i needed to proceed i've changed approach using a second pipeline feeded by a custom appsource that's receiving a copy of the buffer from the sink on the primary pipeline. This is also making easier to handle the continous start/stop on the pipeline caused by the switch between recorded files. Anyway in the next days i'll try all of your suggestions since i wish to fix it to avoid to be restricted this way. – Gianks Jul 15 '16 at 21:24