Skip to content
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

Hardware decoding failure on M1 Macbook Pro #39511

Open
3 of 6 tasks
myndzi opened this issue Jul 1, 2024 · 1 comment
Open
3 of 6 tasks

Hardware decoding failure on M1 Macbook Pro #39511

myndzi opened this issue Jul 1, 2024 · 1 comment
Labels
needs-investigation A bug not 100% confirmed/fixed OS/Desktop OS/macOS

Comments

@myndzi
Copy link

myndzi commented Jul 1, 2024

Description

Edit: GDQ responded to me, and mentioned that they are having this sort of issue when "falling back to [their] backup encoder". I'm asking for clarification, but it seems like perhaps they're switching the source of their stream video live between two encoders; this could explain the problem if it is indeed an unexpected sequence of frame data like in one of the issues I read. They say that also they get an increased occurrence of playback errors while on the backup encoder though, so possibly it's also something about the video produced by that encoder.

Something about the encoded data stream of GDQ is creating a condition where video decoding fails. In the console, this error shows up: PIPELINE_ERROR_DECODE: Error Domain=NSOSStatusErrorDomain Code=-12909

As best I can tell, it's possible that the video encoder is creating an unusual or possibly invalid circumstance. This is backed up by noting that when watching the VOD on a quality lower than "source", there is no crash (presumably due to re-encoding). Similarly, playing back the clip (remuxed? it still has a "source" quality option but does not crash) does not crash - so possibly the error is in the framing/muxing and not the video stream itself. Disabling hardware encoding also avoids the problem.

May be related, but less specific and closed without resolution: #3050
This issue from hls.js seems possibly relevant: video-dev/hls.js#3834

Google Chrome does not break in the same way; I attempted to download a build of Chromium but it wouldn't run.

I'm not sure if the error applies on e.g. an M2.

I'm up-to-date on MacOS Sonoma 14.5 and Brave Version 1.67.123 Chromium: 126.0.6478.126 (Official Build) (arm64)

I'm hoping that the fix is just to bring in some patch or change from upstream, but who knows :\

Steps to reproduce

  1. Open https://clips.twitch.tv/AmazonianNurturingPartridgeYouWHY-sGjid8UJGYfMYESx
  2. Listen for "So you can... do a little grab there and she... [here]"
  3. The video glitches out but continues playing
  4. Click "Watch full video" and it will play the same segment, but crash instead of glitch out
    a. Be sure (settings cog, hover over the video) you are playing on "Source" quality

Actual result

Video playback reports an error (which, in this case, causes it to give up and require a refresh)

Expected result

Video playback continues uninterrupted

Reproduces how often

Easily reproduced

Brave version (brave://version info)

1.67.123 Chromium: 126.0.6478.126 (Official Build) (arm64)
Revision | fc7619ef621fe4e6a0fa8b16c718f78ffc97a861
OS | macOS Version 14.5 (Build 23F79)

Channel information

  • release (stable)
  • beta
  • nightly

Reproducibility

  • with Brave Shields disabled
  • with Brave Rewards disabled
  • in the latest version of Chrome

Miscellaneous information

No response

@rebron rebron added needs-investigation A bug not 100% confirmed/fixed OS/macOS labels Jul 1, 2024
@rebron
Copy link
Collaborator

rebron commented Jul 1, 2024

cc: @ryanbr

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-investigation A bug not 100% confirmed/fixed OS/Desktop OS/macOS
Projects
None yet
Development

No branches or pull requests

2 participants