You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi.
Don't know if bug or just my misunderstanding, so posting here anyway :)
I've noticed that hls_fragment and hls_playlist_length do not have any effect, no matter what I set I have this in .m3u8 files:
#EXT-X-TARGETDURATION:48
#EXTINF:47.747,
As far as I understand, it means that rtmp module is using fragment length of 48s, which is strange.
Moreover, I noticed, that rtmp module cleans out fragments while they are still in the playlist. As a result, Chrome on Android, for example, tries to download first fragment in playlist, gets 404 and refuses to continue.
And one more issue: it seems that rtmp module creates .m3u8 file for stream only after writing first fragment for it (after stream is started), thus leading to a 48 second delay. Can this be worked around?
I'm using nginx-1.9.4 with nginx-rtmp-module-1.1.7.
The text was updated successfully, but these errors were encountered:
Hi.
Don't know if bug or just my misunderstanding, so posting here anyway :)
I've noticed that
hls_fragment
andhls_playlist_length
do not have any effect, no matter what I set I have this in.m3u8
files:As far as I understand, it means that rtmp module is using fragment length of 48s, which is strange.
Moreover, I noticed, that rtmp module cleans out fragments while they are still in the playlist. As a result, Chrome on Android, for example, tries to download first fragment in playlist, gets 404 and refuses to continue.
And one more issue: it seems that rtmp module creates
.m3u8
file for stream only after writing first fragment for it (after stream is started), thus leading to a 48 second delay. Can this be worked around?I'm using nginx-1.9.4 with nginx-rtmp-module-1.1.7.
The text was updated successfully, but these errors were encountered: