<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>Thanks for the help and you're right about the 2 seconds.</p>
    <p>I switched to Kurento media server (RTSP to WebRTC server) and i
      can't get any closer than a 2s latency, but it's a lot better than
      the 8s i had previously.<br>
    </p>
    <pre class="moz-signature" cols="72">Guillaume</pre>
    <div class="moz-cite-prefix">Le 28/03/2017 à 17:20, Josh Gustafson a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CAOVFAB0mNoVkVMzOcP8PCVihuhLLhQX4mLXawiKW6RcGKZrKsw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Tue, Mar 28, 2017 at 2:29 AM,
            Guillaume <span dir="ltr"><<a moz-do-not-send="true"
                href="mailto:libav@shadowprojects.org" target="_blank">libav@shadowprojects.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">Hello,<br>
              <br>
              I have a dvr with security camera and one of them is
              displayed (through a rspi 2) on a web page (rtsp stream)
              with vlc plugin to show who is at the door and open it
              remotely.<br>
              Problem is, firefox 52 disabled npapi plugins (flash
              player excepted) so it doesn't work anymore.<br>
              <br>
              I am trying to convert the stream in real time to one
              compatible with html5 video tag, but at best, i have a 8
              seconds delays. And it keeps filling the drive with
              streaming files.<br>
              But i don't see any bottleneck on the rspi, cpu, ram and
              io seems fine.<br>
              <br>
              Here's the rtsp stream informations  : Video: h264 (High),
              yuv420p, 352x288, 1k tbr, 90k tbn<br>
              <br>
              I am running this command : avconv -v info -i "rtsp://<a
                moz-do-not-send="true"
href="http://login@192.168.3.90:554/user=login&password=password&channel=1&stream=1.sdp"
                rel="noreferrer" target="_blank">login@192.168.3.90:554<wbr>/user=login&password=password&<wbr>channel=1&stream=1.sdp</a>"
              -c:v copy -bufsize 10240k -pix_fmt yuv420p
              /var/www/portier.m3u8<br>
              <br>
              I can ran the conversion on a lxc container (with Ubuntu
              16.04) which is more powerfull than a rspi 2, but even
              there, i have a 4s delay (and still a growing number of
              temporary files which fill the drive).<br>
              <br>
              Is there a way to do a better job and tell avconv to
              remove its old files ?<br>
            </blockquote>
            <div><br>
            </div>
            <div>I've been working on something similar (though using
              the APIs rather than the CLI.) There's a few things you
              may find helpful in the options supported by the HLS
              muxer: <a moz-do-not-send="true"
                href="https://www.ffmpeg.org/ffmpeg-formats.html#hls-1">https://www.ffmpeg.org/ffmpeg-formats.html#hls-1</a></div>
            <div><br>
            </div>
            <div>Under `hls_flags`, there's `delete_segments`, which
              will cause the mux to automatically delete segments which
              have "fallen off" the end of the playlist. So that part's
              easy.</div>
            <div><br>
            </div>
            <div>Latency is harder (or has been harder in my
              experience.) One source of latency is the time it takes to
              gather all the stream info from the source prior to the
              start of muxing; I've found that with h264 from rtsp
              cameras, this simply takes time and I haven't found a way
              around it. A second source of latency is the HLS segment
              size - HLS won't publish a segment until it's complete,
              which means a latency at least as great as the (longest)
              segment duration, which defaults to 2 seconds. You can try
              adjusting that with `hls_time` and `hls_init_time`, but
              when you're remuxing, the minimum segment duration is in
              practice bound by the interval between keyframes, and with
              the h264 streams I've seen from security cameras, that's
              going to be around 2 seconds anyway. :-/</div>
            <div><br>
            </div>
            <div>Josh</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Libav-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libav-user@ffmpeg.org">Libav-user@ffmpeg.org</a>
<a class="moz-txt-link-freetext" href="http://ffmpeg.org/mailman/listinfo/libav-user">http://ffmpeg.org/mailman/listinfo/libav-user</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>