1 year ago

#383506

test-img

PierreYves

GStreamer AppSrc AppSink latency

I'm would like to use GStreamer to decode an H264 frame. My pipeline looks like this:

appsrc name=source  max-buffers=1 ! video/x-h264,  framerate=10/1, stream-format=byte-stream ! h264parse name=parser ! video/x-h264, profile=baseline, width=320, height=240 ! nvh264dec name=decoder ! appsink name=sink max-buffers=1 drop=TRUE

AppSrc is configuref in push mode. I have an enconding thread that pushes H264 frames appsrc. At the end of the pipeline, I receive the decoded frame through AppSink. This works well except I have a latency between the time the frame is pushed to the pipeline and the time it reaches AppSink. More precisely I noticed that:

  • the sink always receives the first frame after the 6th frame has been pushed to the source.
  • the sink and all upstreams element receive a "latency" event after the 6th frame has been pushed to the source.
  • the pipeline state changes from READY to PAUSED just after the latency event
  • the pipeline state changes from PAUSED to PLAYING just after the source receive the latency event, ie just before the sink receives the first frame.

So the timeline looks like this (with an enconding thread at 10 fps):

Time (ms) AppSrc AppSink
0 Frame 1
100 Frame 2
200 Frame 3
300 Frame 4
400 Frame 5
500 Frame 6 Frame 1
600 Frame 7 Frame 2
700 Frame 8 Frame 3
800 Frame 9 Frame 4

etc ...

It seems the delay is directly linked to the size of the pipeline. I removed the decoder in order to test this hypothesis (of course it doesn't make sense from a functional point of view):

appsrc name=mysource  max-buffers=1 ! video/x-h264,  framerate=10/1, stream-format=byte-stream ! h264parse name=parser ! appsink name=sink max-buffers=1 drop=TRUE sync=FALSE

With this shrinked pipeline, I receive the first frame in the sink, after the third frame has been pushed.

I would like to receive the first frame in the sink a soon as it is pushed to the pipeline. Actually the input framerate is not that important for me. The latency is the key point. I'm even ready to consider a solution where the encoding thread is blocked until the frame reaches the sink before pushing a new one.

Any help would be greatly appreciated.

Regards, PY

c++

gstreamer

0 Answers

Your Answer

Accepted video resources