Open mhzbg opened 11 years ago
Please add -sc_threshold 0
to ffmpeg call. That will synchronize all your streams.
Thanks ! So far it works with minor glitches, but much better than what it used to be ! It did worsen the compression a little bit thought, but this is expected given the nature of this parameter. I hat to revert to master, I guess native-hls is still work in progress. Thanks again
so did you have any problem with native-hls?
the only issue with native-hls is it did not clear the playlist, it continued from the sequence it was reached before, so those 2 playlists were offset by 2 segments and this was an issue. I ran it with the exact same settings I run master. In master the playlists gets cleared from 0 on encoder restart but in hls-native it continues from there it had reached. This is the only issue I can tell so far.
It's not a bug but a feature :)
It can be disabled with hls_continuous off
ok, so the logic changed. By default its off in master, as you can see in my config its commented out. In same config behavior is I have to explicitly state it off so it actually is on by default in native-hls. Thanks
I have been testing both master and native-hls branches. have the following rtmp-module options (relevant snipppet from config) server: server { listen 1935; ping 20s; max_streams 512; max_message 1M; wait_key on; interleave on; chunk_size 8192;
application hls { live on; hls on; hls_path /tmp/hls; hls_fragment 10s; hls_playlist_length 1m; hls_sync 300ms;
hls_continuous on;
I encode the source which is a live source with the following ffmpeg command on a dedicated box
ffmpeg -i http://live-input-progressive:port -vf yadif=0 -c:v libx264 -preset veryfast -profile:v main -g 25 -vb 768k -threads 2 -c:a libfaac -ab 96k -ac 2 -f flv rtmp://192.168.72.200:1935/hls/1_medium -c:v libx264 -preset veryfast -profile:v baseline -g 25 -vb 224k -s 320:240 -threads 2 -c:a libfaac -ab 64k -ac 2 -f flv rtmp://192.168.72.200:1935/hls/1_low
and have created a variance playlist in static html which looks like
EXTM3U
EXT-X-TARGETDURATION:10
EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=256000
http://192.168.72.200:8080/hls/1_low.m3u8
EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=768000
http://192.168.72.200:8080/hls/1_medium.m3u8
This all works fine, except that the low bitrate m3u8 and the medium differ in several segment sequences. This makes jwplayer play and halt on first segment and ios devices also get confused. They skip a segment or 2 or pause possibly because of confusion. The low and medium m3u8s are at a different point and the sequence numbers also differ between 1-2-3 and more.
In theory I have hard set the keyframe to 25 instead of the default 250 in ffmpeg but it has the same behavior. It works well with one bitrate, but with 2 variance playlist they are always a bit out of sync, specially when they run for longer time.
RTMP on each quality works well. Its only mixing them in HLS that causes this behavior.
I have tried playing with the above configs, remove them, tweaked them, its all the same.
Any ideas ?
Thanks.
P.S Here are both plalists loaded at the same time
EXTM3U
702 863582700
EXT-X-TARGETDURATION:10
EXT-X-ALLOW-CACHE:NO
EXT-X-MEDIA-SEQUENCE:696
EXTINF:10,
1_medium-696.ts
EXTINF:10,
1_medium-697.ts
EXTINF:10,
1_medium-698.ts
EXTINF:10,
1_medium-699.ts
EXTINF:10,
1_medium-700.ts
EXTINF:10,
1_medium-701.ts
EXTM3U
700 847639950
EXT-X-TARGETDURATION:10
EXT-X-ALLOW-CACHE:NO
EXT-X-MEDIA-SEQUENCE:694
EXTINF:10,
1_low-694.ts
EXTINF:10,
1_low-695.ts
EXTINF:10,
1_low-696.ts
EXTINF:10,
1_low-697.ts
EXTINF:10,
1_low-698.ts
EXTINF:10,
1_low-699.ts
Notice the time stamp (I think this is what it is on the native-hls built under EXTM3U) and also the EXT-X-MEDIA-SEQUENCE differ between the 2. Players go crazy as the poll both playlists. Also I think because for life HLS they play playlist -2 or -3 segments, the segment names differ, one is there, the other not yet, which is the real trouble.