[Libav-user] Convert a dvr security camera rtsp stream for using with video html5 tag

[Guillaume]

Thanks for the help and you're right about the 2 seconds.

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.

Guillaume

Le 28/03/2017 à 17:20, Josh Gustafson a écrit :
> On Tue, Mar 28, 2017 at 2:29 AM, Guillaume <libav at shadowprojects.org 
> <mailto:libav at shadowprojects.org>> wrote:
>
>     Hello,
>
>     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.
>     Problem is, firefox 52 disabled npapi plugins (flash player
>     excepted) so it doesn't work anymore.
>
>     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.
>     But i don't see any bottleneck on the rspi, cpu, ram and io seems
>     fine.
>
>     Here's the rtsp stream informations  : Video: h264 (High),
>     yuv420p, 352x288, 1k tbr, 90k tbn
>
>     I am running this command : avconv -v info -i
>     "rtsp://login@192.168.3.90:554/user=login&password=password&channel=1&stream=1.sdp
>     <http://login@192.168.3.90:554/user=login&password=password&channel=1&stream=1.sdp>"
>     -c:v copy -bufsize 10240k -pix_fmt yuv420p /var/www/portier.m3u8
>
>     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).
>
>     Is there a way to do a better job and tell avconv to remove its
>     old files ?
>
>
> 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: 
> https://www.ffmpeg.org/ffmpeg-formats.html#hls-1
>
> 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.
>
> 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. :-/
>
> Josh
>
>
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ffmpeg.org/pipermail/libav-user/attachments/20170328/b52779d3/attachment.html>