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

Video Track EXCEEDS_CAPABILITIES on media3 v1.2.0 but not in exoplayer v2.17.0 #966

Closed
kvillnv opened this issue Jan 13, 2024 · 7 comments
Closed

Comments

@kvillnv
Copy link

kvillnv commented Jan 13, 2024

Using the same device and same streams I have noticed a performance limitation in media3 v1.2.0 in comparison to exoplayer v2.17.0 and below.
It seems media3 is more strict. In the MappingTrackSelector logs, more tracks are marked supported=NO_EXCEEDS_CAPABILITIES
This results in lower resolution playback on media3.
Media3 is using all the same parameters I was using with exoplayer, migration was pretty straightforward following the guide with exoplayer 2.19.1.

Device: Samsung Galaxy Tab A7 (SM-T500) API 31. It is a middle performance device, which is a great benchmark for testing before going to production.
H.264 codec: OMX.qcom.video.decoder.avc.secure
H.265 codec: OMX.qcom.video.decoder.hevc.secure

Media: Any H.264 and H.265 Widevine protected DASH streams with multiple video tracks.
H.264 playlists contains 3 video tracks: 640x380, 960x540 and 1280x720
H.265 contains: 640x480,128x720 and 1920x1080
Those streams have been playing for years fine with exoplayer 2.17 and below.

With exoplayer 2.17.0 and below the A7 was able to play:

  • H.264 up to 1280x720 (max)
  • H.265 up to 1280x720 (max - 1)

With media3 1.2.0 the A7 can only play:

  • H.264 up to 960x540 (max - 1)
  • H.265 up to 640x360 (max - 2)

I was about to create a new app release and fortunately I noticed the quality issue last minute.
If it happens on the Tab A7 it will probably happen on more devices.
Note: My Pixel 7 pro is not affected, but I don't expect all the users to have high performance devices, I really want mid-performance devices to stay compatible.
It looks like programmed obsolescence.


What I noticed:
In the logs below accelerated=YES does not appear on media3 and appears in exoplayer.
I am not using a custom MediaCodecSelector in this app. I would expect exoplayer to select the correct one. And even if I start exploring this solution I cannot be sure to select correct codec on all devices.
I have experience with MediaCodecSelector on another app with a custom STB.

QUESTION:
Can you explain what changed in media3?
Is there a new setting I should enable somewhere?
Any other information that could help?


Here are the MappingTrackSelector logs. They show less track compatible with media3, and accelerated=YES is missing

H.264 - Same device, same DASH

  • exoplayer v2.17.0
