Leap 16.0: VLC spielt keine mp4-Videos ab, Ton ist zu hören

Hinweis: In dem Thema Leap 16.0: VLC spielt keine mp4-Videos ab, Ton ist zu hören gibt es 23 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Nach einem Neustart sieht das Ergebnis so aus:


    Code
    zypper ps -s
    Es wurden keine Prozesse gefunden, die gelöschte Dateien verwenden.
    
    Seit dem letzten Systemstart sind keine zentralen Bibliotheken oder Dienste aktualisiert worden.
    Ein Neustart ist wahrscheinlich nicht notwendig.
    
    Hinweis: Bei Ausführung ohne root-Berechtigung sind Sie auf die Suche nach Dateien beschränkt, für die Sie Berechtigungen zur Untersuchung mit der Systemfunktion stat(2) haben. Das Ergebnis kann unvollständig sein.

    Für den Inhalt des Beitrages 324785 haftet ausdrücklich der jeweilige Autor: deneb

  • Bei Ausführung ohne root-Berechtigung sind Sie auf die Suche nach Dateien beschränkt, für die Sie Berechtigungen zur Untersuchung mit der Systemfunktion stat(2) haben. Das Ergebnis kann unvollständig sein.

    Lesen und verstehen.......

  • Nach einem Neustart sieht das Ergebnis so aus:

    ... eigentlich macht zypper ps -s nur vor einem reboot Sinn, um festzustellen, ob es laufende Programme gibt, die von der durchgeführten Installation überhaupt betroffen sind.

    Für den Inhalt des Beitrages 324787 haftet ausdrücklich der jeweilige Autor: luigi

  • Was wäre die bessere Reihenfolge bei der Installation von Leap 16.0 gewesen, um solche Konflikte mit dem VLC zukünftig zu vermeiden?

    Für den Inhalt des Beitrages 324790 haftet ausdrücklich der jeweilige Autor: deneb

  • Was wäre die bessere Reihenfolge bei der Installation von Leap 16.0 gewesen, um solche Konflikte mit dem VLC zukünftig zu vermeiden?

    Das sind keine Konflikte.

    openSUSE veröffentlicht keine patent behaftete oder mit eingeschränkten Lizenzen behaftete Pakete.


    Darunter fallen z.B. die h264 oder h265 Codecs.

    openSUSE baut die mitgelieferten ffmpegs ohne diese Codecs, Packman nimmt dasselbe src.rpm und baut daraus die ffmpegs mit diesen Codecs.

    Daher hat openSUSE seit ein paar Jahren das openh264 Repo veröffentlicht, dies stammt von Cisco, da dort anscheinend auch Patente liegen.

    Wenn du das Packman Repo eingebunden hast und darauf umgestellt hast (das war dein Problem), dann brauchst du das openh264 Repo nicht mehr.


    Code
    zypper lr -d | grep -i 264
    23 | openh264                         | openh264                         | Nein    | ----      | ----    | -    |   99     | rpm-md   | http://codecs.opensuse.org/openh264/openSUSE_Leap/


    Bei vlc kommt eine Besonderheit hinzu:

    Packman baut vlc mit einem vlc-codecs Paket, welches solche patentbehafteten Codecs enthält.

    Code
    rpm -ql vlc-codecs
    /usr/lib64/vlc/plugins/codec/libfaad_plugin.so
    /usr/lib64/vlc/plugins/codec/libx26410b_plugin.so
    /usr/lib64/vlc/plugins/codec/libx264_plugin.so
    /usr/lib64/vlc/plugins/codec/libx265_plugin.so
  • Also muss ich darauf achten, dass ich das openh264 Repo immer weglasse, wenn ich das Packman Repo eingebunden habe. Habe ich das richtig verstanden?

    Für den Inhalt des Beitrages 324795 haftet ausdrücklich der jeweilige Autor: deneb

  • Also erst Packman-Repo einbinden, VLC installieren, testen, ob er mp4-Videos abspielt und dann erst das openh264 Repo einbinden.

    Nö, es ist egal wie herum du die einbindest und ob das openh264 Repo eingebunden ist oder nicht.


    Packman ersetzt das openh264 Repo, aber es macht nichts, wenn das openh264 Repo trotz Packman eingebunden ist.

    Beide benutzen unterschiedliche Namen für die darin befindlichen Pakete.

  • Nö, es ist egal wie herum du die einbindest und ob das openh264 Repo eingebunden ist oder nicht.


    Packman ersetzt das openh264 Repo, aber es macht nichts, wenn das openh264 Repo trotz Packman eingebunden ist.

    Beide benutzen unterschiedliche Namen für die darin befindlichen Pakete.

    Ich dachte, die Reihenfolge würde verhindern, dass sich ein Problem wie gestern ergeben würde.

    Für den Inhalt des Beitrages 324799 haftet ausdrücklich der jeweilige Autor: deneb