<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 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 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 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>