-
Notifications
You must be signed in to change notification settings - Fork 361
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
Black screen on ABR changes #1158
Comments
Since you are able to replicate the problem on your device, do you think you can search for the change that broke this behavior? I think you'd need to depend on ExoPlayer/Media3 locally (see instructions here or here, depending on which namespace you are using) and then you can move the code in a more granular way to find the problematic change. |
Hello, If I compile a version and I revert all lines of this commit, the problem is solve. Would you like me to do some special tests to help your analysis? |
The problem is in NalUnitUtil class, in parseSpsNalUnitPayload function.
the problem no longer appears. |
It's probably not that these lines itself are wrong, it's more likely that this causes some configuration change when selecting or configuring codecs for playback. Could you attach an |
Mail sent with requested informations. |
Thanks. Assuming you still have the local checkout, could you try to comment out all four media/libraries/common/src/main/java/androidx/media3/common/util/MediaFormatUtil.java Line 256 in d13a0f4
|
No, the problem is still present with these commented lines. |
Thanks for the confirmation and sharing the bugreports! I think I see the problem now and will share another fix proposal soon (sorry for constantly asking to test things out, but I don't have a reproduction setup myself). |
Some media can read color info values from the bitstream and may partially set some of the SDR default values in Format.ColorInfo. Setting these default values for SDR can confuse some codecs and may also prevent adaptive ABR switches if not all ColorInfo values are set in exactly the same way. We can avoid any influence of HDR color info handling by disabling setting the color info MediaFormat keys for SDR video and also avoid codec reset at format changes if both formats are SDR with slightly different ColorInfo settings. To identify "SDR" ColorInfo instances, we need to do some fuzzy matching as many of the default values are assumed to match the SDR profile even if not set. Issue: #1158 PiperOrigin-RevId: 617473937
Some media can read color info values from the bitstream and may partially set some of the SDR default values in Format.ColorInfo. Setting these default values for SDR can confuse some codecs and may also prevent adaptive ABR switches if not all ColorInfo values are set in exactly the same way. We can avoid any influence of HDR color info handling by disabling setting the color info MediaFormat keys for SDR video and also avoid codec reset at format changes if both formats are SDR with slightly different ColorInfo settings. To identify "SDR" ColorInfo instances, we need to do some fuzzy matching as many of the default values are assumed to match the SDR profile even if not set. Issue: androidx/media#1158 PiperOrigin-RevId: 617473937
The commit linked above should fix the problem. Could you verify this again with your setup? Thanks! |
Yes, if I compile on the main branch I don't see the problem. Thanks a lot ! |
Some media can read color info values from the bitstream and may partially set some of the SDR default values in Format.ColorInfo. Setting these default values for SDR can confuse some codecs and may also prevent adaptive ABR switches if not all ColorInfo values are set in exactly the same way. We can avoid any influence of HDR color info handling by disabling setting the color info MediaFormat keys for SDR video and also avoid codec reset at format changes if both formats are SDR with slightly different ColorInfo settings. To identify "SDR" ColorInfo instances, we need to do some fuzzy matching as many of the default values are assumed to match the SDR profile even if not set. Issue: #1158 PiperOrigin-RevId: 617473937 (cherry picked from commit 3a7d31a)
Some media can read color info values from the bitstream and may partially set some of the SDR default values in Format.ColorInfo. Setting these default values for SDR can confuse some codecs and may also prevent adaptive ABR switches if not all ColorInfo values are set in exactly the same way. We can avoid any influence of HDR color info handling by disabling setting the color info MediaFormat keys for SDR video and also avoid codec reset at format changes if both formats are SDR with slightly different ColorInfo settings. To identify "SDR" ColorInfo instances, we need to do some fuzzy matching as many of the default values are assumed to match the SDR profile even if not set. Issue: androidx#1158 PiperOrigin-RevId: 617473937 (cherry picked from commit 3a7d31a)
Version
Media3 main branch
More version details
Issue appear with version 1.1.0 (OK with version 1.0.2)
Same on ExoPlayer, present on v2.19.0 and not with v.2.17.0
Devices that reproduce the issue
Problem is on our Box Vantiva/Technicolor (broadcom) but also reproduced on 2 differents Sony TVs.
Devices that do not reproduce the issue
Problem is not reproduced on Google TV, not on Nvidia Shield and not on Android Studio Emulator.
And also not reproduced on Samsung mobiles.
Reproducible in the demo app?
Yes
Reproduction steps
Expected result
The media start with a low profile. After a while it play with the highest profile and the transition should be fluent.
Actual result
The media start with a low profile. After a while it play with the highest profile but during the transition we have a black screen.
Media
I'll send you the media to test.
Bug Report
adb bugreport
to [email protected] after filing this issue.The text was updated successfully, but these errors were encountered: