Ursache für teilweise ruckelnde Videos

[rola621]

Hallo!

Habe mir vor einiger Zeit einen Rechner aufgebaut, den ich in erster Linie als möglichst leisen Desktop-PC nutzen wollte. Leise ist er nach wie vor, und das soll auch so bleiben, weil ich das als einen der wichtigsten Aspekte für konzentriertes Arbeiten empfinde.

Es sind folgende Komponenten verbaut:
Mainboard: GIGABYTE B560M DS3H V2
CPU: 11th Gen Intel i7-11700 (16) @ 4.800GHz
CPU-Lüfter: Alpenföhn Brocken
iGPU: Intel RocketLake-S GT1 [UHD Graphics 750]
RAM: 2x16GB Crucial Ballistix (BL16G32C16U4W)
Speicher: Samsung SSD 970 EVO Plus (NVMe) 1TB + 2TB
Netzteil: bequiet STRAIGHT POWER 11 Platinum (550W)


Bin soweit absolut zufrieden, auch wenn es immer mal wieder zu Freezes gekommen ist, wobei die iGPU bzw. deren Treiber als Ursache noch nicht vollständig geklärt ist.
Aktueller Stand ist jedenfalls: alles stabil und zufrieden.

Das einzige, wo ich Verbesserungspotential sehe bzw. was ich etwas schade finde:
Beim Abspielen von Videos in 1080p aufwärts ruckelt es immer ziemlich (insbesondere im Vollbild, wenn ich es kleiner mache geht es wieder einigermaßen), was mich zwar nicht stört da ich nahezu keine Videos schaue, ich mich aber an der Stelle dann doch immer mal wieder frage, woran das ursächlich eigentlich liegt?
Ist hier die iGPU schon an der Grenze, oder kann sie einfach nicht ihr volles Potential entfalten, weil sie softwaremäßig runtergeregelt wird?
Kenne mich mit Grafikkarten etc. leider absolut nicht aus, würde mich allerdings freuen wenn Ihr mir sagen könnt, wo ich da kucken könnte, um dem etwas auf den Grund zu gehen. Vielleicht ist es ja nur eine kleine Einstellung, die mir ruckelfreie Videos ermöglicht?

Hardwaretechnische Anpassungen im Sinne einer dedizierten Grafikkarte o.ä. wollte ich eigentlich vermeiden, weil durch meinen relativ überdimensionierten CPU-Lüfter unter Umständen der Platz nur begrenzt ist und mir momentan auch die finanziellen Mittel fehlen.



Daher einfach mal in die Runde gefragt: Könnte man da auch ohne hardwaretechnischer Änderung etwas optimieren? Was muss mich mir hierfür ansehen?

vielleicht mal als Anfang:

Code: Alles auswählen

inxi -G
Graphics:
  Device-1: Intel RocketLake-S GT1 [UHD Graphics 750] driver: i915 v: kernel
  Device-2: AIRHUG 02 type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: intel dri: iris
    gpu: i915 resolution: 1: 1920x1080~60Hz 2: 1920x1080~60Hz
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel Graphics (RKL GT1)

Viele Grüße und ein schönes Wochenende!

[thunder11]

Ich habe im Vergleich zu dir ein "Methusalem" eingebaut, kann aber deine Erfahrungen nicht nachvollziehen.
Hier mal die Ausgabe (Testing)

Code: Alles auswählen

~$ inxi -G
Graphics:
  Device-1: Intel CoffeeLake-S GT2 [UHD Graphics 630] driver: i915 v: kernel
  Display: x11 server: X.Org v: 21.1.11 driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 3840x2160~60Hz
  API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 23.3.5-1
    renderer: Mesa Intel UHD Graphics 630 (CFL GT2)

Meine Vermutung ist, das da wahrscheinlich einige "Zutaten" fehlen könnten.
Deshalb mal hier die Ausgabe von einigen aus meiner Sicht relevanten Pakten:
Habe nicht weiter gefiltert, abe ein Vergleich dürfte trotzdem möglich sein:

Code: Alles auswählen

~$ dpkg -l *firmware*|grep ii
ii  bluez-firmware         1.2-9                        all          Firmware for Bluetooth devices
ii  firmware-amd-graphics  20230625-2                   all          Binary firmware for AMD/ATI graphics chips
ii  firmware-ath9k-htc     1.4.0-108-gd856466+dfsg1-1.4 all          firmware for AR7010 and AR9271 USB wireless adapters
ii  firmware-intel-sound   20230625-2                   all          Binary firmware for Intel sound DSPs
ii  firmware-iwlwifi       20230625-2                   all          Binary firmware for Intel Wireless cards
ii  firmware-linux         20230625-2                   all          Binary firmware for various drivers in the Linux kernel (metapackage)
ii  firmware-linux-free    20200122-2                   all          Binary firmware for various drivers in the Linux kernel
ii  firmware-linux-nonfree 20230625-2                   all          Binary firmware for various drivers in the Linux kernel (metapackage)
ii  firmware-misc-nonfree  20230625-2                   all          Binary firmware for various drivers in the Linux kernel

Code: Alles auswählen

