Open-Source-Videokonverter HandBrake 1.7.0

 (forum.handbrake.fr)
3 Punkte von GN⁺ 2023-11-21 | 1 Kommentare | Auf WhatsApp teilen

Hinweise zum Upgrade auf HandBrake 1.7.0

  • Vor dem Update von HandBrake sollte sichergestellt werden, dass keine Encodierungen mehr ausstehen; außerdem wird empfohlen, benutzerdefinierte Presets und die Einstellungen der App zu sichern.
  • Windows-Nutzer müssen unbedingt Microsoft .NET Desktop Runtime Version 6.0.x installieren; auch wenn .NET 7 installiert ist, ist die Installation von .NET 6 weiterhin erforderlich.

Release Notes zu HandBrake 1.7.0

  • Die vollständige Liste der Verbesserungen und Bugfixes ist in den Release Notes auf GitHub zu finden.

Fehler melden und Feedback geben

  • Wer einen reproduzierbaren Bug oder ein Problem entdeckt oder Feedback geben möchte, wird gebeten, dies über den GitHub-Issue-Tracker zu melden.
  • Kontakt ist auch über den IRC-Community-Support-Kanal möglich.
  • Die HandBrake-App wird von einem kleinen Team von Freiwilligen in ihrer Freizeit entwickelt, daher sind sofortige Antworten möglicherweise schwierig; alle Rückmeldungen werden jedoch gelesen und konstruktives Feedback ist willkommen.

Dank und Beiträge

  • Einige Funktionen dieser Veröffentlichung wurden von HandBrake-Nutzern oder Unternehmen beigesteuert; die Übersetzungen entstehen durch die aktive Beteiligung einer weltweiten Community von Freiwilligen.
  • Wer sich für Beiträge interessiert, aber noch nicht mitmacht, sollte den Leitfaden für Beiträge lesen.
  • Es gibt viele Möglichkeiten, auch ohne Entwickler zu sein, einen Beitrag zu leisten.

Meinung von GN⁺

  • Das Upgrade auf HandBrake 1.7.0 erfordert eine Sicherung benutzerdefinierter Einstellungen und die Installation der neuen .NET-Laufzeit.
  • Dieses Update enthält Verbesserungen und Bugfixes und ist ein Community-basiertes Projekt, das durch Beiträge von Nutzern und Unternehmen entstanden ist.
  • Dieser Artikel berichtet über die Veröffentlichung einer neuen Version von HandBrake, dem Open-Source-Videotranscoder, und ist interessant, weil er die Bedeutung von Zusammenarbeit und Beiträgen in der Tech-Community hervorhebt.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-21
