Bytestream or sample jitterbuffer

Peter Maersk-Moller pmaersk at
Thu Jan 27 19:38:00 UTC 2022

Hi Nicolas

Thx for taking the time

On Thu, Jan 27, 2022 at 8:12 PM Nicolas Dufresne <nicolas at>

> Somewhat your pipeline is live, or can be made live. One way to reach this
> effect, could be to place clocksync element after your parser (since you
> need
> timeinformation). This will make you pipeline live, and then you can
> control the
> amount of jitter you allow with the processing-deadline properly for the
> "real
> sink", and ts-offset on the clocksync (or something along these line).

Ok so clocksync adds timestamp and we can wait start until first sample. I
thought audiorate also did this?
And is it still the case that fdsrc do-timestamp=true" does not actually
add a timestamp?

Ok so now we have timestamped bytestream (audio or not does not matter)
andwe can add a ts offset, even negative if needed.

But how does the processing dead-line work. If we set that to lets say
100ms, does it mean that the sink (lets use alsasink as a case study), does
start process and output the first sample until after 100ms and
subsequently on average, any sample received after that can be up to 100ms
delayed accoding to a prefect stream thus in effect have a jitterbuffer of
100ms. Is that what you mean and how it works?

Thanks for taking the time.

Peter Maersk-Moller

> > Thanks in advance.
> > Peter Maersk-Moller
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the gstreamer-devel mailing list