Dudemanguy
commented
3 years ago Does v4l2m2m even work on wayland? I have absolutely no idea.
Closed danboid closed 1 year ago
Dudemanguy
commented
3 years ago Does v4l2m2m even work on wayland? I have absolutely no idea.
danboid
commented
3 years ago This thread reports success using mpv under Wayland / Weston with a similar hardware config to mine (meson vpu) although they don't give details on what format videos they are playing etc. I SHOULD be OK to play a 30 fps 4K h264 file, if all the many ducks are aligned and the kernel code isn't buggy. Of course, this could well be a kernel rather than an mpv bug?
I prefer KDE to GNOME but if the mpv devs would prefer I test under Wayland GNOME instead that's fine by me.
danboid
commented
3 years ago I have updated my bug report with a YT video of mpv trying to play the test video.
I'm very impressed with the X96 Air Q1000 as a budget Linux box, even without a fully functional mpv. It has 4 GB of DDR 4 RAM, it can boot directly off a USB 3 SSD, it has gigabit ethernet, Wifi, a better GPU and faster CPU than the Rpi 4, 3 USB ports (which can be used to power the board) and you get a case and remote all for about £30! Amazing! Even moreso if we can get mpv working nicely on it!
danboid
commented
3 years ago Reading through the mpv output, I noticed this line:
[vo/gpu/wayland] Compositor doesn't support the wp_presentation protocol!Is that required for mpv v4l2m2m / meson to work?
Dudemanguy
commented
3 years ago No it's not related. Some of the visual glitches in your video look quite strange but I suppose that's just hwdec at work.
CounterPillow
commented
3 years ago fwiw the visual glitches may also be related to panfrost enabling afbc in mesa 21.1 by default on some more platforms.
danboid
commented
3 years ago @CounterPillow I presume afbc can't be disabled or worked around other than disabling it within mesa?
I will open a bug against mesa if this is actually their problem. Maybe its a mesa, kernel and mpv problem? This is pretty virgin territory, I admit.
CounterPillow
commented
3 years ago there's an environment variable you can set in your environment to disable it (PAN_MESA_DEBUG=noafbc in /etc/environment, then reboot), but this is all pure speculation on my part so opening a bug with them does not seem appropriate at this time, might still just be the hwdec messing up.
danboid
commented
3 years ago I have tried exporting PAN_MESA_DEBUG=noafbcin /etc/environment (and rebooting and checking it's present with env) now but it doesn't seem to have made any difference to the playback.
danboid
commented
3 years ago I have tried playing a h264 file using the same codec and transport as the test video above but using 1080p / 30 fps instead. It seems to drop less frames during playback but its still a jerky mess and with the same flicker/distortion you can see in the 4K playback video.
danboid
commented
3 years ago I should note that I have seen a similar sort of flicker occur on this box under Wayland (both GNOME and KDE) when playing videos under FireFox, the difference being that YT videos play at a decent framerate, at least when not full screen with 4K as it would seem FF is not using any hw accel, and mpv flickers more frequently with my test video(s) than FF does playing videos. I can post a video of Firefox playing videos if required?
danboid
commented
3 years ago My test 4K h264 video plays perfectly under the imaginatively titled Video player app that is installed by default under the stock Android rom of the X96 Air Q1000 so the hardware can handle it.
danboid
commented
3 years ago I have also tried playing some HEVC files under mpv on this box with very similar results to h264 - very slow/jerky playback.
danboid
commented
3 years ago My TV supports Freesync but not g-sync. Android can play this video fine on the same display.
danboid
commented
3 years ago I was having trouble dumping the edid on my TV box so I did it on my laptop. Shouldn't matter how I get it, right?
$ edid-decode < LG
edid-decode (hex):
00 ff ff ff ff ff ff 00 1e 6d 80 80 01 01 01 01
01 1e 01 03 80 a0 5a 78 0a ee 91 a3 54 4c 99 26
0f 50 54 a1 08 00 31 40 45 40 61 40 71 40 81 80
d1 c0 01 01 01 01 08 e8 00 30 f2 70 5a 80 b0 58
8a 00 40 84 63 00 00 1e 66 21 50 b0 51 00 1b 30
40 70 36 00 40 84 63 00 00 1e 00 00 00 fd 00 18
78 1e 87 3c 00 0a 20 20 20 20 20 20 00 00 00 fc
00 4c 47 20 54 56 20 53 53 43 52 0a 20 20 01 e5
02 03 60 f1 5a 61 60 10 1f 66 65 04 13 05 14 03
02 12 20 21 22 15 01 5d 5e 5f 62 63 64 3f 40 2c
09 57 07 15 07 50 57 07 01 67 04 03 6e 03 0c 00
20 00 b8 3c 24 00 80 01 02 03 04 6a d8 5d c4 01
78 80 03 02 30 78 e2 00 cf e3 05 c0 00 e3 06 0d
01 e2 0f 33 eb 01 46 d0 00 2a 3c 03 51 83 70 83
6f c2 00 a0 a0 a0 55 50 30 20 35 00 40 84 63 00
00 1e 00 00 00 00 00 00 00 00 00 00 00 00 00 d9
----------------
EDID version: 1.3
Manufacturer: GSM Model 32896 Serial Number 16843009
Made in week 1 of 2020
Digital display
Maximum image size: 160 cm x 90 cm
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Color Characteristics
Red: 0.6396, 0.3300
Green: 0.2998, 0.5996
Blue: 0.1503, 0.0595
White: 0.3125, 0.3291
Established Timings I & II
720x400 70.082 Hz 9:5 31.467 kHz 28.320 MHz (IBM)
640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz (DMT)
800x600 60.317 Hz 4:3 37.879 kHz 40.000 MHz (DMT)
1024x768 60.004 Hz 4:3 48.363 kHz 65.000 MHz (DMT)
Standard Timings
640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz (DMT)
800x600 60.317 Hz 4:3 37.879 kHz 40.000 MHz (DMT)
1024x768 60.004 Hz 4:3 48.363 kHz 65.000 MHz (DMT)
1152x864 60.000 Hz 4:3 53.700 kHz 81.624 MHz (GTF)
1280x1024 60.020 Hz 5:4 63.981 kHz 108.000 MHz (DMT)
1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz (DMT)
Detailed mode: Clock 594.000 MHz, 1600 mm x 900 mm
3840 4016 4104 4400 (176 88 296)
2160 2168 2178 2250 ( 8 10 72)
+hsync +vsync
VertFreq: 60.000 Hz, HorFreq: 135.000 kHz
Detailed mode: Clock 85.500 MHz, 1600 mm x 900 mm
1360 1424 1536 1792 ( 64 112 256)
768 771 777 795 ( 3 6 18)
+hsync +vsync
VertFreq: 60.015 Hz, HorFreq: 47.712 kHz
Display Range Limits
Monitor ranges (GTF): 24-120 Hz V, 30-135 kHz H, max dotclock 600 MHz
Display Product Name: LG TV SSCR
Has 1 extension block
Checksum: 0xe5
----------------
CTA-861 Extension Block Revision 3
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
92 bytes of CTA data blocks
Video Data Block
3840x2160 60.000 Hz 16:9 135.000 kHz 594.000 MHz (VIC 97)
3840x2160 50.000 Hz 16:9 112.500 kHz 594.000 MHz (VIC 96)
1920x1080 60.000 Hz 16:9 67.500 kHz 148.500 MHz (VIC 16)
1920x1080 50.000 Hz 16:9 56.250 kHz 148.500 MHz (VIC 31)
4096x2160 60.000 Hz 256:135 135.000 kHz 594.000 MHz (VIC 102)
4096x2160 50.000 Hz 256:135 112.500 kHz 594.000 MHz (VIC 101)
1280x720 60.000 Hz 16:9 45.000 kHz 74.250 MHz (VIC 4)
1280x720 50.000 Hz 16:9 37.500 kHz 74.250 MHz (VIC 19)
1920x1080i 60.000 Hz 16:9 33.750 kHz 74.250 MHz (VIC 5)
1920x1080i 50.000 Hz 16:9 28.125 kHz 74.250 MHz (VIC 20)
720x480 59.940 Hz 16:9 31.469 kHz 27.000 MHz (VIC 3)
720x480 59.940 Hz 4:3 31.469 kHz 27.000 MHz (VIC 2)
720x576 50.000 Hz 16:9 31.250 kHz 27.000 MHz (VIC 18)
1920x1080 24.000 Hz 16:9 27.000 kHz 74.250 MHz (VIC 32)
1920x1080 25.000 Hz 16:9 28.125 kHz 74.250 MHz (VIC 33)
1920x1080 30.000 Hz 16:9 33.750 kHz 74.250 MHz (VIC 34)
1440x576i 50.000 Hz 4:3 15.625 kHz 27.000 MHz (VIC 21)
640x480 59.940 Hz 4:3 31.469 kHz 25.175 MHz (VIC 1)
3840x2160 24.000 Hz 16:9 54.000 kHz 297.000 MHz (VIC 93)
3840x2160 25.000 Hz 16:9 56.250 kHz 297.000 MHz (VIC 94)
3840x2160 30.000 Hz 16:9 67.500 kHz 297.000 MHz (VIC 95)
4096x2160 24.000 Hz 256:135 54.000 kHz 297.000 MHz (VIC 98)
4096x2160 25.000 Hz 256:135 56.250 kHz 297.000 MHz (VIC 99)
4096x2160 30.000 Hz 256:135 67.500 kHz 297.000 MHz (VIC 100)
1920x1080 120.000 Hz 16:9 135.000 kHz 297.000 MHz (VIC 63)
1920x1080 100.000 Hz 16:9 112.500 kHz 297.000 MHz (VIC 64)
Audio Data Block
Linear PCM, max channels 2
Supported sample rates (kHz): 192 96 48 44.1 32
Supported sample sizes (bits): 24 20 16
AC-3, max channels 6
Supported sample rates (kHz): 48 44.1 32
Maximum bit rate: 640 kb/s
Dolby Digital+, max channels 8
Supported sample rates (kHz): 48 44.1 32
Supports Joint Object Coding
MAT (MLP), max channels 8
Supported sample rates (kHz): 48
Vendor-Specific Data Block, OUI 0x000c03 (HDMI)
Source physical address 2.0.0.0
Supports_AI
DC_36bit
DC_30bit
DC_Y444
Maximum TMDS clock: 300 MHz
Supported Content Types:
Cinema
Extended HDMI video details:
HDMI VICs:
3840x2160 30.000 Hz 16:9 67.500 kHz 297.000 MHz (HDMI VIC 1)
3840x2160 25.000 Hz 16:9 56.250 kHz 297.000 MHz (HDMI VIC 2)
3840x2160 24.000 Hz 16:9 54.000 kHz 297.000 MHz (HDMI VIC 3)
4096x2160 24.000 Hz 256:135 54.000 kHz 297.000 MHz (HDMI VIC 4)
Vendor-Specific Data Block, OUI 0xc45dd8 (HDMI Forum)
Version: 1
Maximum TMDS Character Rate: 600 MHz
SCDC Present
Supports 12-bits/component Deep Color 4:2:0 Pixel Encoding
Supports 10-bits/component Deep Color 4:2:0 Pixel Encoding
Extended tag: Video Capability Data Block
YCbCr quantization: Selectable (via AVI YQ)
RGB quantization: Selectable (via AVI Q)
PT scan behavior: No Data
IT scan behavior: Supports both over- and underscan
CE scan behavior: Supports both over- and underscan
Extended tag: Colorimetry Data Block
BT2020YCC
BT2020RGB
Extended tag: HDR Static Metadata Data Block
Electro optical transfer functions:
Traditional gamma - SDR luminance range
SMPTE ST2084
Hybrid Log-Gamma
Supported static metadata descriptors:
Static metadata type 1
Extended tag: YCbCr 4:2:0 Capability Map Data Block
3840x2160 60.000 Hz 16:9 135.000 kHz 594.000 MHz (VIC 97)
3840x2160 50.000 Hz 16:9 112.500 kHz 594.000 MHz (VIC 96)
4096x2160 60.000 Hz 256:135 135.000 kHz 594.000 MHz (VIC 102)
4096x2160 50.000 Hz 256:135 112.500 kHz 594.000 MHz (VIC 101)
Extended tag: Vendor-Specific Video Data Block, OUI 0x00d046 (Dolby)
2a 3c 03 51 83 70 83 *<.Q.p.
Detailed mode: Clock 497.750 MHz, 1600 mm x 900 mm
2560 2608 2640 2720 ( 48 32 80)
1440 1443 1448 1525 ( 3 5 77)
+hsync +vsync
VertFreq: 119.998 Hz, HorFreq: 182.996 kHz
Checksum: 0xd9"Can you switch to 24/1.001 and check out how many zeroes it will print?"
I don't understand what you are asking me to do?
Dudemanguy
commented
3 years ago The display refresh hz being slightly weird or whatever shouldn't result in poor performance as shown above. Seems like a red herring.
danboid
commented
3 years ago @ValZapod
I'm still unsure what you want me to do. In my case, when connecting to my laptop running X the xrandr command would be:
xrandr --output DP-1 --rate 23.976 --mode 3840x2160but what do you want me to check after running that? xrandr doen't change the edid does it?
My TV is a LG 65NANO866.
danboid
commented
3 years ago I'm trying to play this video on my ARM TV box running wayland tho. X runs like absolute s#it but Wayland runs pretty well.
I am new to Wayland. Does xrandr still work with Wayland? I presumed it was X only. If so, what is the equivalent Wayland command?
danboid
commented
3 years ago It turns out the display settings in wayland plasma are buggy. I am currently unable to change the resolution and refresh rate under wayKDE but it does work under wayland GNOME.
I configured the GNOME display to 4K @ 23.98 Hz and now the flicker is gone and the video at least plays (the last time I tried playing this test video under wayland GNOME mpv crashed) and its a little less jerky but it still drops hundreds of frames in less than 30 seconds and is nowhere near as smooth as when the video is played under Android.
Here's video of me playing the video under wayland GNOME:
https://www.youtube.com/watch?v=86oCKnUzcW8
Here is the log:
$ mpv VID_20210512_180639.mp4
[cplayer] Waiting for scripts...
[cplayer] Set property: shared-script-properties -> 1
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[cplayer] Done loading scripts.
[cplayer] Running hook: ytdl_hook/on_load
[ytdl_hook] ytdl:// hook
[ytdl_hook] not a ytdl:// url
[ifo_dvdnav] Opening VID_20210512_180639.mp4
[bdmv/bluray] Opening VID_20210512_180639.mp4
[file] Opening VID_20210512_180639.mp4
[demux] Trying demuxers for level=normal.
[cplayer] Set property: shared-script-properties -> 1
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[lavf] Found 'mov,mp4,m4a,3gp,3g2,mj2' at score=100 size=2048.
[file] stream level seek from 131072 to 810264
[demux] Detected file format: mov,mp4,m4a,3gp,3g2,mj2 (libavformat)
[cplayer] Opening done: VID_20210512_180639.mp4
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[find_files] Loading external files in .
[cplayer] Running hook: ytdl_hook/on_preloaded
[lavf] select track 0
[lavf] select track 1
(+) Video --vid=1 (*) (h264 3840x2160 30.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[vo/gpu/opengl] Initializing GPU context 'wayland'
[vo/gpu/wayland] Registered for protocol wl_compositor
[vo/gpu/wayland] Registered for protocol wl_shm
[vo/gpu/wayland] Registered for protocol wl_output
[vo/gpu/wayland] Registered for protocol wl_data_device_manager
[vo/gpu/wayland] Registered for protocol xdg_wm_base
[vo/gpu/wayland] Registered for protocol wl_seat
[vo/gpu/wayland] Registered for protocol wp_presentation
[vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.
[vo/gpu/wayland] Compositor doesn't support the zxdg_decoration_manager_v1 protocol!
[vo/gpu/wayland] Compositor doesn't support the zwp_idle_inhibit_manager_v1 protocol!
[vo/gpu/opengl] EGL_VERSION=1.4
[vo/gpu/opengl] EGL_VENDOR=Mesa Project
[vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL OpenGL_ES
[vo/gpu/opengl] Trying to create Desktop OpenGL context.
[vo/gpu/wayland] GL_VERSION='3.1 (Core Profile) Mesa 21.1.1'
[vo/gpu/wayland] Detected desktop OpenGL 3.1.
[vo/gpu/wayland] GL_VENDOR='Panfrost'
[vo/gpu/wayland] GL_RENDERER='Mali G31 (Panfrost)'
[vo/gpu/wayland] GL_SHADING_LANGUAGE_VERSION='1.40'
[vo/gpu/wayland] Loaded extension GL_ARB_sync.
[vo/gpu/wayland] Loaded extension GL_ARB_get_program_binary.
[vo/gpu/wayland] Loaded extension GL_ARB_shader_storage_buffer_object.
[vo/gpu/wayland] Loaded extension GL_ARB_arrays_of_arrays.
[vo/gpu/wayland] Loaded extension GL_ARB_debug_output.
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] Disabling HDR peak computation (one or more of the following is not supported: compute shaders=0, SSBO=1).
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vo/gpu/wayland] Registered output GSM LG TV SSCR (0x4):
[vo/gpu/wayland] x: 0px, y: 0px
[vo/gpu/wayland] w: 3840px (1600mm), h: 2160px (900mm)
[vo/gpu/wayland] scale: 1
[vo/gpu/wayland] Hz: 60.000000
[vo/gpu] Resize: 0x0
[vd] Container reported FPS: 30.000300
[vd] Codec list:
[vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
[vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper
[vd] Opening decoder h264
[vd] No hardware decoding requested.
[vd] Using software decoding.
[vd] Detected 4 logical cores.
[vd] Requesting 5 threads for decoding.
[vd] Selected codec: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
[vf] User filter list:
[vf] (empty)
[ad] Codec list:
[ad] aac - AAC (Advanced Audio Coding)
[ad] aac_fixed (aac) - AAC (Advanced Audio Coding)
[ad] Opening decoder aac
[ad] Requesting 1 threads for decoding.
[ad] Selected codec: aac (AAC (Advanced Audio Coding))
[af] User filter list:
[af] (empty)
[cplayer] Starting playback...
[af] [in] 48000Hz stereo 2ch floatp
[af] [userspeed] 48000Hz stereo 2ch floatp
[af] [userspeed] (disabled)
[af] [convert] 48000Hz stereo 2ch floatp
[file] stream level seek from 1221442 to 834600
[file] stream level seek from 965672 to 1221442
[file] stream level seek from 1635391 to 835102
[file] stream level seek from 966174 to 1635391
[ao] Trying audio driver 'pulse'
[ao/pulse] requested format: 48000 Hz, stereo channels, floatp
[ao/pulse] Library version: 14.2.0
[ao/pulse] Proto: 34
[ao/pulse] Server proto: 4294967295
[ao/pulse] Channel layouts:
[ao/pulse] - #fl
[ao/pulse] - #fr
[ao/pulse] - #fc
[ao/pulse] - #lfe
[ao/pulse] - #bl
[ao/pulse] - #br
[ao/pulse] - #flc
[ao/pulse] - #frc
[ao/pulse] - #bc
[ao/pulse] - #sl
[ao/pulse] - #sr
[ao/pulse] - #tc
[ao/pulse] - #tfl
[ao/pulse] - #tfc
[ao/pulse] - #tfr
[ao/pulse] - #tbl
[ao/pulse] - #tbc
[ao/pulse] - #tbr
[ao/pulse] result: stereo
[ao/pulse] device buffer: 6718 samples.
[ao/pulse] using soft-buffer of 9600 samples.
AO: [pulse] 48000Hz stereo 2ch float
[cplayer] AO: Description: PulseAudio audio output
[autoconvert] inserting resampler
[swresample] format change, reinitializing resampler
[swresample] 48000Hz stereo floatp -> 48000Hz stereo float
[af] [out] 48000Hz stereo 2ch float
[vd] DR failed - disabling.
[vd] Using software decoding.
[vd] Decoder format: 3840x2160 [0:1] yuv420p auto/bt.601-625/auto/limited/auto CL=mpeg2/4/h264
[vd] Using container aspect ratio.
[vf] [in] 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [userdeint] 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [userdeint] (disabled)
[vf] [autorotate] 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [autorotate] (disabled)
[vf] [convert] 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [convert] (disabled)
[vf] [out] 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
VO: [gpu] 3840x2160 yuv420p
[cplayer] VO: Description: Shader-based GPU Renderer
[vo/gpu] reconfig to 3840x2160 yuv420p bt.709/bt.601-625/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vo/gpu/wayland] Reconfiguring!
[vo/gpu] Resize: 3840x2160
[vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[vo/gpu] Video scale: 1.000000/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Texture for plane 0: 3840x2160
[vo/gpu] Texture for plane 1: 1920x1080
[vo/gpu] Texture for plane 2: 1920x1080
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 3840x2160
[vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[vo/gpu] Video scale: 1.000000/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Reported display depth: 8
[cplayer] first video frame after restart shown
[cplayer] audio ready
[cplayer] delaying audio start 0.012188 vs. 0.000000, diff=0.012188
[cplayer] playback restart complete @ 0.000000, audio=ready, video=playing
[cplayer] Set property: shared-script-properties -> 1
AV: 00:00:00 / 00:00:20 (0%) A-V: 0.000
[cplayer] starting audio playback
[ao/pulse] starting AO
DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memoryIt's not working correctly. Under X, mpv is fine but has anyone got mpv working properly with Wayland under any Linux distro, on any architecture using any GPU or is mpv's wayland support just not there yet?
Today I installed Manjaro unstable on an old i7 desktop with a nvidia GPU (GeForce 650 ti I think). My test video played fine with mpv under X11 plasma but I couldn't get it to play at all under plasma wayland nor under GNOME wayland, I tried different refresh rates but no joy.
Under amd64 nvidia plasma, I have an empty mpv.conf but I've been using the command:
mpv --gpu-context=wayland
Might I need any more options or should I be using a different gpu-context? Funnily enough, I have had more success playing my test video on the £30 TV box than using an i7 with 12 GB RAM etc, at least I can see some of the frames on the Mali TV box.
I did have a Radeon RX 580 GPU and I was going to use that to test mpv under wayland on amd64 but unfortunately it seems my Radeon is dead. I have read Wayland works better on modern Intel and AMD GPUs than NVIDIA but I'm using the latest NVIDIA driver I can get for my GPU - 465.xx . I've got a machine with an older Intel HD but its not quite up to the job of running Wayland plasma at 4K.
I have also read online that the mpv devs don't support mpv under wayland GNOME? Is this true? Which Wayland compositor has had the most testing with mpv?
Maybe I should open another ticket for mpv on Nvidia plasma or is this combo known not to work already?
Dudemanguy
commented
3 years ago NVIDIA on wayland is a broken mess. Expect nothing good from it unless NVIDIA fixes their drivers one day (good luck).
I have also read online that the mpv devs don't support mpv under wayland GNOME? Is this true?
That is not true. mpv intends to support all compositors that properly follow wayland protocols (which does include GNOME).
Dudemanguy
commented
3 years ago Until they add GBM support or something similar that allows direct access to buffers, it's basically a big hack.
Dudemanguy
commented
3 years ago EGLStreams are good enough.
It's not. Tying a display server to specifically EGL is actually insanity.
Also they are working on GBM
I'll believe it when it actually exists and works.
danboid
commented
3 years ago Have any of you successfully used mpv under Wayland (on amd64 or ARM)? If so, what combo of OS, GPU and compositor are/were you using? Obviously not Nvidia! :)
Did you test 4K or UHD decoding and playback (of h264 or HEVC)?
EDIT
Wayland, not plasma but I'm mainly interested in Plasma. I don't really like GNOME or sway.
Dudemanguy
commented
3 years ago I use mpv on wayland everyday of course (amdgpu on sway). Everything works fine for me (of course), but I don't own any ARM machines so I can't say anything about their performance or lack thereof.
danboid
commented
3 years ago I'd be happy to buy you a X96 Air if you think you could get mpv working on it @Dudemanguy. Might that be a challenge that would interest you?
I was disappointed that the RPi 4 cannot decode h264 @ 4K in hardware, h264 still being a very widely used codec. These S905X3 based TV boxes can decode 4K h264 (and HEVC, VP 9 etc) in hardware so as far as mpv is concerned these meson TV boxes are arguably (could be) a superior platform for using mpv. On top of that you get a case, a remote and SPDIF for about half the price of an RPi 4. The Odroid C4 is almost identical in spec to the X96 Air Q1000, same SoC etc. The C4 has GPIO pins which the X96 Air does not but the C4 is also twice the price. The X96 Air has a serial port but you have to solder the headers on if you want it.
I have got USB 3 boot, gigabit ethernet, wifi, blutooth, accelerated GLES 3 and HDMI audio all working on the X96 Air under Manjaro so its really just the hardware video decoding that isn't working under proper (non-Android) Linux now.
I think it'd be very cool to have a ~£30 Linux box that could play 4K videos with mpv, don't you?
danboid
commented
3 years ago I have already seen mpv working great with HW decoding of 4K videos on an ARM device on my Jetson Nano but that is under X11 and using all that Nvidia nastiness that no-one wants. It'd be much better to have it working on these dirt cheap meson boards that aren't tied to Nvidia's stuff.
Dudemanguy
commented
3 years ago Performance issues are mostly down to drivers and hardware. There's nothing that can really be done from mpv's end. All of the tests I've done show that xorg and wayland on my hardware perform essentially identical which is expected.
danboid
commented
3 years ago Today I updated Manjaro unstable on my X96 Air and I tested playing my test video under mpv at all of the refresh rates that the gnome display manager offers for 3840x2160, the res of my test clip.
When using 23 to 25 Hz, the video played 'jerkily' with about ~450 dropped frames. 29.97 Hz didn't work at all and nor did 60 Hz, 50 Hz performed about the same as 23-25 Hz but the interesting setting was at 59.94 Hz. The video played back even more jerky than at 23 to 25 etc but according to the mpv log it only dropped about 46 frames instead of 10x that amount at the other refresh rates.
Here is the mpv log when using 59.94 Hz @ 3840x2160:
$ mpv VID_20210512_180639.mp4
[cplayer] Waiting for scripts...
[cplayer] Set property: shared-script-properties -> 1
[cplayer] Done loading scripts.
[cplayer] Running hook: ytdl_hook/on_load
[ytdl_hook] ytdl:// hook
[ytdl_hook] not a ytdl:// url
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b
[ifo_dvdnav] Opening VID_20210512_180639.mp4
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[bdmv/bluray] Opening VID_20210512_180639.mp4
[file] Opening VID_20210512_180639.mp4
[demux] Trying demuxers for level=normal.
[lavf] Found 'mov,mp4,m4a,3gp,3g2,mj2' at score=100 size=2048.
[file] stream level seek from 131072 to 810264
[demux] Detected file format: mov,mp4,m4a,3gp,3g2,mj2 (libavformat)
[cplayer] Opening done: VID_20210512_180639.mp4
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[find_files] Loading external files in .
[cplayer] Running hook: ytdl_hook/on_preloaded
[lavf] select track 0
[lavf] select track 1
(+) Video --vid=1 (*) (h264 3840x2160 30.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
[vo/gpu/opengl] Initializing GPU context 'wayland'
[vo/gpu/wayland] Registered for protocol wl_compositor
[vo/gpu/wayland] Registered for protocol wl_shm
[vo/gpu/wayland] Registered for protocol wl_output
[vo/gpu/wayland] Registered for protocol wl_data_device_manager
[vo/gpu/wayland] Registered for protocol xdg_wm_base
[vo/gpu/wayland] Registered for protocol wl_seat
[vo/gpu/wayland] Registered for protocol wp_presentation
[vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.
[vo/gpu/wayland] Compositor doesn't support the zxdg_decoration_manager_v1 protocol!
[vo/gpu/wayland] Compositor doesn't support the zwp_idle_inhibit_manager_v1 protocol!
[vo/gpu/opengl] EGL_VERSION=1.4
[vo/gpu/opengl] EGL_VENDOR=Mesa Project
[vo/gpu/opengl] EGL_CLIENT_APIS=OpenGL OpenGL_ES
[vo/gpu/opengl] Trying to create Desktop OpenGL context.
[vo/gpu/wayland] GL_VERSION='3.1 (Core Profile) Mesa 21.1.1'
[vo/gpu/wayland] Detected desktop OpenGL 3.1.
[vo/gpu/wayland] GL_VENDOR='Panfrost'
[vo/gpu/wayland] GL_RENDERER='Mali G31 (Panfrost)'
[vo/gpu/wayland] GL_SHADING_LANGUAGE_VERSION='1.40'
[vo/gpu/wayland] Loaded extension GL_ARB_sync.
[vo/gpu/wayland] Loaded extension GL_ARB_get_program_binary.
[vo/gpu/wayland] Loaded extension GL_ARB_shader_storage_buffer_object.
[vo/gpu/wayland] Loaded extension GL_ARB_arrays_of_arrays.
[vo/gpu/wayland] Loaded extension GL_ARB_debug_output.
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] Disabling HDR peak computation (one or more of the following is not supported: compute shaders=0, SSBO=1).
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vo/gpu/wayland] Registered output GSM LG TV SSCR (0x4):
[vo/gpu/wayland] x: 0px, y: 0px
[vo/gpu/wayland] w: 3840px (1600mm), h: 2160px (900mm)
[vo/gpu/wayland] scale: 2
[vo/gpu/wayland] Hz: 59.940000
[vo/gpu] Resize: 0x0
[vd] Container reported FPS: 30.000300
[vd] Codec list:
[vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
[vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper
[vd] Opening decoder h264
[vd] Looking at hwdec h264_v4l2m2m-v4l2m2m-copy...
[vd] Trying hardware decoding via h264_v4l2m2m-v4l2m2m-copy.
[vd] Using underlying hw-decoder 'h264_v4l2m2m'
[ffmpeg/video] h264_v4l2m2m: Using device /dev/video0
[ffmpeg/video] h264_v4l2m2m: driver 'meson-vdec' on card 'Amlogic Video Decoder' in mplane mode
[ffmpeg/video] h264_v4l2m2m: requesting formats: output=H264 capture=NM12
[vd] Selected codec: h264 (H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10)
[vf] User filter list:
[vf] (empty)
[ad] Codec list:
[ad] aac - AAC (Advanced Audio Coding)
[ad] aac_fixed (aac) - AAC (Advanced Audio Coding)
[ad] Opening decoder aac
[ad] Requesting 1 threads for decoding.
[ad] Selected codec: aac (AAC (Advanced Audio Coding))
[af] User filter list:
[af] (empty)
[cplayer] Starting playback...
[af] [in] 48000Hz stereo 2ch floatp
[af] [userspeed] 48000Hz stereo 2ch floatp
[af] [userspeed] (disabled)
[af] [convert] 48000Hz stereo 2ch floatp
[file] stream level seek from 1221442 to 834600
[file] stream level seek from 965672 to 1221442
[file] stream level seek from 1635391 to 835102
[ao] Trying audio driver 'pulse'
[file] stream level seek from 966174 to 1635391
[ao/pulse] requested format: 48000 Hz, stereo channels, floatp
[ao/pulse] Library version: 14.2.0
[ao/pulse] Proto: 34
[ao/pulse] Server proto: 4294967295
[ao/pulse] Channel layouts:
[ao/pulse] - #fl
[ao/pulse] - #fr
[ao/pulse] - #fc
[ao/pulse] - #lfe
[ao/pulse] - #bl
[ao/pulse] - #br
[ao/pulse] - #flc
[ao/pulse] - #frc
[ao/pulse] - #bc
[ao/pulse] - #sl
[ao/pulse] - #sr
[ao/pulse] - #tc
[ao/pulse] - #tfl
[ao/pulse] - #tfc
[ao/pulse] - #tfr
[ao/pulse] - #tbl
[ao/pulse] - #tbc
[ao/pulse] - #tbr
[ao/pulse] result: stereo
[ao/pulse] device buffer: 6718 samples.
[ao/pulse] using soft-buffer of 9600 samples.
AO: [pulse] 48000Hz stereo 2ch float
[cplayer] AO: Description: PulseAudio audio output
[autoconvert] inserting resampler
[swresample] format change, reinitializing resampler
[swresample] 48000Hz stereo floatp -> 48000Hz stereo float
[af] [out] 48000Hz stereo 2ch float
[cplayer] Set property: shared-script-properties -> 1
Using hardware decoding (v4l2m2m-copy).
[vd] Decoder format: 3840x2160 [0:0] nv12 auto/auto/auto/auto/auto CL=unknown
[vd] Using container aspect ratio.
[vf] [in] 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [userdeint] 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [userdeint] (disabled)
[vf] [autorotate] 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [autorotate] (disabled)
[vf] [convert] 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vf] [convert] (disabled)
[vf] [out] 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
VO: [gpu] 3840x2160 nv12
[cplayer] VO: Description: Shader-based GPU Renderer
[vo/gpu] reconfig to 3840x2160 nv12 bt.709/bt.709/bt.1886/limited/display SP=1.000000 CL=mpeg2/4/h264
[vo/gpu/wayland] Reconfiguring!
[vo/gpu] Resize: 3840x2160
[vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[vo/gpu] Video scale: 1.000000/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Texture for plane 0: 3840x2160
[vo/gpu] Texture for plane 1: 1920x1080
[vo/gpu] Testing FBO format rgba16f
[vo/gpu] Using FBO format rgba16f.
[vo/gpu] No advanced processing required. Enabling dumb mode.
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 3840x2160
[vo/gpu] Window size: 3840x2160 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 3840x2160 (1:1)
[vo/gpu] Video display: (0, 0) 3840x2160 -> (0, 0) 3840x2160
[vo/gpu] Video scale: 1.000000/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Reported display depth: 8
[cplayer] first video frame after restart shown
[osd/libass] libass API version: 0x1501000
[osd/libass] libass source: commit: 0.15.1-0-g5447214643eacef71776350e779adf4b6c07bb3b
[osd/libass] Shaper: FriBidi 1.0.10 (SIMPLE) HarfBuzz-ng 2.8.1 (COMPLEX)
[osd/libass] Setting up fonts...
[osd/libass] Using font provider fontconfig
[osd/libass] Done.
[cplayer] audio ready
[cplayer] delaying audio start 0.012188 vs. 0.000000, diff=0.012188
[cplayer] playback restart complete @ 0.000000, audio=ready, video=playing
AV: 00:00:00 / 00:00:20 (0%) A-V: 0.000
[cplayer] starting audio playback
[ao/pulse] starting AO
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu/wayland] Surface entered output GSM LG TV SSCR (0x4), scale = 2
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu] Assuming 59.940000 FPS for display sync.
AV: 00:00:00 / 00:00:20 (4%) A-V: 0.407 Dropped: 18
Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).
AV: 00:00:04 / 00:00:20 (20%) A-V: 14.384 Dropped: 33
[lavf] EOF reached.
AV: 00:00:04 / 00:00:20 (21%) A-V: 15.233 Dropped: 33
[af] filter input EOF
[af] filter output EOF
[cplayer] audio filter EOF
[cplayer] audio draining
[cplayer] audio EOF reached
AV: 00:00:04 / 00:00:20 (21%) A-V: 0.000 Dropped: 33
[ao/pulse] audio end or underrun
AV: 00:00:04 / 00:00:20 (21%) A-V: 0.000 Dropped: 33
[ao/pulse] audio end or underrun
AV: 00:00:19 / 00:00:20 (100%) A-V: 0.000 Dropped: 46
[vf] filter input EOF
[vf] filter output EOF
AV: 00:00:19 / 00:00:20 (100%) A-V: 0.000 Dropped: 46
[cplayer] EOF code: 1
[cplayer] finished playback, success (reason 0)
Exiting... (End of file)
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu/wayland] Deregistering output GSM LG TV SSCR (0x4)I am currently running Linux 5.11 but I will be attempting to build a newer kernel soon. I will report back on this after upgrading to a newer kernel.
If any mpv devs want to try and get mpv working properly on the X96 Air Q1000, you can use my dtb:
CounterPillow
commented
3 years ago @ValZapod 60/1.001 vs. 60 fps will not lead to massive framedrops or desync, it'll lead to one dropped/duplicated frame every few seconds. I don't think this is relevant to what OP is seeing, which is a lot of dropped frames.
CounterPillow
commented
3 years ago Those frames are presenatation drops.
Where are you getting this from? I haven't read the full issue because there's a lot of unrelated noise about nvidia for some reason but decoder drops are shown as VO drops. What could also be causing it is simply the GPU not able to rescale the output with the full shading pipeline, or the cpu memory to gpu memory copy (if there is one with that hwdec) being slow.
CounterPillow
commented
3 years ago The null VO can be used to check whether decoding is the bottleneck, if I recall correctly.
danboid
commented
3 years ago Something like this? (with no mpv.conf)
$ mpv --hwdec=v4l2m2m-copy --hwdec-codecs=all --vo=null VID_20210512_180639.mp4
(+) Video --vid=1 (*) (h264 3840x2160 30.000fps)
(+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz)
AO: [pulse] 48000Hz stereo 2ch float
Using hardware decoding (v4l2m2m-copy).
VO: [null] 3840x2160 nv12
AV: 00:00:07 / 00:00:20 (37%) A-V: 0.497 Dropped: 140
Audio/Video desynchronisation detected! Possible reasons include too slow
hardware, temporary CPU spikes, broken drivers, and broken files. Audio
position will not match to the video (see A-V status field).
AV: 00:00:16 / 00:00:20 (82%) A-V: 1.034 Dropped: 325
Audio device underrun detected.
AV: 00:00:19 / 00:00:20 (98%) A-V: 0.000 Dropped: 371
Exiting... (End of file)Looks like its the decoding then, so is this a kernel rather than an mpv issue?
CounterPillow
commented
3 years ago I wouldn't necessarily say kernel, it could be in ffmpeg. There is some way to test hardware decoding in ffmpeg which @Akemi tells people to try with videotoolbox issues, but I forgot the precise command. But trying that and seeing what fps you get just decoding could turn this into an ffmpeg bug report instead, who can then decide whether it's a kernel issue or not.
Of course, it's entirely possible your video decoding core simply does not support 4k H.264 and only does 4K HEVC or something. I know the hwdec on my old GTX 780 Ti drops many frames on 4k H.264 content, so try with a lower resolution file and double-check the datasheet for your SoC. (Everyone likes to claim "4K" when the display core is technically able to output a 4K video signal, but rarely do they mention in the marketing material which precise other components can do anything useful at that resolution)
danboid
commented
3 years ago I've not looked at the datasheets for my SoC but as I mentioned earlier I have been able to successfully play the test video under Android on my X96 Air with one of the included video players so thats all the proof I need that the hardware is capable of decoding this file. It seems to be playing it back at UHD res although I don't know if the video player I'm using has a stats HUD feature to verify that.
I tried mpv under Android recently but I get the impression its got a lot of catching up to do to match the regular Linux mpv. None of the videos I tried with Android mpv played properly.
I have tried to play my test video with ffplay on my X96 Air and I'm getting pretty much exactly the same results as with mpv so I've opened a bug report with ffmpeg:
danboid
commented
3 years ago My latest comment on the ffmpeg ticket:
I successfully built and installed ffmpeg git under Manjaro ARM and I can run this command without any errors:
$ ffmpeg -c:v h264_v4l2m2m -i VID_20210512_180639.mp4 -f null -As per the example given here:
https://lwn.net/Articles/767126/
How might I modify that ffmpeg command to output a picture (ie to play the video under Wayland) and if decoding is working fine under ffmpeg, why does it not work under ffplay?
danboid
commented
3 years ago Here is the datasheet for the SoC my TV box uses:
https://dn.odroid.com/S905X3/ODROID-C4/Docs/S905X3_Public_Datasheet_Hardkernel.pdf
danboid
commented
3 years ago Whilst it won't help fix this bug, I think its worth mentioning that 1920x1080 h264 videos using this same codec/transport etc play fine under Wayland with mpv with no hw acceleration (vo=gpu/ no options given) on my X96 Air. There are a few dropped frames if you are playing a 1080p h264 on a 4K/UHD desktop but that's only to be expected. If I use 1920x1080 for the desktop res then it can play Full HD/1080p h264 files full screen without dropping frames, without hw accel decoding. It definitely plays 1080p videos much better without hw acceleration than with.
danboid
commented
3 years ago I have written a wiki page for installing and running Manjaro on Amlogic TV boxes. I added a mpv / hw accelerated video section to it today:
chewitt
commented
3 years ago The incorrect assumption(s) are that the current (staging) vdec driver is good, the handling of 8-bit/10-bit output in the DRM layer is good, the firmware blobs from Amlogic are good, and support for v4l2m2m in ffmpeg is both also good and aligned with the current vdec. All of the variables have some question marks against them.
The vdec was developed by Maxime Jourdan in 2018/19 before the stateful UAPI started to mature and so v4l2m2m support in ffmpeg was also immature, but in combination H264 worked well and other codecs were being added - based on an 8-bit output pipeline that did not support Amlogic framebuffer compression used in Mali Utgard SoCs or ARM framebuffer compression (different, but similar) used in Mali Midgard and Bifrost SoCs. AFBC(s) are crucial for supporting 4K output else RAM speeds (esp. in older/cheaper devices) can't sustain the throughput the video pipeline needs.
Once the initial stateful UAPI conformance tests were published in late summer 2019, some work to adapt the vdec to the tests was done by Maxime to meet them. This work focussed on the vdec itself and the conformance test-app, so didn't result in matching changes for userspace apps like ffmpeg and gstreamer. Around this time mesa has started to support AFBC in Panfrost, and the dw-hdmi DRM bridge layer has evolved support for 10-bit output (GXBB/GXL are 10-bit internally but output 8-bit, GXM and newer are 10-bit through the full pipeline). Maxime sadly had to stop work in late 2019 for personal reasons and has never resumed. Neil Armstrong (kernel maintainer and colleague to Maxime) was able to cleanup the remaining scraps of code Maxime had lying around in test branches to finish the kernel side of conformance work, and those went upstreaam in early 2020.
Earlier this year some minor work to revive HEVC support was done and this works well (if you have the right ffmpeg source) on devices with 8-bit ouput. However 10-bit output (essential for 4K) results in hard crashes. One of Maximes original goals was to support all hardware in a single driver. We have learnt over time that HEVC/VP9 are handled quite differently in older and newer SoCs (different firmwares, different approaches to memory management, use of IOMMU, etc.) and to progress support the current vdec should be split-up to handle these differences. One example of bad is, the vdec currently needs a huge CMA reservation (896MB!) for 4K which doesn't play nice with older devices equipped with 1GB RAM.
In the wider V4L2 world there has been great progress on the stateless UAPI (v4l2-request) but stateful is some way behind, and I perceive this is due to dependencies on closed-source firmwares (less attractive to the open-source community) and other devices that use the stateful UAPI, e.g. Exynos, iMX6, often being in the late stages of their lifecycle or with a much higher overall dependency on BSP code so there is less interest or less need for a mainline solution (Exynos is quite broken, iMX6 works okay but its world exists behind NXPs NDA-wall).
The notable stateful exception is the H264 IP in the Raspberry Pi which is under current and very active development from the Pi Foundation developers. RPI4 is also unusual since the HEVC IP is stateless, so you have use of both v4l2-request and v4l2m2m in the same chip. In their ffmpeg sources v4l2m2m is now working very (very) well, but "it takes two to tango" and it works well due to an alignment of ffmpeg changes, vdec changes, and UAPI tweaks. At some point there will be a serious attempt to upstream everything, but for now we're still at the "make it all work" stage. "We" is the Pi devs working with Kodi (a fancy wrapper on ffmpeg) and LibreELEC (which I contribute to).
Up to a specific git-commit point, the improvements Pi devs made in ffmpeg also benefitted the Amlogic vdec and H264 playback is generally great, and with some of the nip/tuck work done on HEVC this now plays (but not seeks) reliably on the 8-bit output devices. However, once Pi devs started to tweak the Pi vdec in combination with ffmpeg we started to see a large regression. From this point the Amlogic vdec needs matching changes .. and that leads into the redesign work previously mentioned.
Why put all this in a long reply? .. because I've been looking for developer talent to work on the vdec since 2019 without much success. The gene-pool of people who can write kernel vdec code is small. The gene-pool of people who also understand ffmpeg/gstreamer etc. is smaller again. The main names on the list are all professional developeers who rightly expect to be paid for their work. It's not impossible for "community" developers to take on the task, but it's not a small task and thus needs a small group with a personal interest; else the commitment is too large. If anyone is interested .. RSVP!
danboid
commented
3 years ago Thanks for giving all that gory technical detai @chewitt! I found it interesting but I don't have the necessary coding skills to make a real dent in any of that unfortinately. I'm going to repost that it a few places to see if it helps drum up any interest.
Thanks
cyph84
commented
2 years ago @danboid Have you had any success so far? I am trying to get 1080p h264 videos playing in Armbian on the Le Potato and have been running into another set of interesting issues (video plays but does not end). I am wondering if this is related
danboid
commented
2 years ago No, I've not tried at this for a while.
1080p videos actually play well enough without any h/w acceleration. I have heard of people getting h/w accel decoding working with 1080p h264 videos but I'm really only interested in UHD/4K hw decoding.
chewitt
commented
2 years ago kernel: https://github.com/chewitt/linux/commits/amlogic-5.18.y ffmpeg: https://github.com/jc-kynesim/rpi-ffmpeg/commits/dev/4.4/rpi_import_1
^ that combo has working H264 @ 1080p with good seeking and HEVC/VP9 with 4K/HDR on GXL/GXM devices; seeking in HEVC isn't perfect but playback should be okay. If you run the same combo on G12 or newer hardware 8-bit HEVC will play but 10-bit will wedge the board. I haven't tested gstreamer in a while but it will probably give similar results; the codec drivers need effort to progress. I'm still trying to find people to work on them.
cyph84
commented
2 years ago Thanks @chewitt for the info. I am trying to play H264 instead of HEVC, but will try the mentioned ffmpeg and kernel to see if it will help.
cyph84
commented
2 years ago After upgrading my Armbian image to (https://redirect.armbian.com/region/EU/lepotato/Jammy_edge_xfce), apt-get update && apt-get upgrade, I am now running on kernel 5.17.5-meson64, ffmpeg 4.4.1-3ubuntu5, mpv mpv 0.34.1.
The situation looks much better. Video actually plays to the end.
However when playing 1080p videos, i get about 10 dropped frames every second. I reckon this is due to the vo/gpu not being able to keep up with the decoder. ffmpeg -c:v h264_v4l2m2m -i in.mp4 -map 0:v -f null -y /dev/null is able to decode 1080p video at 5x speed.
@chewitt would I have any luck trying to get PRIME working with meson-vdec?
chewitt
commented
2 years ago LE uses DRMPRIME with Kodi (EGL also works, as an option). I can't speak for other player apps as I don't use them.
chewitt
commented
2 years ago @cyph84 there was a bug in the ffmpeg sources; branch is updated with a fix (build HEAD)
Important Information
Provide following Information:
X96 Air Q1000 Amlogic S905X3 based TV box.
0.33.1-dirty
Manjaro ARM unstable branch, kernel 5.12.1-1-MANJARO-ARM
manjaro arm unstable repo
KDE plasma wayland, which works better than GNOME wayland for mpv. Attempting to play this video with mpv under wayland GNOME crashed mpv.
mesa 21.1.1-1
https://youtu.be/r4lWJO35o00
Reproduction steps
I am trying to play this video:
https://drive.google.com/file/d/14z1Gd8zXbJ2XWvULvmWXeqLVRcgUHo2p/view?usp=sharing
Under Manjaro ARM unstable KDE wayland (what a mouthful!)
My
mpv.conflooks like this:Expected behavior
Smooth hw accelerated fullscreen video playback using the meson vpu.
Actual behavior
Very jerky video playback, less than 1 fps with 100's of dropped frames. I have tried experimenting with the plasma compositor settings but they don't seem to make any notable difference to mpv.
Log file
Sample files
https://drive.google.com/file/d/14z1Gd8zXbJ2XWvULvmWXeqLVRcgUHo2p/view?usp=sharing