</erledigt>mplayer kann Video abspielen, VLC nicht

[hikaru]

libavcodec58 fehlte mir.

Wie kann das sein?
Das ist eine Abhängigkeitskette. Ohnelibavcodec58 kein vlc-plugin-base, und ohne das kein vlc.

[MSfree]

Wie kann das sein?

Wilde Mischung aus Debian und Deb-Multimedia. roli hat die Lib aus Deb-Multimedia nachinstalliert.

Ohne Deb-Multimedia hatte ich mit dem VLC aus dem Debian-Repo auch noch nie solch kuriose Probleme gehabt. Seit mir mal Deb-Multimedia mein System ziemlich zerbröselt hat, fasse ich das nicht mehr an. Das war aber noch zur Etch- oder Lenny-Zeiten (gebranntes Kind scheut das Feuer).

[hikaru]

Das würde bedeuten, dass libavcodec58 bereits installiert war, aber aus dem offiziellen Repo. vlc war aus deb-multimedia installiert.
Beide Versionen waren zueinander inkompatibel und deb-multimedia hat sich nicht darum gekümmert, das in der Abhängigkeitsbehandlung zu berücksichtigen.

Ja, das klingt vertraut. Und genau solche Effekte wie hier sind der Grund für Fremdquellenwarnungen. Das wäre alles nicht nötig, wenn deb-multimedia sauber mit Abhängigkeiten umgehen würde.

[ralli]

?????, Ich habe doch ein normales bullseye, vlc spielt einwandfrei h264 codierte Videos ohne irgendwelche nachinstallierten Codecs oder irgendwelche Postkonfiguration.Vlc tut es einfach ..... ist das so schwer zu verstehen?

Es ist schlicht gelogen. Ich bin mir zwar sicher, dass bullseye auch irgend wo h.264 nach installierbar her bekommt. (Deswegen habe ich ja gefragt wo. Bei mir kommt es halt aus deb-multimedia) Aber sicher ist das nicht per default installiert. Vermutlich hast du dir das als Abhängigkeit von Gnome/KDE hergeholt.

@roli Du kannst natürlich unter Extras->Codecs->Hardwarebeschleunigung->VA-API auch im VLC Hardware decoding einschalten. Muss aber irgend wie auch ohne gehen.

Mein lieber @wanne....

mußt Du so unverschämt übergriffig werden? Mal abwarten, ob Du das Rückgrad und die Reife hast, Dich dafür zu entschuldigen. Wenn nicht, sagt das sehr viel über Deinen Charakter aus. Als Moderator solltest Du einen anderen Ton anschlagen, vorbildlich ist das nicht.

Grüße ralli

[DeletedUserReAsG]

Dein wiederholtes „Aber bei mir funktioniert es!!k“ hat auch nicht gerade viel zum Thread beigetragen, ralli. Überleg dir mal, wie du es aufnehmen würdest, wenn ich bei einem Problem von dir lediglich mehrfach „Aber bei mir funktioniert es!“ drunterschriebe …

Und nein – ich entschuldige mich nicht.

[Blackbox]

Wieso will man eigentlich auf einem Gnome-System überhaupt den vlc Player verwendet, und nicht den Player totem aus dem eigenen Projekt?
Inklusive aller notwendigen GStreamer-Pakete ist dieser Player doch mindestens genauso gut und zieht keine Qt Abhängigkeiten nach.
Hinzukommt, dass dieser Player ausgezeichnet mit allen anderen Gnome Programmen zusammenarbeitet.

Außerdem sollte man auf deb-multimedia.org als Fremdquelle verzichten, dann ist das Leben mit Debian schon viel einfacher.

[wanne]

Wieso will man eigentlich auf einem Gnome-System überhaupt den Debianvlc Player verwendet, und nicht den Player Debiantotem aus dem eigenen Projekt?

Ich verstehe in die andere Richtung nicht, was der Vorteil sein soll.

Inklusive aller notwendigen GStreamer-Pakete ist dieser Player doch mindestens genauso gut und zieht keine Qt Abhängigkeiten nach.

Der Hass auf ein eine einstellige MiB-Anzahl von QT Abhängigkeiten bei gleichzeitigem Vorschlagen von einem Mehrere zig MiB großen Player erschließt sich mir nicht. Daneben kann der VLC objektiv eine Menge mehr. (Bildschirm aufnehmen Streamen, diverse obskure Medien öffnen.) Ob man das braucht ist eine andere  Frage.

