[FFmpeg-user] ffmpeg for transcoding/stream into web pag

Moritz Barsnick barsnick at gmx.net
Mon May 13 10:18:22 EEST 2019


On Sun, May 12, 2019 at 23:50:03 -0600, R C wrote:
> ffmpeg -i
> "rtsp://192.168.x.y:554/user=admin_password=XXXXXXXX_channel=1_stream=0.sdp?real_stream"
> -y -c:a aac -b:a 160000 -ac 2 -s 960x540 -c:v libx264 -b:v 800000
> -hls_time 6 -hls_list_size 10 -hls_flags delete_segments -start_number 1
> mystream.m3u8
>
> that doesn't delete the "old files" though

Hmm, works for me.

If you add "-loglevel debug", ffmpeg should say:
> [hls muxer @ 0xb9f7140] deleting old segment mystream1.ts
amongst all the other tons of information.

> > Well this is partly because HLS isn’t really a streaming protocol, I can’t think of any good way to avoid that initial delay. The recommended target duration of each segment is 6 seconds (or adjusted for drop frame) so if you change hls_time from 10 to 6 you could make it shorter but I don’t think that’s usually the “bottleneck,” so to speak. There’s the time needed to connect to the original rtsp source and transcode, for instance.
> >
> > If you keep an instance running constantly, this would be a non-issue though?
>
> true,  but the delay is about 60 seconds or so,  I think that is because
> each segment is about that long?

Possibly, because cutting at keyframes requires actual keyframes to
appear. :) You may need to force the maximum GOP to your segment size,
so that the sizes / durations can actually be achieved.

Note that there's also an option "-hls_init_time", to make the first
segment shorter than the subsequent ones. This was possibly introduced
exactly for reducing start-up delay. Do have a closer look at the docs:
https://ffmpeg.org/ffmpeg-formats.html#hls-2

Cheers,
Moritz


More information about the ffmpeg-user mailing list