Current state of video playback?
I'm ready to switch over to this for my daily driver but I saw that hardware video playback is not supported. What does video watching look like right now on the 5T? Is it just low frame rate or is it unusable? How close is hardware playback?
Thanks for all the work being done here. Real incredible stuff
Nocturn-Adrift last edited by Nocturn-Adrift
@twiclo I just switched my OnePlus 5 to UT yesterday. The core "Media Player" app offered by default does not work, neither did it work when I daily drove my Nexus 5.
@nocturn-adrift Thank you!
Hopefully in the future I will finish it fully and it will become the default application.
The application does not support subtitles and cannot correctly detect that the file being played is not a supported codec. Sometimes files .mp4 can be made with different codecs.
I am converting everything to WEBM To avoid this mistake
t subtitles and cannot correctly detect that the file being played is not a supported codec. Sometimes files .mp4 can be ma
Hardware acceleration for the GPU is working on all devices, but hardware decoding does not always work out of box:
- It will never work in the browser, no matter what we do. It misses the whole stack in Morph-Browser.
- It will work in media-player if the format is supported by your hardware AND is not a proprietary codec, that means, one where we would need to deliver copyrighted software with our installation.
- You can try different videos, mp4 with common codecs should work pretty well.
@flohack Yes, we have already talked about this.
I think I will fix this error when I can do APT support. I have already managed to successfully compile and run Transmission, FFMPEG, Midnight Commander, PIL library for Python
But here the question arises whether the developers will be ready for such innovations
@pavelprosto no sorry, apt will not be a valid way to install stuff into the UT image a) its limited in size, and the free space varies sometimes, b) every OTA will overwrite those changes.
@pavelprosto The only way to do things right is to integrate them properly with the system what we have: If you have improvements for media-player and the media-pipeline, you need to extend the existing tools, not add alternatives.
@flohack A little off topic but is their plans in the future for flatpacks or snaps? Like Firefox snap? That would have all dependenceys built in.
@trwidick Some day we talked about this. But its not on the immediate roadmap. Snaps cannot support interaction with other Apps via our content-hub exchange, and probably struggle to request permissions like location, microphone, camera etc.
Its is entirely unclear how snaps and flatpacks would interact with the confined environment that was made so clicks can run.
Its not just making support for a packaging format, the whole OS must support it with all APIs. And thats unlikely to be a quick thing, and we must 100% know that this will make sense first.
But, you are invited to explore whats missing, and make a project plan
dobey last edited by
It will work in media-player if the format is supported by your hardware AND is not a proprietary codec, that means, one where we would need to deliver copyrighted software with our installation.
Eh? No. If the hardware supports the codec, it doesn't matter if it's proprietary or not. It's implemented in the hardware, and we don't ship anything differently. That's the whole point of the hybris plug-in to use hardware decoding, so that we don't have to explicitly deal with licensing of mp3 and such, because the hardware vendors already did and it works in Android.
Only if we wanted to ship software implementations in our software, would it be an issue.
@flohack That's why I developed this project. That is, I can write improvements for an existing media player and they will be published?
AppLee last edited by
I think what Florian tried to say is that you created an alternative media player.
That is fine and greatly appreciated.
But if your goal is to improve the default media player, then it's best and easier for you to contribute directly to this project and not start a completely different one.
@dobey Yeah I got it a bit misleading, what I wanted to say is:
- Hardware decoding will help only for those formats that were implemented at the time the device was released, logically hardware wont change with updates after that. On the other side, it could theoretically be some kind of ASIC or whatsoever that the vendor could load with new firmware so that it can learn new formats later.
- So because we cannot load new proprietary codecs into firmware for the decoder ourselves we can just take whats either there in hardware or firmware. For some devices you will find the supported hardware codec lists somewhere.
- If Google comes up with VP9, 10 whatsoever new shiny compression algorithm or your load your loved MKV movie onto the phone in both cases your screen might stay black with mediaplayer. If there is no suitable codec found, hardware or software, it wouldnt play. On the other hand, it could sometimes decode in software, but you notice the device getting hot, video could be stuttering etc.
- Our older phones probably lack some decoders already,
@pavelprosto does that answer your case in some way?