Außerdem sollte man auf deb-multimedia.org als Fremdquelle verzichten, dann ist das Leben mit Debian schon viel einfacher.

Wenn man keine Videos gucken will. Sonnst kommt man defakto nicht um Fremdquellen rum.

[roli]

Hallo zusammen,

mein Problem ist wie schon geschrieben gelößt. Dafür nochmal vielen Dank.
Ob debian-multimedia.org jetzt hilfreich, oder doch eher kontraproduktiv ist, das sei mal dahingestellt. Mein System ist schon recht alt, 8te Generation Core i5 halt. Wenn ich mich recht erinnere wusste ich mir damals nicht anders zu helfen. Das ich es jetzt noch in den Quellen habe, war mir nicht bewußt. Wie auch immer, das das ganze hier in einen "Glaubenskrieg", eine virtuelle "Prügelei" ausartet war nicht meine Absicht.

[hikaru]

Außerdem sollte man auf deb-multimedia.org als Fremdquelle verzichten, dann ist das Leben mit Debian schon viel einfacher.

Wenn man keine Videos gucken will. Sonnst kommt man defakto nicht um Fremdquellen rum.

Ich gucke seit Jahren Videos ohne Fremdquellen. Vielleicht geht's bei mir deshalb, weil ich bisher nicht wusste, dass es ohne nicht geht.
... wie bei der Hummel, die ja auch nur deshalb fliegen kann, weil sie nicht weiß, dass sie es eigentlich nicht kann.

Ob debian-multimedia.org jetzt hilfreich, oder doch eher kontraproduktiv ist, das sei mal dahingestellt.

Meiner angestaubten Erfahrung nach funktioniert deb-multimedia dann gut, wenn man Software von Anfang an konsequent von dort bezieht, und nicht einmal von dort und ein anderes mal aus den offiziellen Debianquellen.
Das geht so weit, dass ich sagen würde, dass man deb-multimedia direkt nach der Installation eines Minimalsystems einbinden, und dann erst seinen Desktop installieren sollte. Sobald irgendwas in Richtung Multimedia aus den offiziellen Quellen installiert ist (was eine Standardinstallation möglicherweise tut), ohne dass deb-multimdeia die Chance hatte dazwischenzugrätschen, wird's haarig.

Wie auch immer, das das ganze hier in einen "Glaubenskrieg", eine virtuelle "Prügelei" ausartet war nicht meine Absicht.

Keine Sorge! Das ist nur der Krach vom Schulhof in der großen Pause!

[roli]

Keine Sorge! Das ist nur der Krach vom Schulhof in der großen Pause!

Das kenne ich schon, nur macht's deswegen nicht mehr Spass.
Auch wenn ich hier im Gegensatz zu früher nur noch sporadisch aktiv bin, fand ich es immer gut/angenehm/... das die Pause hier ruhiger verläuft

[fischig]

Mich hätte noch eine Antwort rolis auf die konkrete Analyse hikarus interessiert.

[roli]

@fischig: ich gehe mal davon aus, das du das hier meinst:

Das würde bedeuten, dass Debianlibavcodec58 bereits installiert war, aber aus dem offiziellen Repo. Debianvlc war aus deb-multimedia installiert.
Beide Versionen waren zueinander inkompatibel und deb-multimedia hat sich nicht darum gekümmert, das in der Abhängigkeitsbehandlung zu berücksichtigen.

Wie kann ich das checken?

[fischig]

Soweit mir bekannt, kann man Pakete von deb.multimedia am Namensbestandteil *dmo* erkennen.
Also etwa

Code: Alles auswählen

dpkg -l | grep libavcodec

, vlc, etc.
Wie du's jetzt noch checken kannst, bin ich eher unsicher, weil du ja schon erfolgreich eingegriffen hast. Der Stand vor der Nachinstallation von libavcodec58 (von deb.multimedia?) hätte eher Aufschluss geben können, denke ich.

[roli]

Ich muss sehen ob ich vor meinem Urlaub noch die Zeit finde zu schauen, ob ich so noch was finden kann.
Die Liste an Dingen die unbedingt noch erledigt werden müssen ist lang, und am Samstag Morgen geht's los.

[fischig]

Es ist nicht wichtig. Es ist nur meine Neugier. Und ich gehe eh' davon aus, dass hikarus Analyse voll zutraf.

[roli]

Nur wer versteht was falsch gelaufen ist, kann es in Zukunft besser machen!

[roli]

Das hier kann ich "liefern":

Code: Alles auswählen

