fix(android): mediacodec-copy for screen capture visibility (#129)

[RevLaw]

Pull Request

Summary

Use mediacodec-copy as default Android hwdec so decoded frames are not stuck in protected surfaces that screen share (Discord, Meet) shows as black.
Route all Android VideoController hwdec through getDefaultHwdec() by passing null from main playback, home preview, and media bar (TV previously forced auto).
Document that Flutter must stay RenderMode.surface: TextureView would hide the media_kit SurfaceView behind a non-punch-through layer.

The coding was supported by use of Cursor - I hope that the change of the decoding is not breaking anything else. Also, the analyzer says it could have a performance impact. But in my testing everything feels the same

• Closes [Feature] Screenshare content playing #129
• Fixes [Feature] Screenshare content playing #129
• Related to [Feature] Screenshare content playing #129

Type of Change

• Bug fix
• New feature
• Refactor
• Performance improvement
• UI/UX update
• Documentation update
• Build/CI change
• Other (describe):

Changes Made

• Pass hwdec: null on all Android VideoController construction in main playback so defaults resolve to mediacodec-copy via getDefaultHwdec() (removes TV-only auto override).
• Align home preview and media bar trailer controllers to the same Android null hwdec behavior.
• In MainActivity, set RenderMode.surface and TransparencyMode.transparent and document why RenderMode.texture is incompatible with the current media_kit + Flutter layering.

Platform

• Android
• iOS
• macOS
• Windows
• Linux
• All / Shared code

Testing

Describe how this change was tested.

• Tested on emulator / simulator
• Tested on physical device
• Manual testing completed
• Not tested (explain why):

Test Steps

1. Install a build from this branch on a physical Android phone (arm64 debug/release as you usually use).
2. Start playback of a transcoded/direct stream that uses hardware decode.
3. Start screen share in Discord or Google Meet and confirm video is visible (not black) while audio continues.

Screenshots (if applicable)

Include screenshots or recordings for UI changes.

Checklist

• Code builds successfully
• Code follows project style and conventions
• No unnecessary commented-out code
• No new warnings introduced

[RadicalMuffinMan]

Hi! I added exoplayer as the default player with full DV, HDR, HDR10, HDR10+, DTS, DA, etc and also made some changes to MPV, could you pull latest and test your branch again, please and thank you.

[RevLaw]

After testing the recent commits, I found that commit 763c9aa appears to have completely broken playback on my Samsung Galaxy Tab S11.

Playback was functioning correctly before this commit, but no longer works afterward. I wasn’t able to identify the exact cause. From reviewing the changes, most modifications seem related to the Android TV component, which makes the issue on a tablet device somewhat unexpected.

At this point, I can only confirm that the regression was introduced with this commit, but I cannot yet determine which specific change is responsible.

[RadicalMuffinMan]

what exactly is broken? one file, all files, a specific codec. On my pixel 9 pro xl, playback is fully functional still.

[RevLaw]

After compiling the apk from the last commit ec472bb the video player just shows an endless loading animation. My guess at the moment is an issue with Emby. Because I'm using the app with an Emby connection not Jellyfin.

[RadicalMuffinMan]

that helps. there is currently an emby issue I am working towards for the next release. currently it is still broken