You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We changed our codec support check in 2.18.2 to check additional performance point data. I don't have a Lenova Tablet Tab M10 FHD Plus, but what happens on the Pixel 2 Android 10 emulator is that it says it supports the format up to 1920x1088 and 960 fps. This is what the decoder is capable of decoding if you give it enough time. But it also tells us that it only supports up to 30 fps for real-time playback (this is what we started checking in addition). Because your stream is only available in 50 fps, none of the available resolutions is deemed supported because they all exceed the maximum supported frame rate. ExoPlayer then still attempts to play the stream, but only in the lowest possible configuration, under the assumption that if it needs to exceed capabilities anyway, then it should select the format that is most likely to work.
So this is all working as intended from the player code perspective, but I'd say it's a device-specific bug for this Lenovo tablet if it underreports its capabilities. In fact, the Android CDD requires all Android 10 devices to support H264 1280x720x 60 fps at least as long as the display has at least as many pixels. Did you see this issue on any other device?
@tonihei Thank you very much for the feedback. A user reported having issues with multiple devices. I will ask for more specific information and report back to you. I myself have no other test device with this issue.
I also have a problem with this on my Samsung Galaxy Tab A7 (SM-T500, Android 12). ExoPlayer reports that tracks in 1080p with a frame rate >30 FPS are exceeding the device capabilities, although I could not see any issues while force playing 60 FPS in the demo app. I came across this issue because the app from my IPTV provider (https://play.google.com/store/apps/details?id=de.telekom.entertaintv.smartphone) has an issue playing specific videos in HD since around a year and also uses ExoPlayer.
has an issue playing specific videos in HD since around a year and also uses ExoPlayer.
This must be unrelated to the issue above, because the code has only been released 4 months ago.
If the device reports that it doesn't support a certain frame rate and you think it should mark it as supported, it's actually best to report this to the device manufacturer itself. The only scalable way to track support for formats across all devices is to let devices declare their level of support directly, because we can't possibly maintain a separate set of supported formats for all devices.
@tonihei Thank you for the comprehensive explanation of the codec support check in version 2.18.2.
I own a tablet TECLAST P20HD, and when I check its video capabilities using the "getSupportedWidthsFor(720)" function, the response is: "videoCapabilities: [2, 1024]."
This means that with the latest player version, it may not be possible to play videos at 1280x720@25 resolution.
However, if I include it in the "needsIgnorePerformancePointsWorkaround" function, the video plays smoothly at 1280x720@25fps.
I understand the concept of using video capabilities to filter out certain video tracks, but it would be beneficial if the player exhibited some flexibility. For instance, if the device indicates support for 1024x720@25, it might also be capable of handling 1280x720@25 (this is the case of the TECLAST). During playback, the player could continuously monitor the vfpo (visual frame presentation offset) value and exclude that track if vfpo consistently reports negative values.
but it would be beneficial if the player exhibited some flexibility
@tidoemanuele How would you implement this logic exactly? ExoPlayer already attempts to exceed the capabilities if the no fully compatible track available. But it's hard to define a logic that works in all cases and to scale well to all devices we really have to rely on reported capabilities.
@tidoemanuele How would you implement this logic exactly?
ExoPlayer already incorporates a similar approach by rounding down the frame rate.
My suggestion is to introduce a level of tolerance to the parameters: width, height, and framerate. To illustrate, consider the following code example with tolerance adjustments, which would grant the TECLAST P20HD and others the capability to play content at 1280x720@25fps while still rejecting potentially too higher resolutions like 1280x720@60fps or 1920x1080@25fps.
I agree in principle that there is likely some room for tolerance, but it's unfortunately not clear how to set it. To make your example work, we'd need to apply 25% tolerance, which is a lot. Codecs can reasonably fail if the formats exceed the maximum size, so exceeding the declared maximum by 25% already feels quite excessive.
ExoPlayer already incorporates a similar approach by rounding down the frame rate
This is true, but this is within integer rounding errors (2-3% tolerance max) and the frame rate is more complicated to define accurately than the resolution (in particular if the stream declares its effective frame rate based on actual timestamps, that may very slightly exceed the expected value, like 30.002 instead of 30.0).
The interesting remaining question is then: What can you as an app do to explicitly exceed the capabilities if you want to?
If you'd like to customize the logic around which format is support by the renderer/decoders, the best way is probably to override MediaCodecVideoRenderer.supportsFormat to add additional logic:
@Override
protected @Capabilities int supportsFormat(
MediaCodecSelector mediaCodecSelector, Format format)
throws MediaCodecUtil.DecoderQueryException {
@Capabilities int support = super.supportsFormat(mediaCodecSelector, format);
if (RendererCapabilities.getFormatSupport(support) == C.FORMAT_HANDLED) {
return support;
}
// Try again with lower resolution.
Format lowerResFormat =
format.buildUpon()
.setWidth(format.width * 4 / 5)
.setHeight(format.height * 4 / 5)
.build();
return super.supportsFormat(mediaCodecSelector, lowerResFormat);
}
I'll close this issue now too because the original device-specific problem has been addressed.
Activity
tonihei commentedon Jan 5, 2023
We changed our codec support check in 2.18.2 to check additional performance point data. I don't have a Lenova Tablet Tab M10 FHD Plus, but what happens on the Pixel 2 Android 10 emulator is that it says it supports the format up to 1920x1088 and 960 fps. This is what the decoder is capable of decoding if you give it enough time. But it also tells us that it only supports up to 30 fps for real-time playback (this is what we started checking in addition). Because your stream is only available in 50 fps, none of the available resolutions is deemed supported because they all exceed the maximum supported frame rate. ExoPlayer then still attempts to play the stream, but only in the lowest possible configuration, under the assumption that if it needs to exceed capabilities anyway, then it should select the format that is most likely to work.
So this is all working as intended from the player code perspective, but I'd say it's a device-specific bug for this Lenovo tablet if it underreports its capabilities. In fact, the Android CDD requires all Android 10 devices to support H264 1280x720x 60 fps at least as long as the display has at least as many pixels. Did you see this issue on any other device?
cemrich commentedon Jan 5, 2023
@tonihei Thank you very much for the feedback. A user reported having issues with multiple devices. I will ask for more specific information and report back to you. I myself have no other test device with this issue.
cemrich commentedon Jan 6, 2023
After reaching out to the user, the issue can only be reproduced on this single device (in addition to the emulator).
I was stumped by the drastic behaviour change between bugfix releases. But now it is looking like a set of rather rare cirumstances.
7 remaining items
Add workaround for wrong PerformancePoints on some devices.
Add workaround for wrong PerformancePoints on some devices.
Add workaround for wrong PerformancePoints on some devices.
jonas-coded commentedon Mar 22, 2023
I also have a problem with this on my Samsung Galaxy Tab A7 (SM-T500, Android 12). ExoPlayer reports that tracks in 1080p with a frame rate >30 FPS are exceeding the device capabilities, although I could not see any issues while force playing 60 FPS in the demo app. I came across this issue because the app from my IPTV provider (https://play.google.com/store/apps/details?id=de.telekom.entertaintv.smartphone) has an issue playing specific videos in HD since around a year and also uses ExoPlayer.
tonihei commentedon Mar 22, 2023
This must be unrelated to the issue above, because the code has only been released 4 months ago.
If the device reports that it doesn't support a certain frame rate and you think it should mark it as supported, it's actually best to report this to the device manufacturer itself. The only scalable way to track support for formats across all devices is to let devices declare their level of support directly, because we can't possibly maintain a separate set of supported formats for all devices.
Chore/migrate media 1.0.2 (#10)
tidoemanuele commentedon Sep 13, 2023
@tonihei Thank you for the comprehensive explanation of the codec support check in version 2.18.2.
I own a tablet TECLAST P20HD, and when I check its video capabilities using the "getSupportedWidthsFor(720)" function, the response is: "videoCapabilities: [2, 1024]."
This means that with the latest player version, it may not be possible to play videos at 1280x720@25 resolution.
However, if I include it in the "needsIgnorePerformancePointsWorkaround" function, the video plays smoothly at 1280x720@25fps.
I understand the concept of using video capabilities to filter out certain video tracks, but it would be beneficial if the player exhibited some flexibility. For instance, if the device indicates support for 1024x720@25, it might also be capable of handling 1280x720@25 (this is the case of the TECLAST). During playback, the player could continuously monitor the vfpo (visual frame presentation offset) value and exclude that track if vfpo consistently reports negative values.
tonihei commentedon Sep 13, 2023
@tidoemanuele How would you implement this logic exactly? ExoPlayer already attempts to exceed the capabilities if the no fully compatible track available. But it's hard to define a logic that works in all cases and to scale well to all devices we really have to rely on reported capabilities.
tidoemanuele commentedon Sep 13, 2023
ExoPlayer already incorporates a similar approach by rounding down the frame rate.
My suggestion is to introduce a level of tolerance to the parameters: width, height, and framerate. To illustrate, consider the following code example with tolerance adjustments, which would grant the TECLAST P20HD and others the capability to play content at 1280x720@25fps while still rejecting potentially too higher resolutions like 1280x720@60fps or 1920x1080@25fps.
tonihei commentedon Sep 15, 2023
I agree in principle that there is likely some room for tolerance, but it's unfortunately not clear how to set it. To make your example work, we'd need to apply 25% tolerance, which is a lot. Codecs can reasonably fail if the formats exceed the maximum size, so exceeding the declared maximum by 25% already feels quite excessive.
This is true, but this is within integer rounding errors (2-3% tolerance max) and the frame rate is more complicated to define accurately than the resolution (in particular if the stream declares its effective frame rate based on actual timestamps, that may very slightly exceed the expected value, like 30.002 instead of 30.0).
The interesting remaining question is then: What can you as an app do to explicitly exceed the capabilities if you want to?
If you'd like to customize the logic around which format is support by the renderer/decoders, the best way is probably to override
MediaCodecVideoRenderer.supportsFormatto add additional logic:I'll close this issue now too because the original device-specific problem has been addressed.
tidoemanuele commentedon Sep 15, 2023
@tonihei thank you for helping us enhance the resilience of our app without compromising the player integrity. We truly appreciate your assistance.
Fallback to legacy sizerate check for H264 if CDD PerfPoint check fails
Fallback to legacy sizerate check for H264 if CDD PerfPoint check fails