~$ dpkg -l *intel*|grep ii
intel-sound           20230625-2      all          Binary firmware for Intel sound DSPs
ii  intel-media-va-driver:amd64    24.1.0+dfsg1-1  amd64        VAAPI driver for the Intel GEN8+ Graphics family
ii  intel-microcode                3.20231114.1    amd64        Processor microcode firmware for Intel CPUs
ii  intel-opencl-icd               23.35.27191.9-1 amd64        Intel graphics compute runtime for OpenCL
ii  libdrm-intel1:amd64            2.4.120-2       amd64        Userspace interface to intel-specific kernel DRM services -- runtime

Code: Alles auswählen

~$ dpkg -l *mesa*|grep ii
ii  libegl-mesa0:amd64        23.3.5-1     amd64        free implementation of the EGL API -- Mesa vendor library
ii  libegl1-mesa-dev:amd64    23.3.5-1     amd64        free implementation of the EGL API -- development files
ii  libgl1-mesa-dri:amd64     23.3.5-1     amd64        free implementation of the OpenGL API -- DRI modules
ii  libglapi-mesa:amd64       23.3.5-1     amd64        free implementation of the GL API -- shared library
ii  libglu1-mesa:amd64        9.0.2-1.1    amd64        Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-dev:amd64    9.0.2-1.1    amd64        Mesa OpenGL utility library -- development files
ii  libglx-mesa0:amd64        23.3.5-1     amd64        free implementation of the OpenGL API -- GLX vendor library
ii  mesa-common-dev:amd64     23.3.5-1     amd64        Developer documentation for Mesa
ii  mesa-utils                9.0.0-2      amd64        Miscellaneous Mesa utilities -- symlinks
ii  mesa-utils-bin:amd64      9.0.0-2      amd64        Miscellaneous Mesa utilities -- native applications
ii  mesa-va-drivers:amd64     23.3.5-1     amd64        Mesa VA-API video acceleration drivers
ii  mesa-vdpau-drivers:amd64  23.3.5-1     amd64        Mesa VDPAU video acceleration drivers
ii  mesa-vulkan-drivers:amd64 23.3.5-1     amd64        Mesa Vulkan graphics drivers

Code: Alles auswählen

~$ dpkg -l *265*|grep ii
ii  libde265-0:amd64              1.0.15-1     amd64        Open H.265 video codec implementation
ii  libheif-plugin-libde265:amd64 1.17.6-1     amd64        ISO/IEC 23008-12:2017 HEIF file format decoder - libde265 plugin
ii  libheif-plugin-x265:amd64     1.17.6-1     amd64        ISO/IEC 23008-12:2017 HEIF file format decoder - x265 plugin
ii  libx265-199:amd64             1:3.5-dmo2   amd64        x265 video coding library
ii  x265                          1:3.5-dmo2   amd64        video encoder for the H.265/HEV standard

Code: Alles auswählen

~$ dpkg -l *egl*|grep ii
ii  libegl-dev:amd64                               1.7.0-1       amd64        Vendor neutral GL dispatch library -- EGL development files
ii  libegl-mesa0:amd64                             23.3.5-1      amd64        free implementation of the EGL API -- Mesa vendor library
ii  libegl1:amd64                                  1.7.0-1       amd64        Vendor neutral GL dispatch library -- EGL support
ii  libegl1-mesa-dev:amd64                         23.3.5-1      amd64        free implementation of the EGL API -- development files
ii  libgegl-0.4-0:amd64                            1:0.4.46-4+b1 amd64        Generic Graphics Library
ii  libgegl-common                                 1:0.4.46-4    all          Generic Graphics Library - common files
ii  libqt6waylandeglclienthwintegration6:amd64     6.4.2-5       amd64        Qt 6 Wayland WaylandEglClientHwIntegration library
ii  libqt6waylandeglcompositorhwintegration6:amd64 6.4.2-5       amd64        Qt 6 Wayland WaylandEglCompositorHwIntegration library
ii  libwayland-egl1:amd64                          1.22.0-2.1+b1 amd64        wayland compositor infrastructure - EGL library

[niemand]

Die Frage ist auch ein bisschen, welcher Player denn verwendet wird. Wenn man das weiß, kann man schauen, ob der vielleicht aus irgendeinem Grund nur in Software rendert, die GPU-Funktionalität also gar nicht nutzt.

[rola621]

Player wird der mpv-Player verwendet. WIe kann ich den "auf den Prüfstand" stellen? Vom Terminal aus starten und dann besagtes Video abspielen und die Ausgabe posten?

@thunder11:
Habe die ganzen Ausgaben mal in einem Block zusammengefasst:

Code: Alles auswählen

