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 _______________________________________________ ffmpeg-user mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
