<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi,<br>
    </p>
    <div class="moz-cite-prefix">On 3/10/19 1:29 am, Bill Klein wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGSOO2NTUPq-59K1Cnbzo_FN70L2NmTTzUUTV==mqYE2WDk=jA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <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"
cite="mid:CAGSOO2NTUPq-59K1Cnbzo_FN70L2NmTTzUUTV==mqYE2WDk=jA@mail.gmail.com">
      <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"
cite="mid:CAGSOO2NTUPq-59K1Cnbzo_FN70L2NmTTzUUTV==mqYE2WDk=jA@mail.gmail.com">
      <div dir="ltr">
        <div><br clear="all">
          <div>
            <div dir="ltr" class="gmail_signature"
              data-smartmail="gmail_signature">- 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"
            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 &lt;<br>
          >> <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel-bounces@.freedesktop">gstreamer-devel-bounces@.freedesktop</a><br>
          >> &gt; Im Auftrag von logidelic<br>
          >> Gesendet: Dienstag, 1. Oktober 2019 22:28<br>
          >> An: <br>
          >> <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@.freedesktop">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&amp;data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&amp;sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&amp;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&amp;data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350906128&amp;sdata=sFHiIRnyGFAf%2F2cA7f61hhQAgEai4fTIRhWHqM06kEc%3D&amp;reserved=0</a><br>
          >> _______________________________________________<br>
          >> gstreamer-devel mailing list<br>
          >> <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@.freedesktop">gstreamer-devel@.freedesktop</a><br>
          >> <a
href="https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fgstreamer-devel&amp;data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&amp;sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&amp;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&amp;data=02%7C01%7C%7C2f0d7ef9342c4353f7de08d746ddb547%7C28042244bb514cd680347776fa3703e8%7C1%7C0%7C637055790350916131&amp;sdata=2O6SzAzBNFrFBxoXaRlC1R4jkc8clRnqfk%2BLE6L29jk%3D&amp;reserved=0</a><br>
          >> _______________________________________________<br>
          >> gstreamer-devel mailing list<br>
          >> <a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@.freedesktop">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>
  </body>
</html>