desktop@desktop:~$ dpkg -l *egl*|grep ii
ii  libegl-dev:amd64      1.6.0-1          amd64        Vendor neutral GL dispatch library -- EGL development files
ii  libegl-mesa0:amd64    22.3.6-1+deb12u1 amd64        free implementation of the EGL API -- Mesa vendor library
ii  libegl1:amd64         1.6.0-1          amd64        Vendor neutral GL dispatch library -- EGL support
ii  libgegl-0.4-0:amd64   1:0.4.42-2       amd64        Generic Graphics Library
ii  libgegl-common        1:0.4.42-2       all          Generic Graphics Library - common files
ii  libwayland-egl1:amd64 1.21.0-1         amd64        wayland compositor infrastructure - EGL library
ii  libwayland-egl1:i386  1.21.0-1         i386         wayland compositor infrastructure - EGL library
desktop@desktop:~$ dpkg -l *265*|grep ii
ii  libde265-0:amd64  1.0.11-1+deb12u2 amd64        Open H.265 video codec implementation
ii  libde265-0:i386   1.0.11-1+deb12u2 i386         Open H.265 video codec implementation
ii  libx265-199:amd64 3.5-2+b1         amd64        H.265/HEVC video stream encoder (shared library)
ii  libx265-199:i386  3.5-2+b1         i386         H.265/HEVC video stream encoder (shared library)
desktop@desktop:~$ dpkg -l *mesa*|grep ii
ii  libegl-mesa0:amd64        22.3.6-1+deb12u1 amd64        free implementation of the EGL API -- Mesa vendor library
ii  libgl1-mesa-dev:amd64     22.3.6-1+deb12u1 amd64        transitional dummy package
ii  libgl1-mesa-dri:amd64     22.3.6-1+deb12u1 amd64        free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri:i386      22.3.6-1+deb12u1 i386         free implementation of the OpenGL API -- DRI modules
ii  libglapi-mesa:amd64       22.3.6-1+deb12u1 amd64        free implementation of the GL API -- shared library
ii  libglapi-mesa:i386        22.3.6-1+deb12u1 i386         free implementation of the GL API -- shared library
ii  libglu1-mesa:amd64        9.0.2-1.1        amd64        Mesa OpenGL utility library (GLU)
ii  libglu1-mesa-dev:amd64    9.0.2-1.1        amd64        Mesa OpenGL utility library -- development files
ii  libglx-mesa0:amd64        22.3.6-1+deb12u1 amd64        free implementation of the OpenGL API -- GLX vendor library
ii  libglx-mesa0:i386         22.3.6-1+deb12u1 i386         free implementation of the OpenGL API -- GLX vendor library
ii  libosmesa6:amd64          22.3.6-1+deb12u1 amd64        Mesa Off-screen rendering extension
ii  libosmesa6:i386           22.3.6-1+deb12u1 i386         Mesa Off-screen rendering extension
ii  mesa-utils                8.5.0-1          amd64        Miscellaneous Mesa utilities -- symlinks
ii  mesa-utils-bin:amd64      8.5.0-1          amd64        Miscellaneous Mesa utilities -- native applications
ii  mesa-va-drivers:amd64     22.3.6-1+deb12u1 amd64        Mesa VA-API video acceleration drivers
ii  mesa-va-drivers:i386      22.3.6-1+deb12u1 i386         Mesa VA-API video acceleration drivers
ii  mesa-vdpau-drivers:amd64  22.3.6-1+deb12u1 amd64        Mesa VDPAU video acceleration drivers
ii  mesa-vdpau-drivers:i386   22.3.6-1+deb12u1 i386         Mesa VDPAU video acceleration drivers
ii  mesa-vulkan-drivers:amd64 22.3.6-1+deb12u1 amd64        Mesa Vulkan graphics drivers
ii  mesa-vulkan-drivers:i386  22.3.6-1+deb12u1 i386         Mesa Vulkan graphics drivers
desktop@desktop:~$ dpkg -l *intel*|grep ii
ii  intel-media-va-driver:amd64    23.1.1+dfsg1-1           amd64        VAAPI driver for the Intel GEN8+ Graphics family
ii  intel-media-va-driver:i386     23.1.1+dfsg1-1           i386         VAAPI driver for the Intel GEN8+ Graphics family
ii  intel-microcode                3.20231114.1~deb12u1     amd64        Processor microcode firmware for Intel CPUs
ii  libdrm-intel1:amd64            2.4.114-1+b1             amd64        Userspace interface to intel-specific kernel DRM services -- runtime
ii  libdrm-intel1:i386             2.4.114-1+b1             i386         Userspace interface to intel-specific kernel DRM services -- runtime
ii  xserver-xorg-video-intel       2:2.99.917+git20210115-1 amd64        X.Org X server -- Intel i8xx, i9xx display driver
desktop@desktop:~$ dpkg -l *firmware*|grep ii
ii  firmware-linux-free    20200122-1   all          Binary firmware for various drivers in the Linux kernel
ii  firmware-misc-nonfree  20230210-5   all          Binary firmware for various drivers in the Linux kernel
ii  firmware-realtek       20230210-5   all          Binary firmware for Realtek wired/wifi/BT adapters
ii  firmware-sof-signed    2.2.4-1      all          Intel SOF firmware - signed

Danke vielmals für Eure Beteiligung!

[thunder11]

Ich habe dazu immer ein paar Test-Videos parat.
Gibt es hier:https://www.larmoire.info/jellyfish/


Ich hab gerade mal eins unterschiedlich laufen lassen.
Im Terminal kannst du beobachten, wie viel Frames "gedropped" werden, was dann als Ruckeln erscheint.
Das --keep-open=yes ist sinnvoll, da diese Ausgabe sonst nach Beenden des Videos verschwindet.
Normal:

Code: Alles auswählen

mpv --keep-open=yes ~/Videos/Test_Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
VO: [gpu] 3840x2160 yuv420p10
(Paused) V: 00:00:29 / 00:00:30 (100%) Dropped: 30

mit HEVC - Profil:

Code: Alles auswählen

 mpv --profile=HEVC ~/Videos/Test_Videos/jellyfish-120-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
Using hardware decoding (vaapi).
VO: [gpu] 3840x2160 vaapi[p010]
(Paused) V: 00:00:29 / 00:00:30 (100%)

So ein Profil kannst du anlegen: Ohne Profil wird bei mir Software-Kodiert, mit macht es die GPU
CPU-Temp 65′C / 30°C

~/.config/mpv/mpv.conf

Sieht bei mir so aus:

Code: Alles auswählen

[HEVC]  
#autofit-larger=80%x80%
keep-open=yes
hwdec=vaapi
# Der Cache-Speicher ist auf "auto" gesetzt, damit er für Netzwerk-Streams geeignet ist
# (automatische Aktivierung bei Bedarf); die Größe wird durch die Option "cache-default" festgelegt:
cache=auto
# Die Größe des bei Bedarf aktivierten Caches in kByte:
# cache-default=300000
# fs=yes
# --window-scale=0.70
# --autofit-larger=50%x50%

Brauchen tust du nur die auskommentierten. Die anderen zum Spielen ---> man mpv

[wanne]

Der i7-11700 sollte 1080p auch locker in software decodieren können. Selbst wenn sie im unsäglich rechenaufwändigen HVEC in HDR bei riesigen Bitragen der Fall ist encodiert sind sie das bei einigen der jellyfish-videos der Fall ist.
In sofern würde ich mal stark auf ein anderes eher unübliches bottleneck tippen.
Was ist denn das für eine Platte? Wie ist der Bildschirm angeschlossen? Wie
Kannst die Ausgabe von dem da posten:
Am liebsten mit einem Video, dass du hast und bekannter maßen ruckelt. (Falls es nicht zu groß ist, dass das ewig braucht.)
https://www.larmoire.info/jellyfish/med ... d-h264.mkv
https://balja.org/pub/1080p.mkv
Zerst als root

Code: Alles auswählen

echo 3 > /proc/sys/vm/drop_caches

Dann als normaler user

Code: Alles auswählen

time cat 1080p.mkv > /dev/null
time ffmpeg -hide_banner -i 1080p.mkv  -f null -
time mpv --keep-open=yes 

Ruckelt das noch? Bzw. was funktioniert da?

Code: Alles auswählen

mpv --profile=sw-fast --vo=wlshm 1080p.mkv
mpv --profile=sw-fast --vo=x11 1080p.mkv
mpv --hwdec=no 1080p.mkv

[rola621]

Danke!!!
Habe das jetzt auch mal durchlaufen lassen ohne ein Profil anzulegen:

Code: Alles auswählen

mpv --keep-open=yes /home/desktop/Downloads/jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
VO: [gpu] 3840x2160 yuv420p10
(Paused) V: 00:00:29 / 00:00:30 (100%) Dropped: 3

Exiting... (Quit)

Das mit dem Profil habe ich nicht ganz verstanden. Was sollte konkret in der conf-Datei enthalten sein, und was sollte auskommentiert sein??

@wanne:
Es hat alles soweit funktioniert, habe das alles so gemacht, außer das vorvorletzte Kommando hat mir eine Fehlermeldung gebracht:

42118


Die letzten beiden Kommandos haben ruckelfrei die verlinkten Videos abgespielt.
Wie kann ich das Video, welches ruckelt, in mpv testen, und euch die Ausgabe mitteilen?

[wanne]

Also dein Rechner kann mein 10s Video in 0,023s lesen und 0,392s decodieren. Festplatte und CPU fallen damit als bottleneck eher flach. Auch wenn die Festplatte eher gemächlich arbeitet reicht sie locker. Deiner CPU kann das nicht mal einen Kern ernsthaft belasten. (Mein Video scheint aber weniger anspruchsvoll zu sein als deines.)
Selbst das völlig bescheuert encodierte jellyfish video scheint sie problemlos zu schlucken.
Nachdem meine Videos abspielen dürfte es auch kein Problem mit der Bildschirmanbindung sein. – Wäre trotzdem interessant, was das ist. (USB-Docking-Station?)

Wie kann ich das Video, welches ruckelt, in mpv testen, und euch die Ausgabe mitteilen?

Na einfach den Dateinamen ersetzen. Eventuell mit --keep-open=yes, damit die Ausgabe nach Ende des videos noch zu sehen ist. Ich nehme aber an, dass dein Video lange genug ist, dass du einfach anhalten kannst und mitten im Video kopieren kannst.
Interessant, wäre vor allem mal:

Code: Alles auswählen

ffmpeg -hide_banner -t 60 -i [DEIN VIDEO].mkv  -f null -

Das mit dem Profil habe ich nicht ganz verstanden. Was sollte konkret in der conf-Datei enthalten sein, und was sollte auskommentiert sein??

Er wollte eine bestimmte Methode der Hardwarebeschleunigung (für alle h.265 Videos) erzwingen. Das äquivalent wären die Optionen mpv --hwdec=vaapi. Da deine CPU eh flott genug ist, würde ich mich nicht mit Hardwaredecodern, die mpv nicht als sinnvoll ansieht rum schlagen.

das vorvorletzte Kommando hat mir eine Fehlermeldung gebracht

Das klingt nach einem Window-Manager, der nicht ganz auf der Höhe der Zeit ist. Während Wayland was Videolatenzen angeht wirklich merkliche Performancevorteile bringt, halte ich es in deinem Fall eher irrelevant. Trotzdem wäre interessant, um was es sich handelt.

[MaGe]

Da deine CPU eh flott genug ist, würde ich mich nicht mit Hardwaredecodern, die mpv nicht als sinnvoll ansieht rum schlagen.

Vielleicht ist das nur bei mir so.

jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv

mit Hardwaredecoder 8 kerne cpu auslastung 7-11 %
ohne Hardwaredecoder 8 kerne cpu auslastung 97 %



gruss MaGe

[thunder11]

Vielleicht ist das nur bei mir so.

Das ist bei mir genauso: Aber wanne mag ja dampfende CPU's gerne

Code: Alles auswählen

mpv --profile=HEVC /home/thunder/Videos/Test_Videos/jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv 
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
Using hardware decoding (vaapi).
VO: [gpu] 3840x2160 vaapi[p010]
(Paused) V: 00:00:29 / 00:00:30 (100%) Dropped: 8

Code: Alles auswählen

mpv --keep-open=yes /home/thunder/Videos/Test_Videos/jellyfish-400-mbps-4k-uhd-hevc-10bit.mkv 
 (+) Video --vid=1 (*) (hevc 3840x2160 29.970fps)
VO: [gpu] 3840x2160 yuv420p10
(Paused) V: 00:00:29 / 00:00:30 (100%) Dropped: 149

[wanne]

Das ist bei mir genauso: Aber wanne mag ja dampfende CPU's gerne

Nein. Ich mag vernünftig encodete Videos gerne. Hätte man nicht das grundlos bescheuert encodierte jellyfish-Video genommen, hätte man auch kein Problem mit einer kochenden CPU.
* 29.970fps sorgt auf nem 60Hz Bildschirm für maximales Ruckeln. – Die Qualität ist also sogar eher bescheiden. Trotzdem:
* Bei 10 Bit Farbtiefe auf einem 6Bit Bildschirm sind die Hälfte der Bits unnötig. Sorgen aber für maximalen Rechenaufwand, weil die streaming extensions auf ner x86-CPU nicht sinnvoll genutzt werden können.
* HVEC braucht zum decodieren auf einer 8 Core CPU etwa die 20fache Rechenleistung wie VP9 während die Bildqualität bei gleicher Bitrate jenseits der 20MBit/s sogar eher besser ist.
* Auch wenn hier alle am Ende das Gegenteil behaupten werden. Ich gehe jede Wette ein: In einem Blindtest ist keiner in der Lage x265 veryslow CRF encode mit im Schnitt 20MBit/s von einem 400MBit/s zu unterscheiden. Selbst bei BRs, die dafür bekannt sind ihre Daten unnötig aufzublasen um das kopieren zu erschweren dürfen 36Mbit/s nicht überschreiten. Das Video ist einzig und alleine aufgeblasen um künstlich die CPU zum schwitzen zu bringen. Nett als Benchmark aber für die Realität total irrelevant. Keiner encodiert Videos mit 400MBit/s.

[hikaru]

Die jellyfish-Videos sind als Benchmark konzipiert. Die sind absichtlich so "bescheuert" encodiert.

mpv decodiert standardmäßig in Software, weil das tendenziell unproblematischer ist (Rechenleistung vorausgesetzt). Um in Hardware zu decodieren muss man ihm einen hwdec-Parameter mitgeben. --hwdec=vaapi sollte hier passen, im Zweifel sollte --hwdec=auto die richtige Wahl automatisch treffen.
Ruft man mpv mit -v auf, dann gibt es über den verwendeten Decoder Auskunft.

Aber wie schon angeklungen, sollte die CPU 1080p in jedem Codec (außer vielleicht av1) auch in Software schaffen. Ich vermute, das beobachtete Ruckeln rührt eher von Mikrorucklern, weil Bildschirm-Wiederholrate und Video-Framerate nicht zueinander passen. Um das zu eruieren müsste man beide Werte kennen, was hier im Thread bisher nicht der Fall ist.

[rola621]

Danke vielmals für Eure rege Beteiligung!

Mittlerweile glaube ich auch, dass es an der komischen Codierung des Videos liegt, da ich mich aber damit nicht auskenne versuche ich jetzt mal anhand eurer Beiträge, sinnvolle Informationen zu liefern.

Also es sind zwei Videos, bei denen es sich um "Restaurierungen" im Sinne von "upscale" von älterem Bildmaterial handelt.
Die Videoqualität ist subjektiv gut, aber ruckelt eben ziemlich. Bei vergleichbaren Videos dieser "upscale" Sorte tritt das ruckeln nicht auf. Muss also scheinbar wirklich an irgendeinem schlechten Codec oder Verhältnis von Framerate zu was auch immer liegen?

Habe mir jetzt mal von den beiden Videos via mediainfo ein paar Daten anzeigen lassen, vllt könnt ihr damit was anfangen? siehe hier: 42123

Außerdem habe ich den empfohlenen Befehl von @wanne mal bei beiden getestet: 42124

Je weiter wir hier mit dem Thread voranschreiten, desto mehr habe ich das Gefühl, dass einfach die Videos komisch encodiert sind.

Als ich jetzt aber gerade noch den Tip von hikaru ausprobiert habe und die beiden Problemvideos mit dem hwdec=auto Parameter gestartet habe, war das ruckeln zunächst noch vorhanden, als ich allerdings das Fenster auf Vollbild geschalten habe, war es plötzlich flüssiger denn je, und die CPU scheint auch keine Höchstleistungen vollbracht zu haben.

Damit steht für mich jetzt eigentlich fest, dass ich sowohl mit dem SMPlayer als auch mit dem mpv nur noch mit Hardware dekodieren möchte... Denn sonst wäre die gute Intel iGPU ja auch irgendwo eine sinnlose Investition gewesen, wenn sie garnicht zum Zuge kommt, oder?
Und wie man jetzt sieht (an den Daten weiß ichs nicht aber subjektiv ist es jetzt definitiv flüssiger als flüssig, kein ruckeln mehr mit hwdec=auto) steckt sie das auch gut weg.

Frage mich jetzt nur, ob es vielleicht noch eine Art "globale Einstellung" gibt, die dafür sorgt, dass alle Grafikaufgaben ab einem gewissen Anspruchslevel direkt von der Hardware übernommen werden? Oder wäre das sogar eher kontraproduktiv?
Falls nein, wie lässt sich das ggf realisieren?


Ich hätte jetzt treudoof einfach in die "~/.config/mpv/mpv.conf" folgendes eingefügt:

Code: Alles auswählen

hwdec=auto

oder eben direkt

Code: Alles auswählen

hwdec=vaapi

Also entweder, oder....


Im Arch-Linux findet sich aber folgende Passage zu mpv:

If you want to use hardware decoding, you must use a copy-back decoder since normal decoders are not compatible with Vapoursynth (choose a hwdec option that ends in -copy). For instance:

hwdec=auto-copy
hwdec-codecs=all

Either way, hardware decoding is discouraged by mpv developers and is not likely to make a significant difference in performance.

Was meint ihr dazu? Würde halt gerne jedes Video, unabhängig von seiner Encodierung einfach nur öffnen können, sodass es dann auch möglichst effizient und ruckelfrei läuft
Freue mich über jeden Verbesserungsvorschlag bzw. Optimierungsanregungen dahingehend..

Danke auch für die Geduld, hatte/habe privat einiges um die Ohren momentan..

[niemand]

Ich hätte jetzt treudoof einfach in die "~/.config/mpv/mpv.conf" folgendes eingefügt:
[…]

Was meint ihr dazu?

Ich meine: früher™ hätten wir das einfach ausprobiert und geschaut, ob es tut, oder nicht. Du müsstest dafür nicht einmal die Config bearbeiten, die Dinge lassen sich auch direkt beim Aufruf mitgeben.

[rola621]

Du hast ja sowas von recht.... sorry!
Habs getestet, funktioniert mit hwdec=vaapi in der conf Datei ebenso wie mit hwdec=auto ....
Allerdings fällt mir auf, dass es erst zum ruckelfreien Abspielen übergeht, sobald ich entweder
- den bereits laufenden mpv mit ruckelndem Video an den oberen Bildschirmrand ziehe und damit das Fenster maximiere (sobald es dann quasi Vollbild ist ruckelt nixmehr)
oder
- komplett in den Vollbildmodus wechsle via Doppelklick

Die Ausgabe im Terminal bleibt durch dieses Verhalten unberührt:

Code: Alles auswählen

