-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS decoding error: PIPELINE_ERROR_DECODE: VDA Error 4 #5632
Comments
Here's the transmuxed fMP4 dumped from the player. Attempting to decode that with VideoToolbox-accelerated ffmpeg causes problems.
And then that last part repeats a bunch. Full ffmpeg debug log if that's helpful. Remuxing the source m3u8 doesn't cause any issues at all:
|
Duplicated MOOV and SDTP atoms? What's in that TS? |
@robwalch It's just these three files:
The only unusual thing I can think of there is that there are three tracks — H264, AAC, and Vorbis audio. |
The first and last segment play OK. Early in the playback (and decoding) of the second segment, is when the error occurs. All three have the opus track. This should be ignored completely. There's a DVB stream type of 6 that HLS.js is ignoring. I dumped the fmp4 output for the second segment and was able to play the audio and video files with QuickTime. No errors when run through ffprobe (5.1.1). I can reproduce the pipeline error in Chrome:
|
Here's the AVC mp4 which should be playable from 5-10s (0-5 and 10-15 empty): video-2023-07-12T01_46_32.359Z.mp4Let me know if there's an issue with the muxing of any of the samples or timestamps. I don't see the problem, but happy to work on a fix if someone can identify it in this example. |
Huh... interesting! In that video, I'm noticing that the first second of data claims to contain 59 frames, and that the 60th frame is twice as long in duration as the others. EDIT: And I cross-referenced with the original TS data (to be clear, above is about the video in the message preceding this message) for the same time period, and that data does contain 60 distinct timestamps of equal length in the first GOP. So... yeah, something in the muxer is somehow combining that last frame of the GOP with the first frame of the next and considering it a single frame. Hopefully that's enough to figure out why it's happening? |
I can't image... Using config:
load the sample stream in the description and break/step through hls.js/src/remux/mp4-remuxer.ts Line 413 in 70e2c34
It's counting 299 input samples with 836 NAL units. Sample duration handled here and each sample has a duration of (1440 or 1530 / 90000): hls.js/src/remux/mp4-remuxer.ts Lines 585 to 597 in 70e2c34
I don't see how frames would get combined by the remuxer. Maybe the issue is in tsdemuxer > avc-video-parser when parsing AVC NAL units:
|
Yeah, this is almost certainly indeed a problem with the avc-video-parser... Note that the second GOP's first frame does not start with a AUD NAL unit, while every other frame in the TS data does. It seems the NVENC encoder occasionally neglects to insert an AUD before some keyframes, but otherwise always does it. The logic seems to assume AUDs are either always or never there, and that assumption does not hold for this stream. 🤔 When an AUD is seen, this logic happens before creating the new frame: hls.js/src/demux/video/avc-video-parser.ts Lines 164 to 166 in b84baee
But, when a AUD is missing, instead this logic happens, and the existing frame data is never pushed:
Copying those three lines over to here should resolve the issue, as in the presence of a keyframe you can safely assume any remaining frame data waiting to be pushed belongs to a separate frame. On that note, there's another case that should probably also use this logic, when a type-1 NAL unit is a keyframe, here:
|
Went ahead and made a PR for my suggested solution. 👍 |
Confirmed that @Thulinma's branch fixes the problem for me! Here's a built version of the player that plays back smoothly. EDIT: Published to npm as |
…s them to be merged with their preceding frame
… be merged with their preceding frame (#5660)
Thanks for the bug report and the fix. Changes are available in dev and in v1.4.9: |
What version of Hls.js are you using?
v1.4.7
What browser (including version) are you using?
Latest Brave & Firefox on macOS
What OS (including version) are you using?
macOS Ventura 13.3.1 (a)
Test stream
https://docs-livepeer-live-cors.livepeer.workers.dev/eli/966061CB-D79D-46A6-996C-699D87FD4D2D/hls-playback-problem/problem.m3u8
Configuration
Additional player setup steps
Seems to break in all cases where macOS hardware decoding is involved. Using software decoding in an Ubuntu VM, I get a hiccup in the video but nothing fatal. On Windows using NVDEC I get completely clean playback; this is consistent with the original encoder being NVENC.
Checklist
Steps to reproduce
Just playback the stream at https://docs-livepeer-live-cors.livepeer.workers.dev/eli/966061CB-D79D-46A6-996C-699D87FD4D2D/hls-playback-problem/problem.m3u8
Expected behaviour
Clean playback
What actually happened?
Console output
Chrome media internals output
EDIT: My encoder settings for this stream, just in case that matters. 12 Mbps 4k60 with B-Frames disabled.
EDIT 2: Shaka Player and Bitmovin's HLS Player seem to run into this issue as well. But THEOplayer doesn't! Fascinating.
The text was updated successfully, but these errors were encountered: