ubuntuusers.de

Wenn ich ein Video in Handbrake lade, dann kann ich als Zielformat nur x264 oder x265 wählen. Der freie Codec vp9 ist ausgegraut und AV1 ist gar nicht verfügbar. Für AV1 fehlen zurzeit effiziente Codecs. Aber für vp9 müsste es doch Möglichkeiten geben. Vielleicht hat jemand Erfahrung damit und kann mir Tipps geben. Da wäre ich sehr dankbar.

Was spricht gegen FFmpeg auf der Kommandozeile? Sieh https://trac.ffmpeg.org/wiki/Encode/VP9

Von grafischen Programmen hat zum Beispiel Avidemux ein libvpx-Plugin, womit Video mit VP9 komprimiert werden kann. Jedoch ist im Plugin ein erhebliches Problem mit RC (rate control, Bitratensteuerung) erst vor wenigen Stunden behoben worden. Man müsste deswegen entweder selbst kompilieren oder eine Weile warten, bis es neue AppImages gibt.

Selbstredend benutzt auch FFmpeg dieselbe libvpx wie Avidemux. Der VP9-Encoder in dieser Bibliothek liefert zwar eine hohe Qualität, ist aber sehr langsam.

Für AV1 erst mal gucken ob der jeweilige FFmpeg mit der entsprechenden Option (--enable-libaom) gebaut wurde und die Codec Liste nach "AV1" durchgrepen:

ffmpeg -codecs | grep -i "AV1"

Dann dort gucken: https://trac.ffmpeg.org/wiki/Encode/AV1

