Repository navigation
[bug][reproductible in sample app] VP8/VP9 codecs do not work on intel-mac safari #1975
Description
Activity
thanks for the report.
Can you please share the Safari version that you're using? It might be related to that.
If possible, try to update Safari to the latest available version for your OS and see if that helpsthanks for the report.
Can you please share the Safari version that you're using? It might be related to that. If possible, try to update Safari to the latest available version for your OS and see if that helps
Its the lastest version. we tired multiple versions. Does not matter OS or safari version -- what matters is being or not in a mac with an intel chipset.
we've tried to reproduce this on an intel chip mac book with Safari and it didn't reproduce.
Could you please double check:
- does this also happen with vp8 or exclusively with vp9
- which exact Safari version are you using
we've tried to reproduce this on an intel chip mac book with Safari and it didn't reproduce.
Could you please double check:
- does this also happen with vp8 or exclusively with vp9
- which exact Safari version are you using
Im gonna make a video for you.
Meanwhile can you post the specs of the mac you are using so I know its a pre 2018 mac?more details:
- We are using VP9 with simulcast: true
we've tried to reproduce this on an intel chip mac book with Safari and it didn't reproduce.
Could you please double check:
- does this also happen with vp8 or exclusively with vp9
- which exact Safari version are you using
Happens with VP8 As well as VP9
Version: 26.5.2 (20624.2.5.18.7)This has been an issue on Intel Macs with Safari, since I can remember. It has a problem decoding VP8 so anything that falls back to encoding with VP8 will be an issue. VP9 remote clients are fine in my experience, so long as they don't fall back on the encode. I have a Chromebook that does and it seems that ANY device running Safari on a codec other than VP8.
Something to note that I tested out a fair while back is that we had a prototype version of our software that used PlayCanvas with MediaSoup (now use Unity WebGL with LiveKit). I decided to go back and reproduce on that, which it did. So I suspect it is a deeper WebRTC issue.
@lukasIO the reproduction is:
- Set up a client that encodes with VP8 on any platform
- Connect to that client with an Intel Mac running Safari
- On the Intel Mac, you should see that the other client camera doesn't render properly
- Other devices will render a VP8 encode from an Intel Mac Safari, so long as they themselves are not using one
Feel free to correct if I'm wrong. The fix I suspect, wait for Apple to dump support for Intel devices
Reacted by debugChicken@lukasIO and I have been working on this one in the background over the past few months. We've still been unable to reproduce it at all after extensive testing, and are fairly strongly of the impression (as @chuckills suggested) that this is a low level webrtc / hardware issue. Maybe it could be a hardware acceleration problem that only manifests on some specific device models, and not outright on all intel macbooks?
One option we have discussed internally - if we can figure out how to reproduce this and come up with a means of determining reliably whether a given client will go into this failure state or not, we could signal this flag to the SFU and use it to avoid offering VP8/VP9 for these clients.
@dganzella I think figuring this "indicator" out and writing a function which can be called and determine this at connection time is probably the next step that needs to be done to move this issue forward. If you're able to reproduce this reliably, maybe you have some clues as to what that function could be checking for?
Reacted by debugChicken@lukasIO and I have been working on this one in the background over the past few months. We've still been unable to reproduce it at all after extensive testing, and are fairly strongly of the impression (as @chuckills suggested) that this is a low level webrtc / hardware issue. Maybe it could be a hardware acceleration problem that only manifests on some specific device models, and not outright on all intel macbooks?
One option we have discussed internally - if we can figure out how to reproduce this and come up with a means of determining reliably whether a given client will go into this failure state or not, we could signal this flag to the SFU and use it to avoid offering VP8/VP9 for these clients.
@dganzella I think figuring this "indicator" out and writing a function which can be called and determine this at connection time is probably the next step that needs to be done to move this issue forward. If you're able to reproduce this reliably, maybe you have some clues as to what that function could be checking for?
Well the issues we found were in devices distributed here in Brazil and also in India. I wonder if that maybe has something to do with it?
I sent the print screen of the 2018 mac mini model, does yours differs in an any capacity (at least CPU/GPU wise?)
But I also have been looking into every information I can find available in the browser agent and other global information variables, and I was not able to find one piece of information to single out these machines. It would probably be doable with a native macOS application / electron application, though, but that would not solve our case.
anyway, @1egoman thanks for the reply.
Ps. the exact model with issues is Macmini8,1 ;
https://support.apple.com/111912
@1egoman can you send me the exact model of the devices you are using to test and cannot reproduce?
My devices are in Australia. Specifically a MacBook Pro 2020, i5 CPU with Iris Plus 645 GPU and an old 2014 Mac Mini. We have a couple of other devices in the organisation too. They're also in Australia but I'm not sure of their models.
Reacted by Ryan Gaus and debugChickencan you send me the exact model of the devices you are using to test and cannot reproduce
We don't have many intel macs left for testing at livekit, so I've been attempting to reproduce on a personal 2019 16" macbook pro:
But I also have been looking into every information I can find available in the browser agent and other global information variables, and I was not able to find one piece of information to single out these machines. It would probably be doable with a native macOS application / electron application, though, but that would not solve our case
Yeah, this is the main problem this boils down to and why we haven't issued a targeted fix here so far.
Sorry that this is still an open problem for you, but at its current state (no reproduction on our side + no idea what to use as a signal for this) we are out of ideas how to address it.While I realise this might not be ideal for a bunch of reasons, the most practical solution on your side might be to use h264 for now.
We're happy to pick up the work on this and work on a fix if you find a way to single out the affected machines from within the browser context.The issues we faced is that several Android devices we have would refuse to encode in h264 so other users would just get a white square, and still Safari (and perhaps Firefox) -> Intel Safari would still suffer because of fallback to vp8. Our strategy was to use vp9 for the greatest coverage and advise our Intel Mac users to use Chrome.
And like I said earlier, wait for Apple to drop support for Intel. Which won't be long
Reacted by debugChickenExacly, h264 has many, many more issues. Video issues, screen share issues (white screen), freezing, and its random and in many different devices. h264 is not a solution whatsoever, we tested that already. Besides its also proprietary which we want to avoid if at all possible.
Our stategy is also to use vp9 and advise our intel mac users to use chrome for now.
Mankind ill needs a saviour such as h264
can you send me the exact model of the devices you are using to test and cannot reproduce
We don't have many intel macs left for testing at livekit, so I've been attempting to reproduce on a personal 2019 16" macbook pro:
huh, ours is 2018. I wonder if they need to be 2018 or lower.
But I also have been looking into every information I can find available in the browser agent and other global information variables, and I was not able to find one piece of information to single out these machines. It would probably be doable with a native macOS application / electron application, though, but that would not solve our case
Yeah, this is the main problem this boils down to and why we haven't issued a targeted fix here so far. Sorry that this is still an open problem for you, but at its current state (no reproduction on our side + no idea what to use as a signal for this) we are out of ideas how to address it.
While I realise this might not be ideal for a bunch of reasons, the most practical solution on your side might be to use h264 for now. We're happy to pick up the work on this and work on a fix if you find a way to single out the affected machines from within the browser context.
... me? 🫠
Woudnt it make more sense for you guys to poke the big guns there to find and buy you a used 2018 8,1 intel mac mini so you guys can properly debug and see if there is an actual workaround? Now that you know that its something that happens for sure and its not an implementation error on our part?
I could ship mine (its not even with me, its with the QAs) from brazil to the US but im fairly sure it would be cheaper and easier for you guys to buy ones yourselves there. But please let me know, I do think we could arrange if its the only option.
Besides, even if I do find this signal myself, you guys would implement it without double checking yourselves? it makes no sense, you guys need to properly test it there. 🫠
Moreover, does the fixing need to be pre-emptive? You guys could also explore the path of noticing that the frames are not being processed and then send a signal to the server to receive in a different format. It would be a good fallback for this issue and maybe future issues, although I understand this code is somewhat risky.
huh, ours is 2018. I wonder if they need to be 2018 or lower.
No, my Macbook Pro is a 2020 model
huh, ours is 2018. I wonder if they need to be 2018 or lower.
No, my Macbook Pro is a 2020 model
I see. so it seems its not all mac intel, just some random assortment of mac intels. sheesh this makes this even harder
Describe the bug
Describe the bug
VP8/VP9 codecs do not work on intel-mac safari - they either show green screens or a still frame of the publisher on all the subscriber videos.
In Livekit Sample app:
Reproduction
To Reproduce
Enter a meeting with a user using an intel-mac, on safari browser. Observe the videos.
Logs
Nothing special appear in the logs.System Info
Severity
blocking all usage of LiveKit
Additional Information
*** IMPORTANT ***
The issue is observable only in macs with intel chipset, when using Safari.