<div dir="ltr"><div>I don't think my use-case is particularly special, I just need low latency access to the real-time stream being output...</div><div><br></div><div>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...</div><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Bill</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 11:45 AM Jan Schmidt <<a href="mailto:thaytan@noraisin.net">thaytan@noraisin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,<br>
</p>
<div>On 3/10/19 1:29 am, Bill Klein wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Jan,
<div><br>
</div>
<div>First of all, thank you for the work on splitmuxsink! Truly
useful/essential stuff.</div>
</div>
</blockquote>
<p>Cheers! I'm always happy to hear about new use cases. It sounds
like you're doing something a bit different here?<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<p>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.</p>
<p>- Jan.<br>
</p>
<blockquote type="cite">
<div dir="ltr">
<div><br clear="all">
<div>
<div dir="ltr">- Bill</div>
</div>
<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Oct 2, 2019 at 11:23
AM Jan Schmidt <<a href="mailto:jan@widgetgrove.com.au" target="_blank">jan@widgetgrove.com.au</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On 2/10/19 11:34 pm, logidelic wrote:<br>
> Hi Gruesse,<br>
><br>
> Thank you for the response. I will investigate this, but
it doesn't quite<br>
> make sense to me. I can certainly understand that the
split can't happen<br>
> except at the end of a GOP, but aside from that why would
splitmuxsink be<br>
> any different from any other mux/sink in its requirement
to wait for a<br>
> complete GOP before passing to the muxer (in my case
matroskamux) sink?<br>
<br>
Splitmuxsink needs to collect an entire GOP before releasing
it to the<br>
muxer so that it knows whether it will fit in the current file
fragment.<br>
If it will overflow either the time or bytes limit, it needs
to start a<br>
new file for that data.<br>
<br>
- Jan.<br>
<br>
><br>
> Thanks!<br>
><br>
> Bill<br>
><br>
><br>
><br>
> Thornton, Keith wrote<br>
>> Hi, <br>
>> In order to split properly I think you'll find that
splitmuxsink needs to<br>
>> write complete GOPs. So it needs to collect gops
before writing them out.<br>
>> Gruesse<br>
>><br>
>> -----Ursprüngliche Nachricht-----<br>
>> Von: gstreamer-devel <<br>
>> <a href="mailto:gstreamer-devel-bounces@.freedesktop" target="_blank">gstreamer-devel-bounces@.freedesktop</a><br>
>> > Im Auftrag von logidelic<br>
>> Gesendet: Dienstag, 1. Oktober 2019 22:28<br>
>> An: <br>
>> <a href="mailto:gstreamer-devel@.freedesktop" target="_blank">gstreamer-devel@.freedesktop</a><br>
>> Betreff: splitmuxsink passing buffers in bursts<br>
>><br>
>> I have a pipeline which uses splitmuxsink to write to
a file. I noticed<br>
>> immediately that, as opposed to filesink, the file
only gets updated in<br>
>> (relatively) infrequent bursts, rather than regularly
if using a regular<br>
>> filesink.<br>
>><br>
>> This is not due to filesink's buffering mode: I tried
them all and it had<br>
>> no effect.<br>
>><br>
>> Just to be sure, I switched splitmuxsink to use an
appsink instead of a<br>
>> filesink and, indeed, the appsink's new_sample
callback is called in<br>
>> bursts, instead of being called regularly if we use a
straight appsink<br>
>> without splitmuxsink.<br>
>><br>
>> In case you were wondering I set the appsink's sync
property to FALSE.<br>
>> Indeed, with all settings in the pipeline identical,
except for the<br>
>> existence of splitmuxsink, I see that with
splitmuxsink buffers arrive at<br>
>> the final sink in bursts, whereas they arrive
regularly otherwise.<br>
>><br>
>> Any ideas what causes this and if there is a setting
that can fix it?<br>
>> Getting the buffers in a timely manner is important
in my case...<br>
>><br>
>> Thank you!<br>
>><br>
>><br>
>><br>
>> --<br>
>> Sent from:<br>
>> <a href="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" rel="noreferrer" target="_blank">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</a><br>
>> _______________________________________________<br>
>> gstreamer-devel mailing list<br>
>> <a href="mailto:gstreamer-devel@.freedesktop" target="_blank">gstreamer-devel@.freedesktop</a><br>
>> <a href="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" rel="noreferrer" target="_blank">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</a><br>
>> _______________________________________________<br>
>> gstreamer-devel mailing list<br>
>> <a href="mailto:gstreamer-devel@.freedesktop" target="_blank">gstreamer-devel@.freedesktop</a><br>
>> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Sent from: <a href="http://gstreamer-devel.966125.n4.nabble.com/" rel="noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/</a><br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div></div>