Hacker-News-Kommentare

  • Wenn es dich stört, dass HandBrake nicht automatisch den Rest berechnet, wenn man eine endgültige Dateigröße vorgibt, ist die Berechnung selbst einfach
    Durchschnittliche Bitrate [kbps] = Zielgröße [Kilobit] ÷ Länge [Sekunden]
    Wenn man zum Beispiel eine Datei von 2 Stunden 48 Minuten auf unter 5 GB bringen will, dann sind 2 Stunden 48 Minuten 10.080 Sekunden und 5 GB sind 40.000.000 kb, also ergibt sich eine durchschnittliche Bitrate von 40.000.000 kb ÷ 10.080 s = 3.968 kbps
    Wenn das Audio 256 kbps hat, darf die durchschnittliche Video-Bitrate höchstens 3.712 kbps betragen

    • Diese Rechnung stimmt nur beim Encoding mit konstanter Bitrate
      Normalerweise kodiert man mit konstanter Qualität, und die Ausgabegröße hängt dann stark vom Eingabevideo ab
      Deshalb habe ich einen Python-Wrapper gebaut, der die Ausgabe von HandBrakeCLI parst und anhand des Fortschritts sowie der aktuellen Größe der Ausgabedatei die Endgröße schätzt
      Wenn die Datei offenbar zu groß wird oder die Ausgabequalität so schlecht ist, dass man den Qualitätsfaktor erhöhen sollte, kann man frühzeitig abbrechen

  • Es ist schön, dass die Meldung „Put that cocktail down. Your HandBrake encode is complete!“ auch nach all den Jahren noch da ist

    • Solche Details mag ich. Es fühlt sich an, als würde man den Maschinen wieder ein bisschen Seele oder so etwas wie Geister zurückgeben

  • Früher blieben in der HandBrake-Pipeline viele Filter bei 8 Bit, selbst nachdem alles auf 10 Bit umgestellt war, sodass man durch die Wahl des falschen Filters leicht unbemerkt die Kodierqualität verschlechtern konnte
    Inzwischen unterstützen die meisten, vielleicht sogar alle Filter offenbar 10 Bit
    Wegen der FDK-AAC-Lizenz konnte außerdem nicht gebündelt werden, weshalb der AAC-Codec in den Release-Versionen unterlegen war, aber inzwischen soll er nicht mehr so schlecht sein wie früher
    Ich frage mich, ob es in der aktuellen Version dieser guten App noch große Fallstricke gibt

    • Seit 1.6 unterstützen alle Filter hohe Bittiefen. Auch die Qualität des AAC-Encoders ist inzwischen ziemlich ordentlich, und unter macOS kann man Apples AAC-Encoder verwenden, daher ist das dort kein Problem
      Das Kernproblem ist jedenfalls Personalmangel. Viele wünschenswerte Features stecken noch im Feature-Himmel fest
      Aber das gilt wohl für alle Open-Source-Projekte

  • Heutzutage bitte ich ChatGPT einfach um einen ffmpeg-Terminalbefehl
    Das geht viel schneller als jede App und lässt sich genau so anpassen, wie ich es will

    • Man kann einfach auf die Datei klicken, „open with handbrake“ wählen und dann auf „convert“ drücken. Ich kann mir kaum vorstellen, wie etwas noch schneller sein soll
    • „Genau so anpassen, wie ich es will“ bedeutet in der Praxis, dass man die ffmpeg-Optionen und ihr Zusammenspiel tatsächlich versteht
      Durch Versuch und Irrtum oder das Lesen der Manpage zu gehen, ist kaum „viel schneller“, als in HandBrake ein Preset auszuwählen und Kästchen anzuklicken oder Schieberegler zu bewegen
    • ChatGPT kennt aber das Dateiformat nicht, außer man packt auch noch die ffprobe-Ausgabe in den Prompt
      Wenn die Quelle eine DVD ist, muss man außerdem Dinge wie Seitenverhältnis, Deinterlacing, Untertitelbehandlung usw. berücksichtigen
    • ffmpeg ist eigentlich das einzige Programm, auf das ich gern ein visuelles No-Code-Interface angewendet sähe
      Inzwischen ertappe ich mich dabei, bei jeder Manpage nach einer Art --chatgpt-Option ähnlich --help zu suchen
    • Schneller ist es, aber auch fehleranfälliger. Und Apps lassen sich ebenfalls nach Wunsch anpassen, also ist das in dem Punkt unentschieden

  • Die Feature-Liste gefällt mir. Besonders gespannt bin ich auf die Performance-Verbesserungen für arm64 / aarch64 / Apple Silicon, das schnellere HEVC-Decoding im aktuellen FFmpeg und den um 30 % schnelleren bwdif-Filter, die neuen SVT-AV1-Assembler-Optimierungen mit bis zu 4-facher Performance sowie die höhere Speichereffizienz und schnellere Videokonvertierung durch das Entfernen unnötiger Frame-Kopien

  • Mein einziger Kritikpunkt an HandBrakeCLI ist, dass es per stdin gepipte Eingaben nicht kodieren kann
    FFmpeg kann das, und ich dachte, HandBrake nutze intern ohnehin FFmpeg

    • HandBrake verwendet libavformat, libavcodec und libavfilter, also Teile der FFmpeg-Bibliotheken
      Trotzdem ist es eine komplett andere App. Decoder, einige Demuxer und einige Filter sind dieselben, aber die Art, wie sie zusammengesetzt werden, ist völlig anders als bei der FFmpeg-Kommandozeilen-App
    • Funktionieren benannte Pipes nicht?
      Oder vielleicht auch etwas Bash-Magie wie handbrake-cli -i <(cat video-file.mp4)
      Ich habe HandBrakeCLI nie benutzt und nur die GUI verwendet, daher weiß ich es nicht genau
    • Als ich von HandBrake erfuhr, war ich überrascht, dass es viele Komponenten selbst baut, statt einfach nur FFmpeg zu verwenden
      Natürlich nutzt es in anderen Bereichen die FFmpeg-Bibliotheken sehr umfassend
      Es ist einer der wenigen Transcoder, die nicht bloß FFmpeg-Wrapper sind, was zugleich Vor- und Nachteil ist

  • Kann mir jemand einfach erklären, warum HandBrake die Option Zieldateigröße angeblich nicht implementieren kann?
    Bei Android-Apps zur Videokomprimierung funktioniert das ziemlich gut, aber in den entsprechenden Feature-Requests auf GitHub meinte einer der Maintainer, das sei praktisch schwer umzusetzen

    • Das ist wortwörtlich eine Funktion, die alle zugrunde liegenden Encoder bereitstellen. Selbst in exotischen ffmpeg-/vapoursynth-Filterketten geht das
      Deshalb kann ich mir nicht vorstellen, warum es nicht gehen soll
      Unter Windows würde ich einfach Staxrip empfehlen: https://github.com/staxrip/staxrip
      Es gibt auch eine Linux-App auf vapoursynth-Basis, aber mir fällt der Name nicht ein
      Oder vielleicht eines der AV1an-GUIs. All diese Tools unterstützen eine Zieldateigröße und haben weit mehr Funktionen als HandBrake

  • Warum gibt es immer noch keine einfache Funktion wie „Video X auf Dateigröße Y begrenzen“?
    Ich will doch einfach nur eine 5-GB-Videodatei, aber HandBrake scheint sich eher darum zu kümmern, welches von 50 Vimeo-Presets, von denen ich nichts verstehe, relevant ist

    • Ich verstehe nicht, warum du ausgerechnet ein 5-GB-Limit willst. Liegen bei dir schubladenweise 5-GB-USB-Sticks herum, die du füllen willst?
      5 GB ist klar größer als eine CD, und wenn du nicht genau 10 Stück auf eine Blu-ray packen willst, ist es für Blu-ray auch zu klein
      So seltsam dir die Vimeo-Presets vorkommen, so seltsam wirkt dein Anwendungsfall auf den Rest der Welt

  • Außer beim Umgang mit HDR-Videos bevorzuge ich immer ffmpeg gegenüber HandBrake.
    Ich habe keinen passenden ffmpeg-Befehl gefunden, um HDR-Metadaten von der Eingabequelle in die Ausgabe zu kopieren.
    Als ich das zuletzt geprüft habe, war es nicht möglich, und man musste die Metadaten mit einem Tool wie MediaInfo manuell extrahieren und dann jeden Wert als ffmpeg-Argument übergeben.
    Weiß jemand, ob das immer noch so ist?

    • Hast du -movflags und use_metadata_tags ausprobiert?
      ffmpeg -i $input_file -movflags use_metadata_tags -crf 22 $output_file
      Quelle: https://video.stackexchange.com/a/26076
    • Ja, anscheinend muss man die Metadaten immer noch selbst extrahieren und manuell eintragen.
      Etwas ausführlicher: Es gibt zwei gängige HDR-Videostandards, Dolby Vision und HDR10. Beide benötigen separate Unterstützung innerhalb des Encoders, und das ist eher ein Thema von libx265 als von libavformat/ffmpeg.
      Zum Glück kann man, wenn das Quellvideo HDR10 ist, die global unveränderte Übertragungsfunktion und das Tone Mapping extrahieren und direkt auf die Ausgabe-Metadaten anwenden. FFmpeg kann diese Werte an den Encoder weiterreichen, kopiert sie aber nicht standardmäßig von der Quelle ins Ziel.
      Eine Erklärung dazu gibt es unter https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...
      Ich habe schon einmal ein als HDR10 kodiertes Video in ein anderes Format reenkodiert und dabei die Metadaten beibehalten; der endgültige Befehl, der noch in meiner Shell-Historie stand, sah ungefähr so aus: ffmpeg -i Movie-with-HDR.mkv -c:v libx265 -map_metadata:s:0 0:s:0 -map_metadata:g:0 0 -x265-params crf=21:master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)":max-cll=1000,240 Movie-output.mkv
      Die Einstellungen master-display und max-cll waren dabei Farb-Übertragungsfunktionen, die ich mit einem anderen Tool aus dem ersten Video extrahieren musste. Diese Einstellungen sind in der libx265-Parameterdokumentation beschrieben: https://x265.readthedocs.io/en/master/cli.html
      Dolby Vision ist schwieriger. Die Metadaten sind dynamisch, daher bin ich nicht sicher, wie man sie aus der Quelle holen kann, aber man kann sie über Kommandozeilenargumente an libx265 übergeben. Leider ist das nur über die Kommandozeile verfügbar und nicht über die API, daher kann ffmpeg das derzeit noch nicht stellvertretend übernehmen.
      Als weiterführende Referenz zum Extrahieren der Übertragungsfunktion und zum Übergeben an ffmpeg siehe https://medium.com/@yllanos/how-to-encode-a-4k-hdr-movie-usi... und https://codecalamity.com/encoding-uhd-4k-hdr10-videos-with-f...; ein Beitrag, in dem mehrere Leute dieselbe Aufgabe aufarbeiten, ist https://www.reddit.com/r/ffmpeg/comments/g3uucr/how_do_i_enc...
      Für die Umwandlung von Dolby Vision nach HDR10 sowie Inhalte zu HLG und PQ siehe https://www.reddit.com/r/ffmpeg/comments/nkxbay/how_to_conve...; zu den Feinheiten von Dolby Vision siehe https://www.reddit.com/r/ffmpeg/comments/a32yv4/deleted_by_u...

  • Die Release-Seite selbst wäre wohl der bessere Link gewesen.
    Dort steht das Changelog, das die meisten wahrscheinlich sehen wollen.
    https://github.com/HandBrake/HandBrake/releases/tag/1.7.0