Group:4, adaptive_supported=YES [
[X] Track:0, id=video=990000, mimeType=video/avc, bitrate=990000, codecs=avc1.64001E, drm=[widevine,cenc], res=640x360, fps=29.97003, roleFlags=[main], supported=YES, accelerated=YES
[X] Track:1, id=video=2670000, mimeType=video/avc, bitrate=2670000, codecs=avc1.64001F, drm=[widevine,cenc], res=960x540, fps=29.97003, roleFlags=[main], supported=YES, accelerated=YES
[X] Track:2, id=video=5340000, mimeType=video/avc, bitrate=5340000, codecs=avc1.640020, drm=[widevine,cenc], res=1280x720, fps=59.94006, roleFlags=[main], supported=YES, accelerated=YES
  • media3 v1.2.0
group [
[X] Track:0, id=video=990000, mimeType=video/avc, bitrate=990000, codecs=avc1.64001E, drm=[widevine,cenc], res=640x360, fps=29.97003, roleFlags=[main], supported=YES
[X] Track:1, id=video=2670000, mimeType=video/avc, bitrate=2670000, codecs=avc1.64001F, drm=[widevine,cenc], res=960x540, fps=29.97003, roleFlags=[main], supported=YES
[ ] Track:2, id=video=5340000, mimeType=video/avc, bitrate=5340000, codecs=avc1.640020, drm=[widevine,cenc], res=1280x720, fps=59.94006, roleFlags=[main], supported=NO_EXCEEDS_CAPABILITIES ]

H.265 - Same device, same DASH

  • exoplayer v2.17.0
Group:unset:0, adaptive_supported=YES [
[X] Track:0, id=1, mimeType=video/hevc, bitrate=937880, codecs=hev1.1.6.L90.B0, drm=[widevine,cenc], res=640x360, fps=60.0, supported=YES, accelerated=YES
[X] Track:1, id=2, mimeType=video/hevc, bitrate=2601137, codecs=hev1.1.6.L120.B0, drm=[widevine,cenc], res=1280x720, fps=60.0, supported=YES, accelerated=YES
[ ] Track:2, id=3, mimeType=video/hevc, bitrate=5172872, codecs=hev1.1.6.L123.B0, drm=[widevine,cenc], res=1920x1080, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES, accelerated=YES

-media3 v1.2.0

group [
[X] Track:0, id=1, mimeType=video/hevc, bitrate=937880, codecs=hev1.1.6.L90.B0, drm=[widevine,cenc], res=640x360, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES
[ ] Track:1, id=2, mimeType=video/hevc, bitrate=2601137, codecs=hev1.1.6.L120.B0, drm=[widevine,cenc], res=1280x720, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES
[ ] Track:2, id=3, mimeType=video/hevc, bitrate=5172872, codecs=hev1.1.6.L123.B0, drm=[widevine,cenc], res=1920x1080, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES ]

Audio tracks are not shown here for compactness. They all work.

@kvillnv
Copy link
Author

kvillnv commented Jan 18, 2024

There is an improvement with 1.2.1 ! I can now play all the H.264 resolutions.
But H.265 did not improve.

I tested 1.1.1 , 1.1.0, 1.0.2, 1.0.1 and 1.0.0: all have the same bug as 1.2.0

Here are the logs for v1.2.1
Remarks: still no accelerated=YES and the H.265 track that can play is marked NO_EXCEEDS_CAPABILITIES.

H.264 - media3 1v.2.1

[X] Track:0, id=video=990000, mimeType=video/avc, container=video/mp4, bitrate=990000, codecs=avc1.64001E, drm=[widevine,cenc], res=640x360, fps=29.97003, roleFlags=[main], supported=YES
[X] Track:1, id=video=2670000, mimeType=video/avc, container=video/mp4, bitrate=2670000, codecs=avc1.64001F, drm=[widevine,cenc], res=960x540, fps=29.97003, roleFlags=[main], supported=YES
[X] Track:2, id=video=5340000, mimeType=video/avc, container=video/mp4, bitrate=5340000, codecs=avc1.640020, drm=[widevine,cenc], res=1280x720, fps=59.94006, roleFlags=[main], supported=YES

H.265 - media3 v1.2.1 - No improvement from v1.2.0

[X] Track:0, id=1, mimeType=video/hevc, container=video/mp4, bitrate=937880, codecs=hev1.1.6.L90.B0, drm=[widevine,cenc], res=640x360, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES
[ ] Track:1, id=2, mimeType=video/hevc, container=video/mp4, bitrate=2601137, codecs=hev1.1.6.L120.B0, drm=[widevine,cenc], res=1280x720, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES
[ ] Track:2, id=3, mimeType=video/hevc, container=video/mp4, bitrate=5172872, codecs=hev1.1.6.L123.B0, drm=[widevine,cenc], res=1920x1080, fps=60.0, supported=NO_EXCEEDS_CAPABILITIES

(See my previous message showing logs for exoplayer v2.17.0 playingTrack:1 in H.265)

@kvillnv
Copy link
Author

kvillnv commented Feb 1, 2024

Is this regression going to be fixed or is there a specific reason the player became more strict?

@microkatz
Copy link
Contributor

Hi @kvillnv,

Thank you for reporting your issue.

The issue is that the device is not accurately reporting its support capabilities according to the PerformancePoint API.

We are currently working on a workaround to fix the regressed behavior and will update this bug when the fix is in.

Thank you so much for your patience.

@kvillnv
Copy link
Author

kvillnv commented Feb 17, 2024

All right, thank you @microkatz.

copybara-service bot pushed a commit that referenced this issue Feb 23, 2024
Some devices supporting Performance Points for decoder coverage are missing coverage over the CDD requirements for H264. For these cases ExoPlayer should fall back to legacy resolution and frame rate support checks. If there is a stream evaluated as a PerformancePointCoverageResult of COVERAGE_RESULT_NO, then ExoPlayer checks for coverage of the 720p H264 CDD requirement.

Issue: google/ExoPlayer#10898

Issue: #693

Issue: #966
PiperOrigin-RevId: 609740128
copybara-service bot pushed a commit to google/ExoPlayer that referenced this issue Feb 23, 2024
Some devices supporting Performance Points for decoder coverage are missing coverage over the CDD requirements for H264. For these cases ExoPlayer should fall back to legacy resolution and frame rate support checks. If there is a stream evaluated as a PerformancePointCoverageResult of COVERAGE_RESULT_NO, then ExoPlayer checks for coverage of the 720p H264 CDD requirement.

Issue: #10898

Issue: androidx/media#693

Issue: androidx/media#966
PiperOrigin-RevId: 609740128
@microkatz
Copy link
Contributor

@kvillnv

A commit, 23a301f, fixing the issue for your H.265 scenario was pushed into the androidx/media main branch. Hopefully that fixes your issue!

@kvillnv
Copy link
Author

kvillnv commented Mar 9, 2024

@microkatz thanks. I'll test soon.

@microkatz
Copy link
Contributor

@kvillnv

I will close this issue thread as a result. Please re-open or create a new issue if you are still having problems. Thank you!

SheenaChhabra pushed a commit that referenced this issue Apr 8, 2024
Some devices supporting Performance Points for decoder coverage are missing coverage over the CDD requirements for H264. For these cases ExoPlayer should fall back to legacy resolution and frame rate support checks. If there is a stream evaluated as a PerformancePointCoverageResult of COVERAGE_RESULT_NO, then ExoPlayer checks for coverage of the 720p H264 CDD requirement.

Issue: google/ExoPlayer#10898

Issue: #693

Issue: #966
PiperOrigin-RevId: 609740128
(cherry picked from commit 23a301f)
l1068 pushed a commit to l1068org/media that referenced this issue Apr 15, 2024
Some devices supporting Performance Points for decoder coverage are missing coverage over the CDD requirements for H264. For these cases ExoPlayer should fall back to legacy resolution and frame rate support checks. If there is a stream evaluated as a PerformancePointCoverageResult of COVERAGE_RESULT_NO, then ExoPlayer checks for coverage of the 720p H264 CDD requirement.

Issue: google/ExoPlayer#10898

Issue: androidx#693

Issue: androidx#966
PiperOrigin-RevId: 609740128
(cherry picked from commit 23a301f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants