splitmuxsink passing buffers in bursts
Jan Schmidt
thaytan at noraisin.net
Fri Oct 4 07:22:42 UTC 2019
On 4/10/19 4:04 am, Bill Klein wrote:
> I don't think my use-case is particularly special, I just need low
> latency access to the real-time stream being output...
Does that have to be from the fragments being written to disk? You could
insert a tee and stream a parallel feed using a lower-latency method
like RTSP.
>
> 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...
HLS is one of the cases where you aren't allowed to overrun the fragment
time listed in the manifest, so you'd have to control the GOP size and
factor that in to the reported fragment size to make the whole thing
work without the additional latency.
HLS isn't designed for such low-latency access in any case - fragments
are typically ~10 seconds and not published to the manifest until you
finish writing them out, at least that way GStreamer does it.
- Jan.
>
> - Bill
>
>
> On Wed, Oct 2, 2019 at 11:45 AM Jan Schmidt <thaytan at noraisin.net
> <mailto: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 <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
>> <mailto:gstreamer-devel-bounces at .freedesktop>
>> >> > Im Auftrag von logidelic
>> >> Gesendet: Dienstag, 1. Oktober 2019 22:28
>> >> An:
>> >> gstreamer-devel at .freedesktop
>> <mailto: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
>> <mailto: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
>> <mailto: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/20191004/db2e3378/attachment.html>
More information about the gstreamer-devel
mailing list