[video_player_android] Report display size for anamorphic video

[voledyaev]

VideoSize.pixelWidthHeightRatio was never read, so videos stored with non-square pixels (anamorphic content) reported their coded size instead of their display size. VideoPlayerValue.size therefore carried the wrong aspect ratio and such videos rendered stretched.

Example of a real affected file: coded 1080x720 with a 3:8 pixel aspect ratio displays as 405x720, but size was reported as 1080x720 — a 2.67x horizontal stretch.

This scales the reported width by the pixel aspect ratio, which is what media3's own PlayerView does:

float videoAspectRatio = (height == 0 || width == 0) ? 0 : (width * videoSize.pixelWidthHeightRatio) / height;

Both event listeners are updated:

• Texture path — ExoPlayer reports a pixelWidthHeightRatio that already accounts for any applied rotation (MediaCodecVideoRenderer inverts it for 90°/270°), so the ratio is applied to the reported width regardless of the rotation correction.
• Platform view path — Format.pixelWidthHeightRatio describes the unrotated frame, so the ratio is applied before the existing width/height swap.

The scaling is skipped unless the ratio is greater than 0 and not 1, so playback of ordinary square-pixel video is byte-for-byte unchanged.

Verified on a physical anamorphic sample (1080x720, SAR 3:8) on Android 15: previously stretched, now rendered at the correct 9:16 display aspect. iOS is unaffected — video_player_avfoundation already reports presentationSize, which is pixel-aspect corrected, which is why this bug is Android-only.

(No before/after screenshots: the sample videos available to me are private medical content and cannot be published.)

Fixes flutter/flutter#132934
Fixes flutter/flutter#94234

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the AI contribution guidelines and understand my responsibilities, or I am not using AI tools.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request addresses an issue where anamorphic videos (with a pixel aspect ratio other than 1.0) are rendered stretched by scaling the coded width by the pixel aspect ratio in both PlatformViewExoPlayerEventListener and TextureExoPlayerEventListener. Unit tests have been added to verify this scaling behavior. The feedback suggests ensuring that the scaled width is at least 1 to prevent layout issues or division-by-zero errors in Flutter if the calculation rounds down to 0.

[gemini-code-assist]

If width is a small positive integer and pixelWidthHeightRatio is very small, Math.round(width * pixelWidthHeightRatio) can evaluate to 0. A width of 0 is invalid and can cause layout issues or division-by-zero errors in Flutter. We should ensure that if the original width was positive, the scaled width is at least 1.

Suggested change

	if (pixelWidthHeightRatio > 0 && pixelWidthHeightRatio != 1f) {
	width = Math.round(width * pixelWidthHeightRatio);
	}
	if (pixelWidthHeightRatio > 0 && pixelWidthHeightRatio != 1f) {
	int scaledWidth = Math.round(width * pixelWidthHeightRatio);
	width = width > 0 ? Math.max(1, scaledWidth) : scaledWidth;
	}

[gemini-code-assist]

If width is a small positive integer and pixelWidthHeightRatio is very small, Math.round(width * pixelWidthHeightRatio) can evaluate to 0. Since width is guaranteed to be non-zero here, we should ensure the scaled width is at least 1 to prevent layout issues or division-by-zero errors in Flutter.

Suggested change

	if (pixelWidthHeightRatio > 0 && pixelWidthHeightRatio != 1f) {
	width = Math.round(width * pixelWidthHeightRatio);
	}
	if (pixelWidthHeightRatio > 0 && pixelWidthHeightRatio != 1f) {
	width = Math.max(1, Math.round(width * pixelWidthHeightRatio));
	}

[voledyaev]

Thanks — addressed in 66f2dfb, with one deliberate difference from the suggested diff.

In TextureExoPlayerEventListener the width is guaranteed non-zero by the enclosing check, so a plain Math.max(1, ...) is enough.

In PlatformViewExoPlayerEventListener the width comes from Format, where an unknown value is Format.NO_VALUE (-1), not 0. Applying width > 0 ? Math.max(1, scaledWidth) : scaledWidth there would turn -1 into Math.round(-1 * ratio) == 0, i.e. silently convert "unknown" into "zero", which is the failure mode we are trying to avoid. Guarding the whole branch with width > 0 instead leaves NO_VALUE untouched:

if (width > 0 && pixelWidthHeightRatio > 0 && pixelWidthHeightRatio != 1f) {
  width = Math.max(1, Math.round(width * pixelWidthHeightRatio));
}

Both behaviours are now covered by tests (...ReportsAtLeastOnePixel_whenPixelAspectRatioIsDegenerate on both listeners, plus onPlaybackStateChangedReadyLeavesUnknownWidthUnscaled).

[camsim99]

LGTM!