root@griffon:~# dpkg -l | grep libavcodec
ii  libavcodec57:amd64                            10:3.3.9-dmo1+deb9u1                   amd64        Library to encode decode multimedia streams - runtime files
ii  libavcodec58:amd64                            10:4.4-dmo4+deb11u4                    amd64        Library to encode decode multimedia streams - runtime files
root@griffon:~# dpkg -l | grep vlc
ii  libvlc-bin:amd64                              1:3.0.16-dmo1                          amd64        tools for VLC's base library
ii  libvlc5:amd64                                 1:3.0.16-dmo1                          amd64        multimedia player and streamer library
ii  libvlccore9:amd64                             1:3.0.16-dmo1                          amd64        base library for VLC and its modules
ii  phonon4qt5-backend-vlc:amd64                  1:0.11.3-dmo1                          amd64        Phonon4Qt5 VLC backend
ii  vlc                                           1:3.0.16-dmo1                          amd64        multimedia player and streamer
ii  vlc-bin                                       1:3.0.16-dmo1                          amd64        binaries from VLC
ii  vlc-data                                      1:3.0.16-dmo1                          all          Common data for VLC
ii  vlc-l10n                                      1:3.0.16-dmo1                          all          Translations for VLC
ii  vlc-plugin-base:amd64                         1:3.0.16-dmo1                          amd64        multimedia player and streamer (base plugins)
ii  vlc-plugin-notify:amd64                       1:3.0.16-dmo1                          amd64        LibNotify plugin for VLC
ii  vlc-plugin-qt:amd64                           1:3.0.16-dmo1                          amd64        multimedia player and streamer (Qt plugin)
ii  vlc-plugin-samba:amd64                        1:3.0.16-dmo1                          amd64        Samba plugin for VLC
ii  vlc-plugin-skins2:amd64                       1:3.0.16-dmo1                          amd64        multimedia player and streamer (Skins2 plugin)
ii  vlc-plugin-video-output:amd64                 1:3.0.16-dmo1                          amd64        multimedia player and streamer (video output plugins)
ii  vlc-plugin-video-splitter:amd64               1:3.0.16-dmo1                          amd64        multimedia player and streamer (video splitter plugins)
ii  vlc-plugin-visualization:amd64                1:3.0.16-dmo1                          amd64        multimedia player and streamer (visualization plugins)
root@griffon:~

Bringt aber natürlich nichts in Bezug darauf wann was installiert wurde.

[fischig]

libavcodec58 fehlte mir.

Da dürfte der Fehler gewesen sein. libavcodec58 „an sich“ wird wohl nicht gefehlt haben. Ohne funktioniert vlc nicht. Aber das stammte wohl von debian. Gefehlt haben dürfte libavcodec58 von deb-multimedia mit dem der vlc von deb-multimedia dann nicht zurechtkam. Kann man aber jetzt wohl nicht mehr nachvollziehen, dass libavcodec58 vor der Nachinstallation von Debian stammte. Vielleicht kannst du dich erinnern, dass apt bei der Nachinstallation nicht „neu installiert“, sondern sowas wie „Paket aktualisiert“ gemeldet hat. Das wäre dann ein indirekter Hinweis darauf, dass das Paket „an sich“ bereits installiert war. Falls du synaptic benutzt, weiß ich mangels Erfahrung damit allerdings nicht, ob das GUI-Programm den Benutzer mit solchen Feinheiten „belästigt“.

[wanne]

Ich gucke seit Jahren Videos ohne Fremdquellen. Vielleicht geht's bei mir deshalb, weil ich bisher nicht wusste, dass es ohne nicht geht.

Wenn ichs richtig weiß, tut ohne keine Blurays, kein Flash und weder h.265 novh AV1. Klar das meiste Video kommt heute über Web per VP9 oder h.264. Aber wer regelmäßig guckt sollte doch regelmäßig über eine der Kategorieen stolpern. Wenn das bei dir anders ist tut natürlich alles.

Meiner angestaubten Erfahrung nach funktioniert deb-multimedia dann gut, wenn man Software von Anfang an konsequent von dort bezieht, und nicht einmal von dort und ein anderes mal aus den offiziellen Debianquellen.

