best way to flush data in sink/queue

[Mailing List SVR]

Hi,

I have to receive and playback a network stream, it basically works
fine, I have a pipeline that receive audio and video and ends with
something like this:

... ! queue ! videosink
... ! queue ! audiosink

sometime, when the stream start, the server sends about 10 seconds of
data in one second of time. Since video and audio are played synced on
the clock a delay is introduced. This is supposed to be a live stream
even if it sometimes behaves in this strange way.

I can see that the queues overrun when the data arrives very fast and I
would like to flush the queued data (from the queue and/or the sink)
when this happen so I can play real time data, old data can be dropped
in my use case. What is the best way to flush old data? After some
searchs and looking at the code it seems that I can send a flush_stop
event, are there better ways?

Of course I can manually handle this situation using appsink/appsrc and
dropping data in appsink when the queue overrun and/or do something
similar in a pad probe but I would like to avoid this manual handling if
possibile,

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

[Mailing List SVR]

A simple solution seems to set a negative ts_offset on the sink based on
the queue time level,

this seems the less hacky solution,

I have yet to fully understand what the max-lateness property really do
and because its default value is -1 for audio sink and 20000000 for
video sinks, I suppose I have to read the code :)

Nicola

Il 02/10/2017 16:40, Mailing List SVR ha scritto:

> Hi,
>
> I have to receive and playback a network stream, it basically works
> fine, I have a pipeline that receive audio and video and ends with
> something like this:
>
> ... ! queue ! videosink
> ... ! queue ! audiosink
>
> sometime, when the stream start, the server sends about 10 seconds of
> data in one second of time. Since video and audio are played synced on
> the clock a delay is introduced. This is supposed to be a live stream
> even if it sometimes behaves in this strange way.
>
> I can see that the queues overrun when the data arrives very fast and
> I would like to flush the queued data (from the queue and/or the sink)
> when this happen so I can play real time data, old data can be dropped
> in my use case. What is the best way to flush old data? After some
> searchs and looking at the code it seems that I can send a flush_stop
> event, are there better ways?
>
> Of course I can manually handle this situation using appsink/appsrc
> and dropping data in appsink when the queue overrun and/or do
> something similar in a pad probe but I would like to avoid this manual
> handling if possibile,
>
> thanks
> Nicola
> _______________________________________________
> 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

[Tim Müller]

On Mon, 2017-10-02 at 19:23 +0200, Mailing List SVR wrote:

> I have yet to fully understand what the max-lateness property really
> do and because its default value is -1 for audio sink and 20000000
> for video sinks, I suppose I have to read the code :)

If set, it will render buffers that arrive up to $max_lateness late at
the sink. For video sinks that's 20ms by default, so about half a frame
at 25fps and a frame at 50fps. Frames later than that will be dropped
and not rendered.

Audiosinks work differently and will by default just put samples behind
the previous samples, unless there's a discont or the actual position
diverged too much from where it should be. There are other properties
to fine-tune the behaviour (alignment-threshold, drift-tolerance).

--
Tim Müller, Centricular Ltd - http://www.centricular.com

Join us at the GStreamer Conference!
21-22 October 2017 in Prague, Czech Republic
http://gstreamer.freedesktop.org/conference/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

In case it wasn't clear from my explanation, the difference between
max-lateness and ts-offset is that the ts-offset is applied
unconditionally and changes the actual output position for all buffers,
whereas max-lateness only allows some slack for late buffers (which
will then be rendered asap).

--
Tim Müller, Centricular Ltd - http://www.centricular.com

Join us at the GStreamer Conference!
21-22 October 2017 in Prague, Czech Republic
http://gstreamer.freedesktop.org/conference/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lundi 02 octobre 2017 à 19:23 +0200, Mailing List SVR a écrit :

> A simple solution seems to set a negative ts_offset on the sink based
> on
> the queue time level,
>
> this seems the less hacky solution,
>
> I have yet to fully understand what the max-lateness property really
> do
> and because its default value is -1 for audio sink and 20000000 for
> video sinks, I suppose I have to read the code :)

It's a tolerance to lateness, a frame can be 20ms late and it will
still be rendered. This is a bit of a hack in my opinion, but for
videosink, this value should be the duration of a frame more or less.

It basically account for the processing latency, which can be has high
as one frame duration and still be real-time. But it also has the side
effect of accepting some jitter. I don't think that in practice it is
that negative, since the stream clock isn't aligned with the display
clock. The display itself already introduce similar jitter (+- 16.667ms
on 60fps display).

Starting with wayland, with the presentation time extension, we can
measure the latency and schedule frame to a specific blank, so this
jitter is no longer visible, even though the tolerance to lateness is
still needed because the closest refresh might be 1 millisecond ahead
of the presentation time.

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

[Mailing List SVR]

Il 02/10/2017 19:52, Tim Müller ha scritto:
> In case it wasn't clear from my explanation, the difference between
> max-lateness and ts-offset is that the ts-offset is applied
> unconditionally and changes the actual output position for all buffers,
> whereas max-lateness only allows some slack for late buffers (which
> will then be rendered asap).
>

OK, thanks, so in my case only ts-offset is needed,

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