[Libav-user] Convert a dvr security camera rtsp stream for using with video html5 tag
libav at shadowprojects.org
Tue Mar 28 18:44:12 EEST 2017
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
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:
> 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
> Here's the rtsp stream informations : Video: h264 (High),
> yuv420p, 352x288, 1k tbr, 90k tbn
> I am running this command : avconv -v info -i
> -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:
> 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. :-/
> Libav-user mailing list
> Libav-user at ffmpeg.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libav-user