Ja. Wobei nachträgliches hinzufügen kein Problem ist. Nur wieder weg macht ärger und wenn man es dann wieder dran hängt wird es nicht besser und sobald man noch ein paar Testing Pakete dazu haut, wird es richtig lustig. Hintergrund ist, dass die Pakete aus deb-multimedia absichtlich immer größere Versionsnummern als die aus debian haben und dann auch von denen abhängen. Installiert man was aus deb-multimedia werden automatisch alle Abhängigkeiten auf deb-multimedia gezogen. – Und im Normalfall ist das auch gut getestet. Macht man dann ein mal ein apt update ohne deb-multimedia findet apt eventuell eine noch neuere Version aus den Orginalquellen... Und zu der passt dann nichts.

Gefehlt haben dürfte libavcodec58 von deb-multimedia mit dem der vlc von deb-multimedia dann nicht zurechtkam.

Ich tippe eher anders herum. Der deb-multimedia VLC will die libavcodec58 aus deb-multimedia. Während man die libavcodec58 aus deb-multimedia meint problemlos mit der aus Debian zurecht zu kommen. Eventuell hakt es da.

[hikaru]

Wenn ichs richtig weiß, tut ohne keine Blurays,

Mag sein, kann ich nicht prüfen.

kein Flash

Ging früher (vor 10 Jahren(?), als Flash noch ansatzweise relevant war) ohne dmo.

und weder h.265 novh AV1.

Das geht zumndest mit mpv auch ohne dmo. Für mplayer und vlc weiß ich es nicht, aber da die alle auf ffmpeg aufsetzen würde ich es erwarten.

Hintergrund ist, dass die Pakete aus deb-multimedia absichtlich immer größere Versionsnummern als die aus debian haben und dann auch von denen abhängen.

Und das ist halt Mist, weil unsauber. Die saubere Lösung wäre, durchgängig eigene Paketnamen ("-dmo") zu vergeben und mt "conflicts" sowie "provides" zu arbeiten. Dann könnte man nämlich nach dem Entfernen von dmo aus der sources.list alle dmo-Pakete deinstallieren und apt würde die Regulären als Alternativen ziehen.

Installiert man was aus deb-multimedia werden automatisch alle Abhängigkeiten auf deb-multimedia gezogen. – Und im Normalfall ist das auch gut getestet.

Eine Drittquelle die zwar die Installation ihrer Pakete testet aber nicht ihre Deinstallation ist für mich nicht gut getestet. Es zeugt nämlich von einer gewissen "Nabel der Welt"-Einstellung des Drittanbieters, die nicht berechtigt ist. Sonst müsste er kein Drittanbieter sein sondern wäre offizieller Teil von Debian.

Gefehlt haben dürfte libavcodec58 von deb-multimedia mit dem der vlc von deb-multimedia dann nicht zurechtkam.

Ich tippe eher anders herum. Der deb-multimedia VLC will die libavcodec58 aus deb-multimedia. Während man die libavcodec58 aus deb-multimedia meint problemlos mit der aus Debian zurecht zu kommen.

Die Richtung dürfte egal sein. Es kann in beide Richtungen ABI-Brüche geben.
mpv meckert z.B., wenn man es auf ffmpeg-Libs startet, mit denen es nicht gebaut wurde. Und nicht selten bleibt es nicht beim Meckern.


@roli:
Du könntest deine /var/log/apt/history.log nach "dmo" greppen, falls du doch noch schlauer werden willst.

[MSfree]

kein Flash

Ging früher (vor 10 Jahren(?), als Flash noch ansatzweise relevant war) ohne dmo.

Flash geht nach wie vor ohne Deb-Multimedia. Es gibt auch immer noch flv-Formate auf Youtube, halt von uralten Videos, die Google nicht umkonvertiert hat.

und weder h.265 novh AV1.

vlc weiß ich es nicht.

VLC kann H265 out of the Box, ohne Deb-Multimedia. AV1 habe ich gerade keine passenden Dateien zur Hand. Mich würde es aber wundern, wenn VLC das nicht könnte.

Das, was Deb-Multimedia unter anderem mitliefert, ist DeCSS für DVDs und das Pendant für die Blueray-Decryption. Und für das Abspielen von DVDs reicht es, DeCSS von Deb-Multimedia runterzuladen und zu installieren, ohne den VLC auszutauschen.

[wanne]

Flash geht nach wie vor ohne Deb-Multimedia. Es gibt auch immer noch flv-Formate auf Youtube, halt von uralten Videos, die Google nicht umkonvertiert hat.

Das kann ich nicht glauben. Da Chrome das nicht mehr supportet kann ich mir kaum vorstellen, dass Google jetzt Leute dazu drängt andere Browser zu nutzen. Hast du ein Beispiel?

VLC kann H265 out of the Box, ohne Deb-Multimedia.

