<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 4/10/19 4:04 am, Bill Klein wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGSOO2Pf-896WUfmb1=VrfR1HM5vqcf-NGewksaeR1ELD+8fTw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
</blockquote>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:CAGSOO2Pf-896WUfmb1=VrfR1HM5vqcf-NGewksaeR1ELD+8fTw@mail.gmail.com">
<div dir="ltr">
<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>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>- Jan.<br>
</p>
<blockquote type="cite"
cite="mid:CAGSOO2Pf-896WUfmb1=VrfR1HM5vqcf-NGewksaeR1ELD+8fTw@mail.gmail.com">
<div dir="ltr">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">gstreamer-devel@.freedesktop</a><br>
>> <a
href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel"
rel="noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">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" moz-do-not-send="true">gstreamer-devel@lists.freedesktop.org</a><br>
> <a
href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>