splitmuxsink passing buffers in bursts

[Jan Schmidt]

Hi,

On 3/10/19 1:29 am, Bill Klein wrote:
> Hi Jan,
>
> First of all, thank you for the work on splitmuxsink! Truly
> useful/essential stuff.

Cheers! I'm always happy to hear about new use cases. It sounds like
you're doing something a bit different here?

> Just before I got your message I was looking through the source and
> saw what you said: It waits in order to avoid busting the segment size.
>
> This seems like a reasonable default, but it's a pity that it's not
> optional: I'm sure many people would prefer the tradeoff of busting
> the segment size slightly (i.e. by < 1GOP) with the benefit of not
> having to delay buffers getting to the sink.

That sounds like a useful low-latency mode. I'm not sure how difficult
it would be to implement without trying it. The assumption about
releasing 1 GOP at a time was baked in pretty early and may be implicit
in a bunch of annoying places.

- Jan.

>
> - Bill
>
>
> On Wed, Oct 2, 2019 at 11:23 AM Jan Schmidt <jan at widgetgrove.com.au
> <mailto:jan at widgetgrove.com.au>> wrote:
>
>     Hi,
>
>     On 2/10/19 11:34 pm, logidelic wrote:
>     > Hi Gruesse,
>     >
>     > Thank you for the response. I will investigate this, but it
>     doesn't quite
>     > make sense to me. I can certainly understand that the split
>     can't happen
>     > except at the end of a GOP, but aside from that why would
>     splitmuxsink be
>     > any different from any other mux/sink in its requirement to wait
>     for a
>     > complete GOP before passing to the muxer (in my case
>     matroskamux) sink?
>
>     Splitmuxsink needs to collect an entire GOP before releasing it to the
>     muxer so that it knows whether it will fit in the current file
>     fragment.
>     If it will overflow either the time or bytes limit, it needs to
>     start a
>     new file for that data.
>
>     - Jan.
>
>     >
>     > Thanks!
>     >
>     > Bill
>     >
>     >
>     >
>     > Thornton, Keith wrote
>     >> Hi,
>     >> In order to split properly I think you'll find that
>     splitmuxsink needs to
>     >> write complete GOPs. So it needs to collect gops before writing
>     them out.
>     >> Gruesse
>     >>
>     >> -----Ursprüngliche Nachricht-----
>     >> Von: gstreamer-devel <
>     >> gstreamer-devel-bounces at .freedesktop
>     >> > Im Auftrag von logidelic
>     >> Gesendet: Dienstag, 1. Oktober 2019 22:28
>     >> An:
>     >> gstreamer-devel at .freedesktop
>     >> Betreff: splitmuxsink passing buffers in bursts
>     >>
>     >> I have a pipeline which uses splitmuxsink to write to a file. I
>     noticed
>     >> immediately that, as opposed to filesink, the file only gets
>     updated in
>     >> (relatively) infrequent bursts, rather than regularly if using
>     a regular
>     >> filesink.
>     >>
>     >> This is not due to filesink's buffering mode: I tried them all
>     and it had
>     >> no effect.
>     >>
>     >> Just to be sure, I switched splitmuxsink to use an appsink
>     instead of a
>     >> filesink and, indeed, the appsink's new_sample callback is
>     called in
>     >> bursts, instead of being called regularly if we use a straight
>     appsink
>     >> without splitmuxsink.
>     >>
>     >> In case you were wondering I set the appsink's sync property to
>     FALSE.
>     >> Indeed, with all settings in the pipeline identical, except for the
>     >> existence of splitmuxsink, I see that with splitmuxsink buffers
>     arrive at
>     >> the final sink in bursts, whereas they arrive regularly otherwise.
>     >>
>     >> Any ideas what causes this and if there is a setting that can
>     fix it?
>     >> Getting the buffers in a timely manner is important in my case...
>     >>
>     >> Thank you!
>     >>
>     >>
>     >>
>     >> --
>     >> Sent from:
>     >>
>     https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgstreamer-devel.966125.n4.nabble.com%2F&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&reserved=0
>     >> _______________________________________________
>     >> gstreamer-devel mailing list
>     >> gstreamer-devel at .freedesktop
>     >>
>     https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&reserved=0
>     >> _______________________________________________
>     >> gstreamer-devel mailing list
>     >> gstreamer-devel at .freedesktop
>     >> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>     >
>     >
>     >
>     >
>     > --
>     > Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>     > _______________________________________________
>     > gstreamer-devel mailing list
>     > gstreamer-devel at lists.freedesktop.org
>     <mailto:gstreamer-devel at lists.freedesktop.org>
>     > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191003/ceab7c2a/attachment.html>