mpv ~/Downloads/video2004.mp4
 (+) Video --vid=1 (*) (h264 1440x1080 60.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1440x1080 vaapi[nv12]
AV: 00:00:39 / 00:25:10 (3%) A-V:  0.000 Dropped: 2
Exiting... (Quit)

könnt ihr euch dieses Verhalten irgendwie erklären?
Ist schon merkwürdig finde ich, denn eigentlich sollte es ja im Vollbild eher ruckeln weil mehr dargestellt werden muss, als im kleinen Fenster.. ist aber genau umgekehrt.

Ist jetzt an sich kein Problem das ich super schlimm finde, interessieren würde es mich dennoch wo das herkommen kann, denn irgendwas scheint da noch nicht ganz rund zu laufen..

[debianoli]

Wenn das Fenster kleiner ist, muss umgerechnet werden. Wenn maximiert ist, muss nichts umgerechnet werden, da dies der normalen Auflösung Video entspricht. Wäre meine Vermutung

[rola621]

okay, also völlig normal und nichts woran man noch was ändern kann, außer mit ner leistungsfähigeren, dedizierten GPU, oder?

[wanne]

Also das Video
* Nutzt den weitest verbreiteten Codec überhaupt h.264. Der entsprechend wenig ärger machen.
* Hat 60Hz, was die Wiederholrate der meisten Bildschirme ist. – Unter anderem die von deinem... Sollte also auf keinen Fall zu Problemen führen.
* Dein Rechner kann diese Videos selbst auf der CPU ~45 mal schneller dekomprimieren als sie laufen.

okay, also völlig normal und nichts woran man noch was ändern kann, außer mit ner leistungsfähigeren, dedizierten GPU, oder?

Nein. Ganz im Gegenteil. Wenn du nicht im Vollbild bist, wird das Bild meist zuerst auf die CPU und dann zurück in die GPU kopiert. Das dauert deutlich länger als das skalieren selbst. Früher (also bei AGP/PCI also vor PCIe) war das oft der limitierende Faktor, weshalb es abseits von Vollbild ruckelte. Rate mal, wo das nicht benötigt wird: Wenn deine iGPU das Bild sowieso schon im RAM hat und die MMU das nur ummappen muss. Skalieren sollte noch viel weniger ein problem für die CPU sein, wie decodieren. Da um nochmal Größenordnungen harmloser. Deswegen nochmal die Frage nach dem Window-Manager (Und ob du eventuell mal einen anderen probieren kannst. sway ist nicht mal ein MiB groß und deswegen ganz nett zum Testen. (Aber auch etwas komplizierter zu bedienen. Windows-Enter startet ein terminal. Windows+E schließt ihn!) und wie der Bildschirm angeschlossen ist.

Denn sonst wäre die gute Intel iGPU ja auch irgendwo eine sinnlose Investition gewesen, wenn sie garnicht zum Zuge kommt, oder?

Wie gesagt: CPUs sind heute Schnell genug um decodieren zu können. Und die meisten Viedoplayer haben halt weit besser gewarteten Code als die GPUs sodass es mit letzterem viel öfter irgend welche komischen Probleme gibt. Deswegen ziehe ich vor auf der CPU zu decodieren und nur bei 3D-Sachen auf die GPU zurück zu greifen. Der mpv sieht es gleich. Der Chrome zumindest bei Nvidia-GPUs. – Intel ist da ja glücklicherweise eher vorbildlich.

[rola621]

Danke für die ausführliche Antwort!
Windowmanager nutze ich Xfwm4

Bin was Windowmanager etwas unbedarft und übervorsichtig (Neuland für mich, da etwas zu verändern), daher werde ich mir das mit Sway zum Testen mal in Ruhe ansehen und hier nochmal Feedback geben, ob sich unter sway was am Wiedergabeverhalten Vollbild bzw. kleineres Fenster verändert.

Bzgl der CPU vs. iGPU Thematik:
Habe gerade nochmal testweise den Inhalt des config-files gelöscht, um wieder auf Software-Decodierung zu switchen...

liefert dann folgendes:

Code: Alles auswählen

mpv ~/Downloads/video2004.mp4
 (+) Video --vid=1 (*) (h264 1440x1080 60.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1440x1080 yuv420p
AV: 00:00:35 / 00:25:10 (2%) A-V:  0.000 Dropped: 1081

und verhält sich erstaunlicherweise exakt genauso wie mit hwdec=vaapi, also der iGPU Decodierung.
Entweder es ist mir vorher nicht aufgefallen, dass es im Vollbild nicht ruckelt, oder ... ich weiß nicht.
Rein subjektiv betrachtet, ruckelt es ohne hwdec=vaapi etwas stärker im kleineren Fenster, kann mich aber auch täuschen.

Also einziger Ausweg einen anderen Windowmanager testen, oder?

[MaGe]

Rein subjektiv betrachtet, ruckelt es ohne hwdec=vaapi etwas stärker [...]

## Mit hardware decoding

mpv ~/Downloads/video2004.mp4
[...]
VO: [gpu] 1440x1080 vaapi[nv12]
AV: 00:00:39 / 00:25:10 (3%) A-V: 0.000 Dropped: 2 [...]


## Ohne hardware decoding
mpv ~/Downloads/video2004.mp4
[...]
VO: [gpu] 1440x1080 yuv420p
AV: 00:00:35 / 00:25:10 (2%) A-V: 0.000 Dropped: 1081 [...]

Der dropped aber gewaltig.



gruss MaGe

[niemand]

Windowmanager nutze ich Xfwm4
[…]
Also einziger Ausweg einen anderen Windowmanager testen, oder?

Deutet auf Xfce4 hin. Da ist per Default der Compositor aktiv und der hat zumindest bei mir in der Vergangenheit auch schon mal Probleme bereitet. Einen Versuch wär’s wert, den testweise mal abzuschalten (Einstellungen → Feineinstellungen der Fensterverwaltung → Komposit)

[rola621]

## Mit hardware decoding

mpv ~/Downloads/video2004.mp4
[...]
VO: [gpu] 1440x1080 vaapi[nv12]
AV: 00:00:39 / 00:25:10 (3%) A-V: 0.000 Dropped: 2 [...]


## Ohne hardware decoding
mpv ~/Downloads/video2004.mp4
[...]
VO: [gpu] 1440x1080 yuv420p
AV: 00:00:35 / 00:25:10 (2%) A-V: 0.000 Dropped: 1081 [...]

Der dropped aber gewaltig.

Habe soeben wie von @niemand vorgeschlagen den Komposit vollständig deaktiviert, Neugestartet, und dann nochmal die beiden Varianten durchlaufen lassen, mit folgendem Ergebnis:

#ohne Hardwaredecoding

Code: Alles auswählen

mpv ~/Downloads/video2004.mp4
 (+) Video --vid=1 (*) (h264 1440x1080 60.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1440x1080 yuv420p
AV: 00:00:11 / 00:25:10 (1%) A-V:  0.000 Dropped: 352

#mit Hardwaredecoding

Code: Alles auswählen

mpv ~/Downloads/video2004.mp4
 (+) Video --vid=1 (*) (h264 1440x1080 60.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Using hardware decoding (vaapi).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1440x1080 vaapi[nv12]
AV: 00:00:12 / 00:25:10 (1%) A-V:  0.000 Dropped: 535

Also spätestens jetzt raffe ich garnixmehr.... jetzt sind die Drops plötzlich umgekehrt?! Am ruckeln hat sich übrigens rein subjektiv nix verändert... Die Fenster an sich, also Rahmen etc. scheinen mir zwar etwas flüssiger bzw. direkter bzw. mehr "snappy" zu laufen, aber die Videowiedergabe schein gänzlich unverändert..im Vergleich zu vorher..

[wanne]

Naja. So ganz verwunderlich finde ich das nicht. Wir haben ja schon gemerkt. Das decodieren belastet deine CPU gerade mal zu 2%. Es ist also davon auszugehen, dass das keine ernsthaften Unterschiede macht, die Arbeit an die GPU abzugeben.
Es muss also irgend etwas anderes sein, dass dein System an de Rand seiner Leistungsfähigkeit bringt.
Auch wenn ich es nicht glaube. Du kannst ja mal testen, was das Skalieren aus macht:

Code: Alles auswählen

ffmpeg -hide_banner -t 60 -i ~/Downloads/video2004.mp4 -s 1080x810 -f null -

Ich tippe eher dass da irgend ein Bottleneck beim Kopieren erreicht wird. Ein unkomprimiertes 1440x1080-Video mag zwar kein PCIe/USB-C und schon gar kein RAM oder DMI an den Rand bringen. Aber ein paar unnötige hin und her kopierereien und eventuell andere zusätzliche Belastungen halt schon.
Im Optimalfall kommt das komprimierte Video in die GPU, die macht alle Arbeit und die schmeißt das direkt zum am ihr verbundenen Videoausgang raus. Der einzige weg, wie du ein FullHD-Video (das dekomprimiert bei 60Hz 373MB/s hat) an einer 133MB/s PCI-Port angucken konntest. Ähnlich bei deiner CPU: Die Einzelteile des Videos bleiben direkt im den Registern der CPU. Werden da dekomprimiert, skaliert und dann direkt an den verbundenen DP-Ausgang weiter geleitet.
Die Realität sieht oft anders aus. CPU kopiert komprimiertes Video zur GPU die dekomprimiert kopiert zur CPU zurück die skaliert Kopiert in den WM, der skaliert dank 3D Effekt nochmal mit der GPU auf die erst mal kopiert werden muss. Kopiert zurück zur CPU die das in USB verpackt und dann geht es nochmal über USB an die Docking station....
Da deiner iGPU den gleichen RAM nutzt, den auch die CPU benutzt, kannst du eigentlich der MMU sagen, dass sie einfach ohne kopieren den passenden RAM mit dem der GPU austauscht. – Ob das real passiert, ist erneut eine andere Frage.
Wenn die decodierung in Hardware passiert nimmt das Video von Anfang an einen deutlich anderen Weg. – Ob der jetzt effizienter/ineffizienter ist bleibt dann dem Einzelfall überlassen.
Deswegen die Frage, wie der Bildschirm angebunden ist.

Bin was Windowmanager etwas unbedarft und übervorsichtig

Deswegen ja der Vorschlag mit Sway, der als eigenständiger wayland Compositor so ziemlich gar nichts anfasst das deine XFCE verwendet. Wenn was schief geht kannst du einfach im DM wieder XFCE auswählen und alles ist beim alten.

[rola621]

Sorry für die späte Rückmeldung, war viel los hier!

Hier zunächst mal die Ausgabe von ffmpeg wie vorgeschlagen:

Code: Alles auswählen

ffmpeg -hide_banner -t 60 -i ~/Downloads/video2004.mp4 -s 1080x810 -f null -
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/home/desktop/Downloads/video2004.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.45.100
  Duration: 00:25:10.47, start: 0.000000, bitrate: 5615 kb/s
  Stream #0:0[0x1](und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1440x1080 [SAR 1:1 DAR 4:3], 5345 kb/s, 60 fps, 60 tbr, 15360 tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
  Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 256 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> wrapped_avframe (native))
  Stream #0:1 -> #0:1 (aac (native) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, null, to 'pipe:':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf59.27.100
  Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, progressive), 1080x810 [SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 60 fps, 60 tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc59.37.100 wrapped_avframe
  Stream #0:1(und): Audio: pcm_s16le, 44100 Hz, stereo, s16, 1411 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc59.37.100 pcm_s16le
frame= 1604 fps=1571 q=-0.0 size=N/A time=00:00:27.00 bitrate=N/A speed=26.5x   frame= 2385 fps=1568 q=-0.0 size=N/A time=00:00:40.00 bitrate=N/A speed=26.3x   frame= 3151 fps=1559 q=-0.0 size=N/A time=00:00:52.75 bitrate=N/A speed=26.1x   frame= 3600 fps=1559 q=-0.0 Lsize=N/A time=00:01:00.00 bitrate=N/A speed=  26x    
video:1659kB audio:10336kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

Wollte jetzt mit Sway mein Glück versuchen, allerdings bin ich etwas verunsichert, wenn ich das hier lese:
https://wiki.debian.org/sway
Paket installieren ok, aber welche dieser unzähligen Konfigurationen muss ich in meinem Fall, von Xf4wm kommend, wirklich durchführen?

[GregorS]

Mittlerweile glaube ich auch, dass es an der komischen Codierung des Videos liegt, ...

Diesen Eindruck habe ich auch. Insbesondere, wenn ich

Also es sind zwei Videos, bei denen es sich um "Restaurierungen" im Sinne von "upscale" von älterem Bildmaterial handelt. ...

lese. Das Skalieren eines Filmchens sollte man IMO immer dem Player überlassen. Wenn der etwas taugt, „weiß“ der normalerweise schon selbst, wie er das Skalieren am besten umsetzt.

Gruß

Gregor

PS: Eieiei ... meine Signatur passt hier womöglich wieder einmal wie die Faust aufs Auge ...