Reopen: Bug Resurfaces -> Low resolution on HD streams since v2.18.2 #693

[donchummar]

Version

Media3 1.3.1

More version details

I previously reported an issue in Media3 ExoPlayer (issue #693), which was subsequently resolved in commit 4515a0c. The fix was working correctly until version 1.3.1, where it appears the bug has resurfaced. The issue seems to be related to a fix for another bug reported in issue #966, and the problem emerged after the changes made in commit 23a301f.

Devices that reproduce the issue

Galaxy Tab S7 FE

Devices that do not reproduce the issue

.

Reproducible in the demo app?

Not tested

Reproduction steps

Play widewine drm asset with more than 30fps

Expected result

It should select max resolution available

Actual result

Stuck with lowest resolution available

Media

.

Bug Report

• You will email the zip file produced by adb bugreport to [email protected] after filing this issue.

[microkatz]

@donchummar

Thank you for reopening your issue!

Could you provide additional details of the content you were trying to play? Can you provide the encodings, resolutions and framerates that were available. The encoding, resolution and framerate you expected to be playable and the actual resultant selection?

Thanks!

[donchummar]

The content i am playing (H264) having multiple resolution available
480x270 with framerate 50/1
640x360 with framerate 50/1
960x540 with framerate 50/1
1920x1080 with framerate 50/1
1280x720 with framerate 50/1

with latest exo player version (From 1.3.1) on that samsung galaxy s7 fe tab , its selecting 480x270 with framerate 50/1 instead of 1920x1080 with framerate 50/1

It seems like Samsung tab A7 issue fix is conflicting with this

[microkatz]

@donchummar

Apologies but I don't have this particular device. Would you be able to share a bug report taken while reproducing the issue on the demo application? Also if you had access to content of an H264 stream with 1280x720 with framerate 60/1 then that would be helpful to see the logs with that stream as well.

The additions in 1.3.1 are related to the fix that helped you before. However, I am struggling to see how they would regress your scenario(unless your tablet is on SDK >= 35 and Samsung did not fix its reporting issue).

Basically, the original fix said that if you are trying to stream H264 and the Performance Point API says your stream is not covered, check the CDD base requirement for H264. If the device fails the Performance Point check for the base requirement, use the legacy checks.

The new commit, 23a301f, takes that and says if you are trying to stream any encoding, not just H264, that fails the Performance Point check, then run a check for the CDD H264 1280p base requirement. If that fails then use the legacy checks. The difference between 1.2.1 and 1.3.1 is in running the check not just when streaming H264.

The fact that the original solution helped you would lead me to believe that your device does not advertise support for the CDD base requirement for H264(which is 1280p at 60fps). So I'm hoping to see in a trace with that stream a version of the following in the logs.

[X] Track:2, id=video=5340000, mimeType=video/avc, bitrate=5340000, codecs=avc1.640020, drm=[widevine,cenc], res=1280x720, fps=60, roleFlags=[main], supported=NO_EXCEEDS_CAPABILITIES, accelerated=YES

[donchummar]

Format exceeds selected codec's capabilities [id=7, mimeType=video/avc, bitrate=249984, codecs=avc1.4D401E, drm=[playready,widevine,cenc], res=480x270, color=NA/NA/NA/8/8, fps=50.0, c2.qti.avc.decoder.secure]

I have sent bug report to [email protected]

[microkatz]

@donchummar

Thank you for submitting your bug report.

From the report I was able to see the following log traces:

tracks [eventTime=0.39, mediaPos=0.00, window=0, period=0
09-02 12:35:46.128 D EventLogger:   group [
09-02 12:35:46.128 D EventLogger:     [X] Track:0, id=1, mimeType=video/avc, container=video/mp4, bitrate=10948900, codecs=avc1.64002a, res=1920x1080, fps=60.0, supported=YES
09-02 12:35:46.128 D EventLogger:   ]
09-02 12:35:46.128 D EventLogger:   group [
09-02 12:35:46.128 D EventLogger:     [X] Track:0, id=0, mimeType=audio/mp4a-latm, container=audio/mp4, bitrate=133203, codecs=mp4a.40.2, channels=2, sample_rate=48000, supported=YES
09-02 12:35:46.128 D EventLogger:   ]
09-02 12:35:46.128 D EventLogger: ]
09-02 12:35:46.428 D EventLogger: downstreamFormat [eventTime=0.69, mediaPos=0.00, window=0, period=0, id=1, mimeType=video/avc, container=video/mp4, bitrate=10948900, codecs=avc1.64002a, res=1920x1080, fps=60.0]
09-02 12:35:46.496 D EventLogger: videoDecoderInitialized [eventTime=0.76, mediaPos=0.00, window=0, period=0, c2.qti.avc.decoder]

Most notably, the device has support for 1920x1080 at 60 fps with the c2.qti.avc.decoder and I will assume that the same decoder has support for 1280x720 at 60 fps. I have a theory for what is occurring:

1. I think your device has multiple hardware decoders for H264, c2.qti.avc.decoder, c2.qti.avc.decoder.secure, c2.qti.avc.decoder.low_latency etc.
2. In the original code fix, ExoPlayer would for H264 streams and a specific decoder, given the PerformancePoint failing, check if the PerformancePoint check fails the CDD required support for 1280p at 60 fps. Although c2.qti.avc.decoder succeeds the check, c2.qti.avc.decoder.secure in this case would not. Hence why in the original bug you said the issue was reproducing for encrypted streams only? For that specific decoder, it would fall back to legacy checks and pass. The resolution would be deemed supported.
3. In the new code, ExoPlayer still checks the CDD required support for 1280p at 60fps but returns for the result for the first found decoder that supports PerformancePoints. I think your scenario is seeing that c2.qti.avc.decoder supports the CDD standard and so is using the PerformancePoints result for all the decoder support checks.

We will need to evaluate a proper solution to this issue. The odd case being that its a specific decoder that is missing the necessary performance point (ex: c2.qti.avc.decoder passes but c2.qti.avc.decoder.secure does not).

[donchummar]

Yes you are right i guess, that why when i play clear content(not drm enabled), its using c2.qti.avc.decoder and plays fine with most highest res possible but when playing drm enabled content which is using c2.qti.avc.decoder.secure it fails and stuck at lowest res possible. Hope you can come up with a solution for this soon

Thanks for looking at this in detail

[microkatz]

@donchummar

I pushed a commit to the main branch, f0fb386 that should hopefully resolve your issue. If you could please check it out and see if it fixes your scenario then that would be great!

[donchummar]

Yeah, it seems like this fixed Galaxy Tab S7 Issue, hope we will get this in an upcoming release
Thank you

[brad-clark]

Do we know when this fix will be in a release (or beta release)?

[microkatz]

The fix was included in the 1.5.0-beta01 release and so will be included in the official 1.5.0 release.

Closing the issue as fix is in release pipeline.