Migrate to androidx-media3 video player #3857
Conversation
…yback works. Play, ff, rew buttons are from inconsistent versions of the product (play is circular, rew and ff aren't). Video caption flickers weirdly.
… use dash (consider rls if we add peertube later)
Previous code didn't distinguish between a down and up motion event, so the description was being shown on the down and immediately removed on the up.
This also means the player has to be recreated as necessary - Make `player` property - Release `player` in `onPause` - Add initializePlayer() to do the initialisation and binding
… when appropriate
|
Tested the patch, works great. Excited to see this moving forward. Many thumbs up 👍👍👍👍 I noticed some quirks.
This reproduces 100%.
I think problem 2 is the only true showstopper here. If we either fix problem 2, or roll back |
|
Screenshot of above-described ~phenomena~
|
|
Thanks for the detailed feedback @mcclure
Having the timeout for the description be different for that (especially in the face of user feedback that the existing timeout of 3 seconds is too short, e.g., #3141) didn't seem like a good idea. The darker background is R.id.exo_controls_background (https://github.com/androidx/media/blob/release/libraries/ui/src/main/res/layout/exo_player_control_view.xml#L23-L26). While that could be shrunk in code to cover just the area taken by the controls, it's also needed to ensure that the media description text is visible. [ Changing the video player to use a bottom sheet to show the media description the way the image viewer does is out of scope for this PR ]
Note that there's a couple of different dimensions to the problem that can make this tricky to reproduce. First, the physical hardware that the user is using. Second, the Mastodon server the user is using. It occurred to me earlier that if you're on server A and I'm on server B and you send me a link to a post that's not working, and it works for me, that doesn't prove anything (I think), because when I view the post the media will be fetched/proxied by server B. So if server A is misconfigured (e.g,. the Range bug, see the comment thread starting at #1310 (comment)) the video might refuse to play because of a server problem. So any time videos are collected it's important to get the video from the same server that the user is reporting the problem from. |
|
Activity crash bug is gone with latest commit! If I were a reviewer I would approve this branch at this point. |
Yeah, that sounds right. What I am thinking is once we're on media3 we should try to set up some kind of systematic process for gathering and submitting such reports. (Yes, I am volunteering to do the organizing work on that.) You make an interesting point about the depth of information we'd need though. Maybe this would require us to move toward in-app reporting infrastructure first. |
I think we probably want to be as far away from that as possible, since we're not in a position to resolve the issues. I'm thinking of:
|
nikclayton
requested review from
connyduck and
mcclure
and removed request for
Tak,
charlag and
connyduck
|
@mcclure - ready for final review, thanks. |
|
LGTM. I tested and the prior crashes with audio I saw are indeed fixed. I clicked the "Review" button and it didn't do anything. |
In the new Tusky version, we switched from "old and busted" Android video player to new "Exoplayer" (PR #3857). This introduced a dark "curtain" covering the entire screen. This patch restores the 23.0 look. This is done by creating a "magic" exo_player_control_view.xml override file.
Behaviour is consistent with previous player except that:
Fixes #3329, #3141, #3126, #2753, #3508, #3291