Interessant. Weißt du mit welcher lib?

Und für das Abspielen von DVDs reicht es, DeCSS von Deb-Multimedia runterzuladen und zu installieren, ohne den VLC auszutauschen.

Aber genau damit machst du dir halt die Probleme. Für libdvdread4 ändert sich nicht mehr viel aber genau über alte libavcodec58 von deb-multimedia stolpert der neue vlc.

Es zeugt nämlich von einer gewissen "Nabel der Welt"-Einstellung des Drittanbieters, die nicht berechtigt ist. Sonst müsste er kein Drittanbieter sein sondern wäre offizieller Teil von Debian.

Christian Marillat war lange Zeit auch maintainer vom offiziellen VLC aus debian. Alles was er macht ist codecs einzucompiliren die rechtlich (insbesondere außerhalb von Frankreich) problematisch sind. (Kopierschutzumgehung ist z.B. in Deutschland verboten. Kopierschutz heißt aber immer auch Abspielschutz unter Linux.) und einige Pakete die nicht mit den debian Guidelines vereinbar sind. Vor allem einige mplayer Features, die für Debian zu buggy sind Marillat aber trotzdem für nützlich hält.

Und das ist halt Mist, weil unsauber. Die saubere Lösung wäre, durchgängig eigene Paketnamen ("-dmo") zu vergeben und mt "conflicts" sowie "provides" zu arbeiten

So einfach ist es nicht. Er kann nicht conflicts auf Pakete legen die erst später in den Debian-Repos auftauchen. Und für provides müssten die Debianer mitspielen und eben auch provides für ihre libs bauen. Das hat er machen können als er noch Teil von Debian war. Jetzt nicht mehr. Ähnlich wie die systemd-leute systemv-kompatibilität kaputt schießen konnten indem sie hart die Abhängigkeiten von Gnome und Co auf systemd-logind statt auf das virtuelle Pakete logind und init-system gesetzt haben und systemd-udevd einfach in udev umbenannt haben. Alles was du dann machen kannst ist dich anders zu benennen (und dann Upgrades und Kombinationen zu verunmöglichen) oder eben höhere Versionen zu verwenden und zu versuchen auf jede Änderung möglichst schnell zu reagieren.

[hikaru]

Es zeugt nämlich von einer gewissen "Nabel der Welt"-Einstellung des Drittanbieters, die nicht berechtigt ist. Sonst müsste er kein Drittanbieter sein sondern wäre offizieller Teil von Debian.

Christian Marillat war lange Zeit auch maintainer vom offiziellen VLC aus debian. Alles was er macht ist codecs einzucompiliren die rechtlich (insbesondere außerhalb von Frankreich) problematisch sind. (Kopierschutzumgehung ist z.B. in Deutschland verboten. Kopierschutz heißt aber immer auch Abspielschutz unter Linux.) und einige Pakete die nicht mit den debian Guidelines vereinbar sind. Vor allem einige mplayer Features, die für Debian zu buggy sind Marillat aber trotzdem für nützlich hält.

Und das kann er auch gern so halten. Aber es gibt eben Gründe, warum seine Pakete nicht offizieller Teil Debians sind.
Unter'm Strich bleibt stehen, dass man seine Pakete zu einem bestehenden Debian zwar hinzufügen, aber nicht wieder entfernen kann. Und das ist nunmal unsauber. Ähnliche Zustände innerhalb des offiziellen Repos wären release-critical.

Er kann nicht conflicts auf Pakete legen die erst später in den Debian-Repos auftauchen.

Muss er auch nicht. Keiner installiert libavcodec58 manuell als Selbstzweck und bekäme dann Probleme, wenn es durch libavcodec59 ersetzt wird. Es ist eine automatisch installierte Abhängigkeit von z.B. vlc.
Wenn nun vlc-dmo von libavcodec58-dmo abhinge und beide provides und conflicts für ihre jeweiligen nicht-dmo-Äquivalente setzen würden, die depends aber auf die dmo-Pakete gehen würden und Marillat seine Updates zeitlich auf die offiziellen Debian-Updates abstimmen würde (das ließe sich scripten, auch wenn er gerade schläft), dann gäbe es keine Probleme.

Und für provides müssten die Debianer mitspielen und eben auch provides für ihre libs bauen.

