appsrc flushing, or decoder flushing

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

appsrc flushing, or decoder flushing

Ash 20001
I have a pipeline that takes in raw H264 frames, parses them and passed them to a HW OMX h264 Decoder using decodebin and then render to the scren:

gst-launch-1.0 -v filesrc location=out.264 ! h264parse ! decodebin ! xvimagesink

I have converted this pipeline into C++ code using appsrc as the source. The pipeline requires several frames before it actually start to output (around 7 frames by my calculations, depending on content). So if my appsrc is a live source, I can never seem to render the most up to date frame because it is always 7 frames behind. Is there a way to set something on the pipeline or flush the pipeline for live sources?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: appsrc flushing, or decoder flushing

Nicolas Dufresne-4
Le mardi 22 mars 2016 à 16:08 -0700, Ash 20001 a écrit :

> gst-launch-1.0 -v filesrc location=out.264 ! h264parse ! decodebin !
> xvimagesink
>
> I have converted this pipeline into C++ code using appsrc as the
> source. The pipeline requires several frames before it actually start
> to output (around 7 frames by my calculations, depending on content).
> So if my appsrc is a live source, I can never seem to render the most
> up to date frame because it is always 7 frames behind. Is there a way
> to set something on the pipeline or flush the pipeline for live
> sources?
H264 decoder element should expose their latency in order to work
properly in live mode. Did you verify that OMX decoder do that ? You
can always manually force a latency to get going. See
gst_pipeline_set_latency().

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: appsrc flushing, or decoder flushing

Ash 20001
I don't have gst_pipeline_set_latency as I am stuck on gstreamer 1.4.5 and can't change it due to embedded system.
Is there a way to use do_latency signal to do this?

Subject: Re: appsrc flushing, or decoder flushing
From: [hidden email]
To: [hidden email]
Date: Tue, 22 Mar 2016 19:52:43 -0400

Le mardi 22 mars 2016 à 16:08 -0700, Ash 20001 a écrit :

> gst-launch-1.0 -v filesrc location=out.264 ! h264parse ! decodebin !
> xvimagesink
>
> I have converted this pipeline into C++ code using appsrc as the
> source. The pipeline requires several frames before it actually start
> to output (around 7 frames by my calculations, depending on content).
> So if my appsrc is a live source, I can never seem to render the most
> up to date frame because it is always 7 frames behind. Is there a way
> to set something on the pipeline or flush the pipeline for live
> sources?

H264 decoder element should expose their latency in order to work
properly in live mode. Did you verify that OMX decoder do that ? You
can always manually force a latency to get going. See
gst_pipeline_set_latency().

Nicolas

_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel