splitmuxsink passing buffers in bursts

[Bill Klein]

I don't think my use-case is particularly special, I just need low latency
access to the real-time stream being output...

Actually, I know that hlssink2 makes use of splitmuxsink, so I assume it's
subject to the same problem/limitation: An unnecessary latency is
introduced. If people are trying to use hlssink2 for real-time live
broadcast (for example), they are getting handicapped...

- Bill


On Wed, Oct 2, 2019 at 11:45 AM Jan Schmidt <thaytan at noraisin.net> wrote:

> 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>
> 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
>> > 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/6faa2720/attachment-0001.html>