Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

gpu-next: Unwatchable framerate when software decoding HEVC 10-bit video #855

Open
soredake opened this issue Jan 18, 2024 · 4 comments · May be fixed by mpv-player/mpv#13682
Open

gpu-next: Unwatchable framerate when software decoding HEVC 10-bit video #855

soredake opened this issue Jan 18, 2024 · 4 comments · May be fixed by mpv-player/mpv#13682
Labels
bug gpu-next

Comments

@soredake
Copy link

soredake commented Jan 18, 2024 •
edited

Important information

Android version: 11 (One UI 3.1)

mpv-android version: 2023-11-30-release / 8033 (release)

Description

My tablet does not support hardware decoding HEVC 10-bit so only software decoding is available for this kind of videos, and frame rate with software decoding is unwatchable, I get 0.7-0.8 fps.

Log output

mpv-android-framerate.log

Additional information

File that I played to test https://www.larmoire.info/jellyfish/media/jellyfish-3-mbps-hd-hevc-10bit.mkv

Enabling "Low-quality video decoding" does not help. Both VLC and MX Player have okay or good frame rate with hevc 10-bit.
@soredake soredake mentioned this issue Jan 18, 2024
Closed
@sfan5 sfan5 changed the title Unwatchable framerate when software decoding HEVC 10-bit video gpu-next: Unwatchable framerate when software decoding HEVC 10-bit video Jan 25, 2024
@sfan5 sfan5 added the bug label Jan 25, 2024
@sfan5
Copy link
Member

sfan5 commented Jan 25, 2024

I can reproduce and the lack of performance is easy to explain:

mpv is converting the 10-bit YUV to 32-bit floating point RGB using unoptimized code paths (because nobody ever does this):

01-18 19:05:34.768 27266 28544 V mpv     : [vf:v] [convert] 1920x1080 yuv420p10 bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0
01-18 19:05:34.769 27266 28544 V mpv     : [autoconvert:info] Converting yuv420p10 -> gbrpf32
01-18 19:05:34.776 27266 28544 V mpv     : [ffmpeg:v] swscaler: Lanczos scaler, from yuv420p10le to gbrpf32le using C
01-18 19:05:35.137 27266 28544 V mpv     : event: video-reconfig
01-18 19:05:35.137 27266 27266 E mpv     : mpv_get_property(track-list/0/lang) format 1 returned error property unavailable
01-18 19:05:35.138 27266 28544 V mpv     : [vf:v] [out] 1920x1080 gbrpf32 rgb/bt.709/bt.1886/full/display CL=mpeg2/4/h264 crop=1920x1080+0+0

The mystery here is why mpv and/or gpu-next might be picking that format.

@MrDark-code
Copy link

@soredake in mpv.conf :

vf=format=fmt=yuv420

@sfan5
Copy link
Member

sfan5 commented Feb 4, 2024

Btw I tracked this down last week or so and the gist of this issue is that libplacebo uses/prefers slightly different texture formats for uploading on GLES than vo_gpu and in the end that means it doesn't find a "better" format than (emulated) 32-bit float rgb

@sfan5 sfan5 added the gpu-next label Feb 7, 2024
@sfan5 sfan5 mentioned this issue Mar 3, 2024
Draft
@sfan5 sfan5 linked a pull request Mar 10, 2024 that will close this issue
Draft
@sfan5
Copy link
Member

sfan5 commented Mar 15, 2024

this is actually a missing feature in gpu-next/libplacebo and now tracked as mpv-player/mpv#13706

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug gpu-next
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

vo_gpu_next: use emulated formats only as fallback sfan5/mpv
3 participants
@sfan5 @soredake @MrDark-code