Nein, müssten sie nicht. Warum?
Streng genommen muss nicht mal Marillat das tun, denn eigentlich wäre das provides nur dazu da, offiziellen Debianpaketen, deren Abhängigkeiten durch dmo-Pakete ersetzt werden, nicht den Boden unter den Füßen wegzuziehen. Da man aber in dem Fall eigentlich sowieso mit ABI-Brüchen rechnen muss, so wie es aktuell auch häufig passiert, müsste Marillat ohnehin die ganz Kette der Pakete neu bauen und eben alles war z.B. direkt oder indirekt von libavcodec58 abhängt mit eigenen Paketen ersetzen.
Ja das ist aufwändiger. Aber so ist das halt, wenn man es sauber machen will. Genau dieser Punkt war übrigens vor einigen Jahren Streitpunkt zwischen Ubuntu und Mint, denn Mint macht mit seinen Repos im Grunde das Gleiche wie Marillat mit dmo, nur hängt Mint das höher auf und verkauft es als eigene Distribution. Canonical wollte das nicht mehr, weil es seinen Ruf durch die dadurch verursachten ABI-Brüche gefährdet sah. Ich weiß nicht mehr wie das ausging, ob Canonocal vor Gericht gezogen ist und es zum Vergleich kam, oder ob man vorher entschieden hat, dass es die Sache nicht wert ist. Am Ende kam aber raus, dass Mint ein wenig nachgebessert hat und jetzt mehr selbst compiliert, aber dass das grundlegende Problem nach wie vor besteht.

Ähnlich wie die systemd-leute systemv-kompatibilität kaputt schießen konnten indem sie hart die Abhängigkeiten von Gnome und Co auf systemd-logind statt auf das virtuelle Pakete logind und init-system gesetzt haben und systemd-udevd einfach in udev umbenannt haben.

Das ist organisatorisch eine andere Geschichte. Das ist alles Debian-intern. Man hat sich intern bei Debian geeinigt, das jetzt so zu machen und bietet nun einen neuen, konsistenten Zustand an.
Das Äquivalent für Marillat wäre gewesen, Debians Ausrichtung entsprechend zu ändern, so dass seine Pakete die offiziellen wären. Hat er nicht geschafft. Wenn er nicht bereit ist sein Zusatzrepo sauber zu führen, dann wäre die saubere Alternative, Debian insgesamt zu forken, so wie es Devuan gemacht hat.

Edit:
Wenn Marillat seine aktuelle Praxis beibehalten will, dann sollte er sich dafür einsetzen, dass in Debian ein sauberer Downgrade-Mechanismus implementiert wird.

[electri]

Bin gerade über den Thread gestolpert, da ich das gleiche Problem habe. Allerdings lags bei mir nicht an irgendwelchen Paketen:
Ich habe einen i5-11500 mit integrierter IntelGrafik. Da ich keinen Backports-kernel verwende, brauche ich einen speziellen Kernel-parameter beim Booten um Grafik zu haben. Deb-Multimedia ist nicht installiert. Alle VLC-Pakete sind ordnungsgemäß aus den offiziellen Debian-quellen installiert, so auch libavcodec58. MPV (smplayer-frontend) spielt Videos ohne Probleme. VLC spielt nur Ton, aber kein Bild. In VLC hat bei den Einstellungen unter Eingang/Codecs eine Änderung von "Hardware-beschleunigte Decodierung"Automatisch->VDPAU-Videodecoder zum Erfolg geführt. Nun funktionieren Videos auch mit VLC.

[hikaru]

Ich habe einen i5-11500 mit integrierter IntelGrafik.
[..]
VLC spielt nur Ton, aber kein Bild. In VLC hat bei den Einstellungen unter Eingang/Codecs eine Änderung von "Hardware-beschleunigte Decodierung"Automatisch->VDPAU-Videodecoder zum Erfolg geführt.

Diese vlc-Einstellung sollte eigentlich nicht nötig sein. Ist bei dir firmware-misc-nonfree installiert?

MPV (smplayer-frontend) spielt Videos ohne Probleme.

Wirklich? Wenn vlc keine Hardwarebeschleunigung nutzen kann, würde ich erwarten, dass mpv es auch nicht kann. Nur wirst du davon nichts merken, weil mpv sanft auf Softwaredecodierung zurückfällt und deine CPU stark genug ist, die meisten Videos auch in Software zu decodieren.
Versuche mal, ein Video in mpv gezielt mit Hardware-Decodierung zu starten:

Code: Alles auswählen

mpv --vo=gpu --hwdec=gpu VIDEODATEI

Dann schau dir die Terminalausgabe von mpv an, ob du eine Meldung wie diese findest:

Code: Alles auswählen

falling back to software decoding