Leider ist libaom eine Schnecke. Das encodieren verlangt also eine Supermaschine oder ist extrem langsam. rav1e (https://github.com/xiph/rav1e) sollte schneller sein, aber muss auch erst mal selbst in den FFmpeg eingebaut werden. Viel Spaß dabei. https://askubuntu.com/questions/1189174/how-do-i-use-ffmpeg-and-rav1e-to-create-high-quality-av1-files

Was VP9 angeht, ist inzwischen ein frisches AppImage von Avidemux mit fehlerbereinigtem libvpx-Plugin auf dem Avidemux-Server verfügbar.

Grundsätzlich sollte man den besten Codec nehmen, den man auf dem anvisierten Gerät hardwarebeschleunigt dekodieren kann. Wenn man nicht gerade einen brandneuen Smart-TV der gehobenen Klasse oder einen Rechner mit Intel Xe, NVIDIA RTX 30xx oder AMD Radeon RX 6000 sein eigen nennt oder eine baldige Anschaffung plant, ergibt das Verbraten einer Menge Strom zum Komprimieren mit AV1 IMHO wenig Sinn.

Beim älteren VP9 sieht es natürlich besser aus (zum Beispiel, mit NVIDIA ab GTX 10xx ist man auf der sicheren Seite).

trollsportverein schrieb:

Für AV1 erst mal gucken ob der jeweilige FFmpeg mit der entsprechenden Option (--enable-libaom) gebaut wurde und die Codec Liste nach "AV1" durchgrepen:

ffmpeg -codecs | grep -i "AV1"

Ich bekomme als Antwort u.a.:

ffmpeg version 4.3.1-4ubuntu1 Copyright (c) 2000-2020 the FFmpeg developers
  built with gcc 10 (Ubuntu 10.2.0-9ubuntu2)
(...)
 DEV.L. av1                  Alliance for Open Media AV1 (decoders: libdav1d libaom-av1 ) (encoders: libaom-av1 )

Ich möchte ein Video möglichst platzsparend archivieren. Ich könnte x265 als Codec nutzen, oder lieber VP9/AV1, die komplett Open Source sind. Was spricht denn dagegen?

Ich nutze Handbrake, weil das Programm sehr komfortabel ist. Ich habe aber kein Problem mit ffmpeg auf der Kommandozeile. Deswegen frage ich hier, ob jemand mit VP9 encoding schon Erfahrungen gesammelt hat.

moonwalker3 schrieb:

Wenn ich ein Video in Handbrake lade, dann kann ich als Zielformat nur x264 oder x265 wählen. Der freie Codec vp9 ist ausgegraut und AV1 ist gar nicht verfügbar. Für AV1 fehlen zurzeit effiziente Codecs. Aber für vp9 müsste es doch Möglichkeiten geben. Vielleicht hat jemand Erfahrung damit und kann mir Tipps geben. Da wäre ich sehr dankbar.

Eine Fage hierbei ist: Was ist das Quellmaterial? Ist es irgendein lossy-Format,dann lass die Konvertierung und benutze lieber vorerst den codec, den das Video hat. Von lossy zu lossy konvertieren bringt nämlich zwangsweise Qualitätsverluste und das sollte man immer vermeiden. Also entweder so lassen oder zu lossless konvertieren (was aber wegen Dateigrößen noch nicht sinvoll sein kann), um zukünftigen Qualitätsverlust zu vermeiden. Erst recht archivieren sollte man die beste Version, die man hat und nicht auf den Speicherplatz achten! Speicherplatz kann man einfach erweitern mittlereile auch zu bezahlbaren Preisen. Dagegen einmal das Video verkleinert (und verkrüppelt) und man kann nie wieder zurück. In 10 oder 20 Jahren ärgert man sich (oder die Nachkommen), dass man keine besere Version hat, obwohl man die damals eben doch bereits hatte.

Was man machen kann: Das Material in einen anderen Medienkontainer verpacken. Beispielsweise von MP4 zu MKV. Ich nutze MKV

Ich rate auch eher von den „next generation codecs“ wie x265 und AV1 ab. Grund: Sie sparen enorm Platz ein gegenüber den Vorgängern. Ohne irgendwelche Qualitätsverluste ist das eigentlich gar nicht mehr möglich, so viel Platz einzusparen. Irgendwo muss man da an der Qualität weiter manipulieren, um die Daten zu speichern. Das will ich den Videos echt nich antun. Man sollte leiber die bestehenden alten codecs benutzen und bei Gelegenheit in der Zukunft mehr in Richtung lossless gehen, dann hat man sauberstes Material. Ich fürchte mich ehrlich gesagt für die Zukunft, wenn alle die AV1-Soße benutzen …

shinichi schrieb:

Eine Fage hierbei ist: Was ist das Quellmaterial? Ist es irgendein lossy-Format,

Das Quellmaterial ist immer lossy. Wenn du eine DVD hast, ist es Mpeg2, bei einer Bluray halt Mpeg4 ACV (h264). Oder kennst du Medien, die dir ein RAW-Video ausgeben?

Was man machen kann: Das Material in einen anderen Medienkontainer verpacken. Beispielsweise von MP4 zu MKV. Ich nutze MKV

Dann habe ich nichts gewonnen!

Ich rate auch eher von den „next generation codecs“ wie x265 und AV1 ab. Grund: Sie sparen enorm Platz ein gegenüber den Vorgängern. Ohne irgendwelche Qualitätsverluste ist das eigentlich gar nicht mehr möglich, so viel Platz einzusparen.

Das stimmt doch nicht. Man kann bei einem Codec eine bestimmte Qualität einstellen, dann hat man ein gutes Ergebnis.

moonwalker3 schrieb:

Ich möchte ein Video möglichst platzsparend archivieren. Ich könnte x265 als Codec nutzen, oder lieber VP9/AV1, die komplett Open Source sind. Was spricht denn dagegen?

Zunächst mal ist x265 selbstverständlich komplett Open Source (GPLv2). HEVC an sich ist auch vollumfänglich standardisiert und dokumentiert. Was Du meinst sind wahrscheinlich Kosten, die für eine lizensierte Nutzung des patentgeschützten Codecs anfallen würden.

Bei VP9 und seinem Nachfolger AV1 ist die Lage nur so, dass etliche Akteure Unsicherheit verbreiten, indem sie behaupten, Patente auf Teile davon zu halten. Mir ist einfach nicht bekannt, wie der letzte Stand auf dem schmutzigen Feld der Patentkriege so ist.

Gegen Priorisierung von Speicherplatzverbrauch gegenüber Qualitätsverlust und Energieverbrauch durch Neukodierung und besonders durch spätere Wiedergabe ohne hardwarebeschleunigte Dekodierung sprechen niedrige Preise für herkömmliche, rotierende Festplatten. Jedenfalls würde ich nur dann H.264-Quellmaterial in VP9 oder AV1 neu kodieren, wenn hierbei wichtige andere Aufgaben miterledigt werden, zum Beispiel Deinterlacing.

Beim Dinosaurier MPEG-2 ist es eine andere Sache, jedoch haben viele Video-DVD eine derart erbärmliche Qualität, von einer bescheidenen 704x480 (NTSC) oder 704x576 (PAL) Auflösung ganz zu schweigen (720 ist 704 + 8 pixel auf jeder Seite für Overscan), dass ich persönlich sie nicht noch weiter verschlechtern möchte.

Ich nutze Handbrake, weil das Programm sehr komfortabel ist. Ich habe aber kein Problem mit ffmpeg auf der Kommandozeile. Deswegen frage ich hier, ob jemand mit VP9 encoding schon Erfahrungen gesammelt hat.

Während der Arbeit am VP9 Video Encoder Plugin in Avidemux habe ich einige kurze Videos mit VP9 komprimieren müssen. Dabei ist mir nur aufgefallen, dass eine vom Geschehen im Video abhängige Platzierung der Keyframes nur im 2-Pass-Modus möglich ist, sonst ist die GOP-Länge konstant (die Vorgabe ist 128 Frames). Beim Codec gibt es meines (Un)Wissens kein Frame Reordering, also keine B-Frames, was Schnitt im Kopiermodus sehr erleichtert. Die Bildqualität bei den zu H.264 vergleichbaren Bitraten kann ausgezeichnet gut aussehen, aber eine höhere Kompression wird mit sehr langsamer Kodiergeschwindigkeit erkauft – auf meiner zugegebenermaßen älteren Hardware erreiche ich bei FullHD-Material kaum 2 FPS.

shinichi schrieb:

Ich rate auch eher von den „next generation codecs“ wie x265 und AV1 ab. Grund: Sie sparen enorm Platz ein gegenüber den Vorgängern. Ohne irgendwelche Qualitätsverluste ist das eigentlich gar nicht mehr möglich, so viel Platz einzusparen.

Im Umkehrschluss bedeutet es, dass bei vergleichbarer (praktisch etwas niedrigerer als beim altehrwürdigen H.264) Bitrate die Qualität überragend ist. Einzig auf die Verfügbarkeit der Dekodierung in Hardware sollte meiner Meinung nach aus Umweltschutzgründen geachtet werden.

eumagga0x2a schrieb:

Beim Dinosaurier MPEG-2 ist es eine andere Sache, jedoch haben viele Video-DVD eine derart erbärmliche Qualität, von einer bescheidenen 704x480 (NTSC) oder 704x576 (PAL) Auflösung ganz zu schweigen (720 ist 704 + 8 pixel auf jeder Seite für Overscan), dass ich persönlich sie nicht noch weiter verschlechtern möchte.

Welches Zielformat würdest für MPEG2 wählen? x264 oder x265/VP9?

MPEG2-Material ist oft interlaced, womit sich eine Neucodierung in ein effizienteres Format anbietet. In wiefern ist die Breite von 704 oder 720 Pixeln entscheidend, wenn man beim Ergebnis im MKV-Container 4:3 oder 16:9 einstellt?

moonwalker3 schrieb:>

Das Quellmaterial ist immer lossy. Wenn du eine DVD hast, ist es Mpeg2, bei einer Bluray halt Mpeg4 ACV (h264). Oder kennst du Medien, die dir ein RAW-Video ausgeben?

Ntürlich gibts die, nämlich die,die man mit einer eigenen Kamera in RAW aufnimmt.

Dann habe ich nichts gewonnen!

Doch schon. MKV ist besser, allein weil es nicht proprietär ist.

Das stimmt doch nicht. Man kann bei einem Codec eine bestimmte Qualität einstellen, dann hat man ein gutes Ergebnis.

Ja, das geht natürlich, allerdings gibts dann auch den selben Speicherplatz. Wozu dann ein neuer codec, der erst überall implementiert werden muss und die ganze software unnötig komplizierter macht?

moonwalker3 schrieb:

MPEG2-Material ist oft interlaced, womit sich eine Neucodierung in ein effizienteres Format anbietet.

Tu es nicht, du verschlechterst die Qualität. Wenn sie schon so schlecht ist, auch der geringen Auflösung geschuldet, dann wird die konvertierung in H.264 oder anderes lossy Zeug noch übler und man sieht Artefakte erst recht! Dann hast du gar nix gewonnen, sondern nur verloren! Lass den bestehenden codec und konvertiere höhstens zu lossless (wenn Speicherplatz keine Rolle spielt), damit die Videodaten bei späterer Bearbeitung keinen Qualitätsverlust mehr haben.

moonwalker3 schrieb:

eumagga0x2a schrieb:

Beim Dinosaurier MPEG-2 ist es eine andere Sache, jedoch haben viele Video-DVD eine derart erbärmliche Qualität, von einer bescheidenen 704x480 (NTSC) oder 704x576 (PAL) Auflösung ganz zu schweigen (720 ist 704 + 8 pixel auf jeder Seite für Overscan), dass ich persönlich sie nicht noch weiter verschlechtern möchte.

Welches Zielformat würdest für MPEG2 wählen? x264 oder x265/VP9?

Wie oben gesagt, ich würde tunlichst vermeiden, die Quelle neu zu kodieren. Wenn es aber wegen spezieller Anforderungen (zum Beispiel, wiedergabe auf einem Smartphone oder Tablet) unumgänglich sein sollte, würde ich die Wahl sowohl des Formats (des Containers) als auch des Codecs (H.264, HEVC, VP9 oder AV1) abhängig von den Fähigkeiten der konkreten Hardware und Software treffen. Das Kriterium: Es muss möglich sein, den Codec in Hardware zu dekodieren. Falls die Hardware nur H.264 kann, wird es zwangsläufig H.264 sein, gerne mit x264 als Encoder. Kann die Hardware auch HEVC, dann x265 anwerfen und viel Geduld mitbringen. Geht auch VP9 oder gar AV1 – dann halt noch viel mehr Strom und Geduld investieren.

Bei niedriger Auflösung schwinden allerdings die Vorteile moderner Codecs. Sie bleiben dennoch eine bessere Wahl, falls die Hardware mitspielt.

MPEG2-Material ist oft interlaced, womit sich eine Neucodierung in ein effizienteres Format anbietet. In wiefern ist die Breite von 704 oder 720 Pixeln entscheidend, wenn man beim Ergebnis im MKV-Container 4:3 oder 16:9 einstellt?

Technisch kennt MKV nur Display-Breite, wegen der Usability erlauben aber viele Tools, stattdessen ein Seitenverhältnis anzugeben. In diesem Fall wird die angezeigte Breite von der Bildhöhe abgeleitet. Betrachtet man es sehr streng, sollte der Player 720 px wie auf einem Röhrenfernseher mit Overscan auf 704 beschneiden und erst dann horizontal strecken. Praktisch bezweifle ich, dass das Ausgangsmaterial immer dafür ausgelegt ist. Im Ergebnis können Objekte im Bild geringfügig (um rund 3% im Breitbildformat) zu schmal erscheinen.

shinichi schrieb:

MKV ist besser, allein weil es nicht proprietär ist.

MKV ist sicherlich fein, aber MP4 (ISO/IEC 14496-14) ist ein vollständig offenes, standardisiertes Format, für jeden frei zu benutzen. Technisch hat MP4 den Vorteil, die Zeitstempel für jede Spur in einer eigenen Zeitbasis auszudrücken (zum Beispiel, "30 fps" können wirklich 30 mit Zeitbasis: 1/30 sein, aber auch 29,97 mit Zeitbasis 1001/30000), somit sind sie exakt und nicht ein Rundungswert (auf Millisekunde genau) wie bei MKV.

eumagga0x2a schrieb:

MKV ist sicherlich fein, aber MP4 (ISO/IEC 14496-14) ist ein vollständig offenes, standardisiertes Format, für jeden frei zu benutzen.

Stimmt schon, aber das Problem dabei ist imho, dass MP4 (als Teil vn MPEG-4) „im Einflußbereich“ der MPEG ist. Und DIe MPEG will ihr proprietäres Zeug verbreiten,dass so viele wie möglich Abgaben abdrücken müssen. Für digitale Medien wie Audio, Bilder, Video ist das aber gar nicht mehr nötig und nur sinnlose Wegelagerei. MP4 bedeutet fast ausschließlich, dass sich darin proprietäres Zeug befindet und software, die das Format benutzt oder besser gesagt generiert, da auch diesen proprietären Kram bevorzugt reindrückt. Sicherlich, das kann man auch in MKV reinsetzen (beispielsweise ist oft H.264 oder H.265 drin). Aber grundsätzlich ist „die MKV-Welt“ frei angelegt, halt nach dem Gemüt „machts rein, was ihr wollt, its free“. Bei MP4 ists eher gefühlt so „In MP4 kommt MPEG-Zeug. Da kann vlt. zwar auch mal was anderes rein, aber wir empfehlen es nicht. Nutzt unsere codecs, dann ist alles schön zusammen von uns.“ Und ich weiß nicht, wer Linux nutzt, der müsste eigentlich eine Tendenz zur freien Option aaufweisen. Oder nicht? 😉

Technisch hat MP4 den Vorteil, die Zeitstempel für jede Spur in einer eigenen Zeitbasis auszudrücken (zum Beispiel, "30 fps" können wirklich 30 mit Zeitbasis: 1/30 sein, aber auch 29,97 mit Zeitbasis 1001/30000), somit sind sie exakt und nicht ein Rundungswert (auf Millisekunde genau) wie bei MKV.

Stimmt nicht ganz. Die Millisekunde ist der default-Wert bei MKV. Man kann ihn auch ändern. MKV kann bis auf die Nanosekunde genau sein. Bei Videos mit Ton ist das aber im Alltagsfall nicht nötig.

shinichi schrieb:

eumagga0x2a schrieb:

MKV ist sicherlich fein, aber MP4 (ISO/IEC 14496-14) ist ein vollständig offenes, standardisiertes Format, für jeden frei zu benutzen.

Stimmt schon, aber das Problem dabei ist imho, dass MP4 (als Teil vn MPEG-4) „im Einflußbereich“ der MPEG ist. Und DIe MPEG will ihr proprietäres Zeug verbreiten,dass so viele wie möglich Abgaben abdrücken müssen.

Ob ein Format gut oder schlecht ist, entscheiden IMHO seine Spezifikationen und Lizenzbedingungen, nicht politische und wirtschaftliche Verbindungen der dahinter stehenden Unternehmen und Personen. Und der MP4-Container ist nun mal offen.

Die Situation bei Codecs ist anders, das erkennt man schon am weitgehenden Scheitern von HEVC durch unbefriedigende Lizenzbedingungen. Möglicherweise war HEVC bereits der Ruin für MPEG. Hoffentlich gelingt mit AV1 ein Durchbruch, immerhin sind die größten Vertreter der Industrie mit am Bord in AOMedia. Ach ja, man kann AV1 mit Vorbis-Audio wunderbar in MP4 muxen.

Und ich weiß nicht, wer Linux nutzt, der müsste eigentlich eine Tendenz zur freien Option aaufweisen. Oder nicht? 😉

Ich verspüre kein Verlangen nach ideologischen Beschränkungen, mir genügt, dass es freie Implementierungen für Dekoder, Encoder, Demuxer und Muxer gibt (dies dürfte denjenigen, die Codecs und Formate kommerziell nutzen, nicht genügen, aber im privaten Rahmen sehe ich keinen Unterschied). Was wirklich zählt, ist der Energieverbrauch der Geräte, und hier versündigt man sich unnötig an unserer Lebensgrundlage, wenn man Codecs einsetzt, die nicht energiesparsam in Hardware dekodiert werden können.

Technisch hat MP4 den Vorteil, die Zeitstempel für jede Spur in einer eigenen Zeitbasis auszudrücken (zum Beispiel, "30 fps" können wirklich 30 mit Zeitbasis: 1/30 sein, aber auch 29,97 mit Zeitbasis 1001/30000), somit sind sie exakt und nicht ein Rundungswert (auf Millisekunde genau) wie bei MKV.

Stimmt nicht ganz. Die Millisekunde ist der default-Wert bei MKV. Man kann ihn auch ändern. MKV kann bis auf die Nanosekunde genau sein. Bei Videos mit Ton ist das aber im Alltagsfall nicht nötig.

Eine kleinere Zeiteinheit behebt nicht das grundlegende Problem, dass es keine Zeitbasis Zähler/Nenner gibt, die alle Zeitstempel eines Tracks korrekt beschreibt. Deswegen treibt zum Beispiel Avidemux im Matroska-Demuxer einen ziemlich großen Aufwand, um aus sämtlichen PTS (presentation timestamps) eines Videotracks eine geeignete Zeitbasis abzuleiten.

Last but not least: Matroska sieht DTS (decode timestamps) nicht vor. Nicht gravierend, aber unbequem, wenn der Codec mit frame reordering arbeitet.