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 <[email protected]
<mailto:[email protected]>> 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://[email protected]:554/user=login&password=password&channel=1&stream=1.sdp
<http://[email protected]: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
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
