Closed mrjamesriley closed 1 year ago
For the above, please note that following:
I can see in the logs mention of audio overlaps. Given that I do not control the original audio file, my desire here is for HLS to 'just work' and play through despite such issues. This Video does play well using the Video.js library (without any stalling), which I hope is a positive sign that any issues with the encoding of the original video doesn't need to be a show-stopper.
The overlap that results in a video SourceBuffer gap and ultimately the stall is in the main playlist:
base-stream-controller.ts:556 [log] > [stream-controller]: Buffered main sn: 0 of level 4 (frag:[0.000-4.000] > buffer:[0.000-4.000])
base-stream-controller.ts:556 [log] > [stream-controller]: Buffered main sn: 1 of level 4 (frag:[3.933-7.933] > buffer:[0.000-3.833][3.933-7.933])
Thank you for the response @robwalch
Given that the source of these videos is the Instagram API (and thus we do not control the encoding here), is there a way to configure HLS.js to 'ignore' such issues and just play through?
HLS.js version 1.2.4
and prior manage to play this stream without trouble - is it possible to achieve the same behaviour on the latest version of HLS.js? I'm hoping to be able to avoid the video pausing/stalling and have the library 'do its best' with what it has available - even if it means audio loss of video frames lost etc.
I got this problem too, the video is hosted on Cloudflare, everything works fine when I downgrade to 1.2.4 too
HLS.js version 1.2.4 and prior manage to play this stream without trouble
Probably a result of this change:
@mrjamesriley or @suppayami, can either of you confirm?
The change above is not one we want to remove. There may some reasoning where making adjustments is OK in this case, but we need to confirm why this overlap is detected:
Is it a problem in the media resulting from bad track alignment (shifting negative timestamps to 0 on first segment)? Or, is HLS.js doing the shifting in this case (didn't look like it, but a closer look is in order)?
transmuxer-interface.ts:379 [warn] > AVC: 67 ms (-6000dts) overlapping between fragments detected
onWorkerMessage @ transmuxer-interface.ts:379
TransmuxerInterface.onwmsg @ transmuxer-interface.ts:88
The issue is primarily that the media timestamps of the last and first samples in the first two TS segments literally overlap:
Last video sample of msn 0: pts: 363000, dts: 357000 First video sample of msn 1: pts: 360000, dts: 354000
Regardless of whether Hls.js aligns on PTS or DTS, the last frame at the end of the first segment is overlapped by the first of the second, resulting in the former being ejected by MSE on append.
Hi @mrjamesriley and @suppayami,
Do the changes in #5500 resolve the playback issues for you (buffer gap resulting in stall at the end of the first segment)?
@robwalch sorry for late reply, I just tried with latest canary and it seems to work fine. Thank you so much 🚀
@robwalch I've been seeing this issue for a while now and came across this thread - it appears to have been resolved for others but for my usecase, it still appears to be broken with various versions of this library including the latest release. These videos are through Cloudflare Streams and I have no control over the encoding.
Example video:
With v1.4.2 Demo:
Looking at the demo I can see an overlap between segments here, which may be of note:
The order in which requests are made is quite a bit different between Firefox and Chrome, which may hint at why things are working in Firefox, though the order of these could well be dependent on my individual network speed.
Chrome:
In Firefox, segmented audio and video are grouped together and things work as expected.
Here are the console logs I see from the demo:
I spotted this issue which also seems related; You requested a new issue card be made for that one, but the problem I'm having seems as if it's the same as the one mentioned in this card. If you would like me to split this into its own issue please let me know. Any ideas?
Hi @bhayward93,
Please file a new issue.
Check against dev (https://hlsjs-dev.video-dev.org/demo/) and include a sample HLS asset reproducing the issue with complete console log text.
Hi @bhayward93,
Please file a new issue.
Check against dev (https://hlsjs-dev.video-dev.org/demo/) and include a sample HLS asset reproducing the issue with complete console log text.
Thank you for the quick response @robwalch. I've made a new issue card here https://github.com/video-dev/hls.js/issues/5797
What version of Hls.js are you using?
1.4.2
What browser (including version) are you using?
Chrome 113.0.5672.92 (Official Build) (arm64)
What OS (including version) are you using?
Mac OSX Ventura 13.2
Test stream
https://4cda8c72.hls-js-dev.pages.dev/demo/?src=https%3A%2F%2Fcustomer-xd80itw4spq1dhtd.cloudflarestream.com%2F256b50e4b1fe5e1cb1d010a9668bb2ec%2Fmanifest%2Fvideo.m3u8&demoConfig=eyJlbmFibGVTdHJlYW1pbmciOnRydWUsImF1dG9SZWNvdmVyRXJyb3IiOmZhbHNlLCJzdG9wT25TdGFsbCI6dHJ1ZSwiZHVtcGZNUDQiOmZhbHNlLCJsZXZlbENhcHBpbmciOi0xLCJsaW1pdE1ldHJpY3MiOi0xfQ==
Configuration
Additional player setup steps
No response
Checklist
Steps to reproduce
Expected behaviour
The video does not stall and the plays all the way through without stopping.
What actually happened?
After 3 seconds in the video playback stalls. Audio continues to play for a few more seconds, then also stops. A second or two later, the video is able to 'recover' and continues playing.
Console output
Chrome media internals output
No response