Leserartikel Videos platzsparend konvertieren

habichtfreak

Captain
Registriert
Aug. 2006
Beiträge
3.542
Videos platzsparend konvertieren
Eine Schritt-für-Schritt Anleitung​


Immer wieder taucht – auch im Forum von Computerbase - die Frage auf, wie man eine beliebige Videodatei konvertieren kann. Sei es, weil das Endgerät das derzeitige Dateiformat nicht versteht, oder einfach weil man Platz sparen möchte. Gerne wird diese Frage mit „DVD-Rippen“ in einem Topf geworfen, was nach dem geltenden Recht der meisten Länder verboten ist. Entsprechend wertet ihr hier auch keine Infos darüber finden, wie ihr einen Kopierschutz umgehen könnt. Wenn ihr jedoch eine Videodatei bereits auf eurer Festplatte habt, die ihr konvertieren (umwandeln) wollt, dann findet ihr hier eine möglich Lösung für euer Problem (viele Wege führen bekanntlich nach Rom).

1. Grundlagen

Bevor es losgeht, hier ein paar Grundlagen, die zum besseren Verständnis der späteren Einstellungen dienen sollen:​
Container:
Als Container bezeichnet man bei Videodateien den Dateityp, also beispielsweise .avi, .flv, .mp4, .mkv, .vob, .mpg und viele andere. Mit dem Dateityp kann man aber nicht immer Rückschlüsse daraus ziehen, was sich tatsächlich in dem jeweiligen Container befindet. Manche Container können nur bestimmte Codecs enthalten (z.B. VOB nur MPEG-1 oder MPEG-2), andere sind sehr kompatibel und können fast alle Formate beinhalten (z.B. Matroska).​
Codec:
Der Codec ist der Name des Verfahrens, wie der Inhalt (Audio oder Video) komprimiert wurde. Mediadateien werden grundsätzlich komprimiert gespeichert, da unkomprimiertes Speichern enormen Speicherplatz benötigen würde. Beispiels:​
Audio: MP3, AAC, FLAC, AC3​
Video: siehe Liste bei Wikipedia: https://de.wikipedia.org/wiki/Liste_der_Videocodecs
Aufbau einer Videodatei:
In Zeiten bevor es hochauflösendes Material gab, waren der DivX bzw. der Open-Source Pentant XviD die bekanntesten Vertreter im privaten Bereich. Als Container diente zumeist der Audio Video Interleave (.AVI). Mit dem Aufkommen von hochauflösendem Material stiegen die Bitraten und damit auch die Dateigrößen weiter an, was die Entwicklung effizienterer Komprimierungsverfahren vorantrieb. Der bekannteste Codec der aus dieser Entwicklung hervor ging, ist H.264. Er ist auch unter weiteren Namen wie MPEG-4/AVC oder MPEG-4/Part 10 bekannt. Sein Nachfolger wird der H.265 bzw. HEVC Codec sein, der heutzutage von den meisten Endgeräten noch nicht unterstützt wird.​
container-png.582079
Vollbilder und Halbbilder:
Vollbilder:​
Heutzutage werden die einzelnen Bilder, aus denen eine Videodatei besteht, als Ganzes abgespeichert, sogenannte Vollbilder (engl. progressive).​
Halbbilder:​
Jede Datenübertragung erfordert eine bestimmte Bandbreite. Videos erkennt das menschliche Auge als flüssig, wenn mehr als 25 einzelne Bilder pro Sekunde zu sehen sind. Um so wenig wie möglich Bilder übertragen zu müssen, und damit Bandbreite zu sparen, hat man sich eines Tricks bedient, dem Zeilensprungverfahren (eng. interlace). Hierbei wird das einzelne Bild zerlegt, in so viele Streifen wie es Pixel in der Höhe hat. Diese Pixelreihen werden durchnummeriert und im ersten gesendeten Bild sind nur die ungeraden Zeilen enthalten. Dieses Halbbild baut der Bildschirm komplett auf (jede zweite Zeile fehlt) und anschließend das Bild mit den geraden Zeilennummern. Da dieser Bildaufbau zu oft für das menschliche Auge geschieht, sehen wir die Bilder nicht unvollständig, sondern als Ganzes.​
Auch wem Voll- bzw. Halbbilder bisher nicht geläufig waren, wir sehen sie jedem Tag. Schaltet mal den Fernseher ein, findet man neben den Infos zur laufenden Sendung auch die Information über die empfangene Auflösung. Da könnte 1080p, 1080i, 720p oder 576i stehen. Die Zahl bezeichnet die Auflösung, und der Buchstabe dahinter die Art der Bilder. „i“ steht für interlace, also Halbbilder, „p“ für progressive (Vollbilder)​
Warum ist es nun wichtig, sich damit auseinander zu setzen? Hat man beispielsweise Aufnahmen von alten DV-Camcorder oder ähnlichen Geräten, dann liegt das Quellmaterial in Halbbildern vor. Das Ziel sollten jedoch Vollbilder sein. Ohne entsprechende Einstellungen vorzunehmen entsteht ein solch verschobenes Bild:​
interlace1-png.582058

Interlace (nicht korrigiert)​

Vielleicht habt ihr selbst auch schon mal Videodateien gesehen, bei denen jede zweite Zeile verschoben ist. Hier hat derjenige der die Datei erzeugt hat, genau das nicht berücksichtigt. Die bekannten PC-Media-Player können das zwar korrigieren, jedoch ist es mühselig die entsprechenden Einstellungen vorzunehmen, da es verschiedene Arten der Verschiebung gibt. Endgeräte wie Fernseher bieten gar keine Möglichkeit das Bild im Nachgang zu korrigieren. Deshalb sollte man die Verschiebung korrigieren und die Datei neu erstellen. Das Ergebnis schaut sich sehr viel angenehmer:​
interlace2-png.582059

Interlace (korrigiert):​

Encoder und Decoder:
Ein Codec besteht immer aus einem Encoder und einem Decoder. Der Encoder (auch Kodierer genannt), wandelt das Quellmaterial nach einem vorgeschriebenen Kodierverfahren um. Dieser Vorgang geschieht nur einmalig beim Umwandeln eines Videos und erfordert viel Rechenkraft. Wird das Video abgespielt, kommt der Decoder zum Einsatz, der die kodierte Datei entschlüsselt und in ihr ursprüngliches Format zurückkonvertiert. Der bekannteste Encoder für H.264 ist der X.264, welcher im späteren Beispiel auch zum Einsatz kommt.​
Die Aufgabe des decodieren übernimmt am PC der Prozessor (CPU). Allerdings ist dieser denkbar ungeeignet für diese Aufgabe, weshalb in den meisten Geräten spezielle Decoder verbaut sind. Diese verstecken sich meist in der Grafikeinheit. AMD nennt es beispielsweise UVD (Unified Video Decoder). Welche Decoder genau verbaut sind und welchen Codec sie beschleunigen können hängt von der verbauten Version des Decoders ab.​
uvd-jpg.582060

Wie wichtig ein Decoder ist, veranschaulicht der nachfolgende Vergleich. Auf einem Intel Core i5-4590 wurde der 4k Trailer „Der Hobbit“ mit und ohne Decoder abgespielt:​
decoder-vergleich-png.582061

Video: 4096 x 2304 @ 13,9 MBit/s // Audio: 2 Kanal @ 147 kBit/s​


2. Wie konvertiere ich richtig

Warum ihr euer Video umwandeln wollt, kann verschiedene Gründe habe:​
  • Bisheriges Dateiformat wird vom Endgerät nicht unterstützt
  • Datei unnötig groß
  • Zu hohe Auflösung (kann vom Endgerät nicht abgespielt werden)
Sofern man sehr altes Quellmaterial besitzt, kann es sein, dass die schwarzen Ränder (oben und unten) Bestandteil der Videodatei sind. Das wurde damals bewusst so gemacht, um ein Seitenverhältnis von 4:3 zu erzeugen. Zum einen lassen sich derartige Videos auf heutigen 16:9 Geräten nicht bildschirmfüllend darstellen, zum anderen verbrauchen die gespeicherten schwarzen Flächen unnötig Speicherplatz. Dieses Problem lässt sich beim Konvertieren ebenfalls beheben​
Umwandeln ist immer mit Qualitätsverlust verbunden
Über diesen Satz ist jeder schon mal gestolpert, denn er ist immer gültig. Aber: Er hat heutzutage auch an Gewicht verloren. Die früheren Codecs wie DivX oder Xvid waren bei weitem nicht so leistungsstark wie der H.264. Zum anderen spielt auch das Verfahren eine wichtige Rolle, wie umgewandelt wird. Man unterscheidet zwischen 2-Pass (früher gebräuchlich) und One-Pass (heute Maß der Dinge).​
Beim 2-Pass Verfahren wird im ersten Durchlauf (Pass 1) das Quellmaterial analysiert, um herauszufinden wie die zur Verfügung stehende Bitrate möglichst effizient aufgeteilt werden kann. Erst im zweiten Durchlauf (Pass 2) findet die eigentliche Umwandlung statt. Da dem Encoder vor Beginn seiner Arbeit die zu erreichende Bitrate vom User vorgegeben wird, kann er nur in begrenztem Rahmen die Bitrate anpassen. Insbesondere beim Wechsel von Szenen, sind Fehler in der Darstellung mit bloßem Auge zu erkennen, sogenannte Kompressionsartefakte.​
kompressionsartefakte-jpg.582063

Beim One-Pass Verfahren wird dem Encoder keine feste Bitrate vorgegeben, die zu erreichen ist, sondern eine bestimmte Qualität. Diese steht, je nach verwendetem Programm, als CQ (Constant Quality) oder CRF (Constant Rate Factor) in den Einstellungen zur Auswahl. Theoretisch sind alle Stufen zwischen 0 bis 51 (in 1er-Schritten) möglich. Die meisten Programme beschränken sich aber auf den Bereich zwischen 16-24.​
Bedeutung dieser Scala:​
  • 0: Bestmögliche Qualität (extrem große Datei)
  • 51: Kleinstmögliche Datei (extrem schlechte Qualität)

vergleich-crf-png.582065

Je höher der CRF gewählt wird, je schneller geht das Umwandeln und die Bitrate des Videos sinkt. Die im Diagramm angegebenen Werte sind Beispielwerte und dienen zu Verdeutlichung des Zusammenhangs der einzelnen CRF-Stufen. CRF 22 führt ungefähr zur halben Dateigröße (exkl. Audio) im Vergleich zu CRF 18. Das ist immer so, egal welche Auflösung das Video hat.​
Welche sichtbare Qualität mit den einzelnen Werten erreicht wird, lässt sich an dieser Stelle nicht feststellen. Hier bleiben nur zwei Möglichkeiten: Man verlässt sich auf die Erfahrung anderer, oder man legt selbst eine Messreihe an. D.h. ein Video wird mit unterschiedlichen Stufen verarbeitet. Am Ende hat man mehrere Videodateien und sucht sich einen beliebigen Frame (Einzelbild). Diesen speichert man je Stufe einmal ab und vergleicht die sichtbare Qualität.​
Rein Subjektiv betrachtet, kann ich euch folgende Erfahrungswerte mit auf den Weg geben:​
  • 16: Unnötig aufgeblähte Dateigröße ohne Mehrwert
  • 18: Kein Unterschied zum Original zu sehen
  • 20: gelegentlich, minimale Unterschiede erkennbar
  • 22: Sichtbar schlechter als Original

Hier mal ein Beispielframe (aus: „Appleseed Alpha“) dessen Videobitrate ursprünglich 5610 kBit/s betrug. Nach der Umwandlung mit CRF 20 (ohne Änderung der Auslösung) betrug sie nur noch 2350 kBit/s. Die Bitrate wurde also um 58% gesenkt.​
Da das Forum leider nicht die Möglichkeit bietet, zwei Bilder zu vergleichen, greife ich an dieser Stelle auf auf einem externen Dienst zurück. Schaut euch die beiden Bilder an und vergleicht selbst.
Die offensichtlichste Änderung ist das Verschwinden des Grauschleiers, was die Qualität der Zieldatei subjektiv besser wirken lässt. Wie man diese (un-)beabsichtigten Änderungen vornimmt, soll aber hier und heute nicht Bestandteil sein.​
Je nachdem wie gut die eigenen Augen sind, kann man einzelne Pixel am Helm ausmachen, die durch das Umwandeln verändert wurden. Wenn man – bei den eigenen Versuchen – nur geringe oder keine Unterschiede sehen kann, dann hat man alles richtig gemacht. Denn die Kunst beim Konvertieren besteht darin, die Veränderungen so gering wie möglich zu halten, und trotzdem signifikant Bitrate zu sparen.​
Zusammenhang von Auflösung und Bitrate
Glaubt man der landläufigen Meinung, dann ist eine höhere Auflösung immer mit besserer Qualität verbunden. Diese Aussage gilt beim Konvertieren nicht, denn entscheidend für die Qualität ist in erster Linie die Bitrate. Je höher diese ist, je mehr Informationen können gespeichert werden. Erst wenn die Bitrate so hoch gewählt wird, dass die zur Verfügung stehende Auflösung keine zusätzlichen Details darstellen kann, wirkt sich eine höhere Auflösung positiv auf die Qualität aus. Beim Umwandeln eines Videos macht es jedoch keinen Sinn die Auflösung zu erhöhen, denn mehr Details als in der Ursprungsdatei, können auch nicht in der Zieldatei vorhanden sein. Egal ob man die Auflösung beibehält, oder sie verringert (wie im späteren Beispiel), das Ziel ist die bestmögliche Qualität, was nicht immer durch eine höhere Auflösung erreicht wird.​
bitrate-aufloesung2-jpg.582067

Trotz zehnmal höherer Auflösung (bei gleicher Bitrate) ist die Qualität deutlich schlechter. Wer also mit Videomaterial arbeitet, muss den Spagat aus beiden Parametern hinbekommen um das bestmögliche Ergebnis zu erzielen. Hier spielt die Erfahrung eine entscheidende Rolle, denn feste Bitraten-Werte für bestimmte Auflösungen gibt es nicht. Aber: Dank des Constant Rate Factors (CRF), übernimmt der Encoder den Großteil diese Aufgabe.​

3. Theorie trifft Praxis

Nach jeder Menge Theorie, kommen wir nun zur Praxis. Ich verwende seit Jahren das Tool „RipBot264“. Der Name erweckt vielleicht den Anschein, dass man mit diesem Tool sogenannte DVD-Rips anfertigen kann, also das umgehen eines Kopierschutzes. Nein, das kann das Tool nicht. RipBot ist vielmehr eine GUI (graphische Benutzeroberfläche), die das Arbeiten dank Schaltflächen vereinfacht. Versierte User wissen, mit einer Batchdatei und dem entsprechenden Know-How lässt sich die Aufgabe auch ganz ohne zusätzliches Tool erledigen.​
RipBot einrichten
Beim ersten Start, wird RipBot vermutlich nicht Starten und stattdessen erscheint dieses Fenster:​
rb1-png.582068

Klickt auf den jeweiligen Link, installiert die fehlenden Komponenten und startet RipBot erneut. Hat alles geklappt, erscheint dieses Fenster:​
rb2-png.582069

Einen Job erstellen
Jobs sind in RipBot die Aufgaben die zu erledigen sind. Die Jobliste seht ihr im Hauptfenster, zu Beginn ist sie natürlich leer. Um einen neuen Job zu erstellen, klickt auf die Schaltfläche „Add“. Es öffnet sich ein neues Fenster in dem ihr die zu konvertierende Datei auswählen müsst. Anschließend erscheint das „New Job“ Fenster. Alle Felder sind leer, alle Funktionen ausgegraut.​
rb3-png.582070

In der linken unteren Ecke seht ihr die Meldung „Demuxing audio streams …“. Ripbot zerlegt jetzt die ausgewählte Datei in den Audio- und Videostream. Diese Dateien werden standardmäßig im Temp-Ordner unter C: zwischengespeichert. Wer hohes Schreibaufkommen auf seiner SSD vermeiden will, kann ich den Einstellungen einen anderen Ordner festlegen.​
Bekannter Fehler: Enthält der Dateiname der eingelesenen Datei Zeichen die Ripbot nicht verarbeiten kann, geht das demuxen sehr schnell und endet meinst mit der Anzeige [No Audio].​
no-audio-png.582076

In diesem Fall trat ein Fehler auf, welcher meist auf Umlaute (Ä/ä, Ü/ü, Ö/ö) im Dateinamen zurückzuführen ist. Benennt die Datei um und versucht es erneut. Enthält eure Datei tatsächlich keine Audiospur, ist dies natürlich nicht als Fehler zu interpretieren. Ist das Zerlegen (demuxen) abgeschlossen, füllen sich die Felder und die Schaltflächen können bedient werden.​
rb4-png.582071

Jetzt kommt es drauf an, warum ihr das Video konvertieren wollt. Entsprechend sind unterschiedliche Einstellungen für euch wichtig. Die erste Zeile zeigt euch die erkannte Video- bzw. Audiospur. Das eingelesene Video hat bereits das Format H.264 und AAC-Audio.​
Profile (Video): Hier könnt ihr aus einer Liste von Profilen wählen, um Dateien zu erzeugen, die auf bestimmten Endgeräten abgespielt werden können. Ist die Kompatibilität mit einem bestimmten Endgerät für euch nicht wichtig, wählt das Standardprofil [High 4.1] DEFAULT . DEFAULT​
Profile (Audio): Da die Tonspur in den meinen Fällen bereits in einem gängigen Format vorliegt (AAC, MP3, AC3), dass jedes moderne Endgerät beherrscht, kann hier die Einstellung „COPY STREAM“ gewählt werden. Damit bleibt die Tonspur unverändert erhalten.​
Mode und CRF: Diese Einstellung hab ich bereits eingangs beleuchtet.​
Properties (neues Fenster)​
Crop: Mit dieser Funktion könnt ihr manuell oder automatisch schwarze Ränder am Bildschirmrand entfernen​
Size:​
Hier kann die Auflösung der Zieldatei angepasst werden. Alle vordefinierten Auflösungen haben das Seitenverhältnis 16:9. Sofern die Quelle ein anderes Seitenverhältnis hat, wählt die Einstellung „Custom“. Jetzt könnt ihr eine beliebige Breite wählen. Die Höhe wird anhand des erkannten Seitenverhältnisses automatisch berechnet. Klickt auf „Preview Script“ um zu überprüfen, ob die getroffenen Einstellungen zum gewollten Ergebnis führen. Vergleicht das Seitenverhältnis mit der Originaldatei, falls ihr euch nicht sicher seid.​
Deinterlace:​
Sofern die Quelldatei aus Halbbildern besteht (oder verschobenen Vollbildern), müsst ihr hier eine Auswahl treffen. Welche in eurem Fall die Richtige ist, bekommt ihr nur durch probieren heraus (mit der Vorschau „Preview Script“ erkennt ihr sofort ob die Verschiebung korrigiert wurde oder nicht)​
  • TFF (Top Field First): für Aufnahmen von DV-Camcordern
  • BFF (Bottom Field First): Für TV-Aufnahmen
Alle weiteren, hier nicht angesprochenen Einstellungen unter Properties sind im privaten Umfeld nicht von Interesse. Mit einem Klick auf OK werden die getroffenen Einstellungen für diesen einen Job übernommen.​
rb5-png.582072

Beispieleinstellungen: schwarze Balken werden entfernt (294/292) und die Auflösung auf 720p geändert​

Ihr landet anschließend im vorherigen Job-Fenster. Wählt zum Schluss das Ausgabeverzeichnis und einen Dateinamen. Ob ihr euch für MKV oder MP4 entscheidet, hängt vom Endgerät ab. Mit „DONE“ übernehmt ihr den Job in die Warteschleife.​
rb6-png.582073

Zu guter Letzt den Job starten und warten bis die Aufgabe erledigt ist. Überprüft die neue Datei, ob das Seitenverhältnis stimmt und der Ton synchron ist. Entspricht das Ergebnis euren Erwartungen, entfernt den Job aus der Liste mit „Remove“. In diesem Augenblick werden auch die temporären Dateien dieses Jobs von der Festplatte entfernt.​

4. Schlusswort
Wie man anhand der Bilder sehen kann, habe ich in diesem Beispiel den UHD-Trailer zum Film „Der Hobbit“ konvertiert. Dieser lässt sich auf einem FullHD Fernseher nicht abspielen. Es erscheint die etwas verwirrende Meldung „Diese Videodatei wird nicht unterstützt“. Sowohl das Dateiformat als auch die enthaltenen Codecs unterstützt der Fernseher, aber er ist nicht in der Lage Videos abzuspielen, deren Auflösung höher ist als seine eigene. Dieses Problem trifft man ebenfalls bei 3D-Videomaterial an, bei dem zwei FullHD-Einzelbilder nebeneinander (Side-by-Side) oder übereinander (over-under) angeordnet sind.​
 

Anhänge

  • container.PNG
    container.PNG
    10,8 KB · Aufrufe: 1.288
  • interlace1.png
    interlace1.png
    233,4 KB · Aufrufe: 11.028
  • interlace2.png
    interlace2.png
    207,5 KB · Aufrufe: 11.004
  • uvd.jpg
    uvd.jpg
    215,7 KB · Aufrufe: 10.967
  • decoder-vergleich.png
    decoder-vergleich.png
    21,4 KB · Aufrufe: 10.930
  • kompressionsartefakte.jpg
    kompressionsartefakte.jpg
    285,9 KB · Aufrufe: 10.717
  • vergleich-crf.png
    vergleich-crf.png
    2,1 KB · Aufrufe: 10.778
  • bitrate-auflösung2.jpg
    bitrate-auflösung2.jpg
    275,4 KB · Aufrufe: 10.819
  • rb1.PNG
    rb1.PNG
    41,1 KB · Aufrufe: 10.759
  • rb2.PNG
    rb2.PNG
    35 KB · Aufrufe: 10.611
  • rb3.PNG
    rb3.PNG
    39,9 KB · Aufrufe: 10.718
  • rb4.PNG
    rb4.PNG
    43,9 KB · Aufrufe: 10.809
  • rb5.PNG
    rb5.PNG
    37,8 KB · Aufrufe: 10.808
  • rb6.PNG
    rb6.PNG
    30,2 KB · Aufrufe: 10.640
  • no-audio.png
    no-audio.png
    12,7 KB · Aufrufe: 10.655
  • container.PNG
    container.PNG
    7,2 KB · Aufrufe: 10.949
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Restart001, Gorasuhl, darkcrawler und 7 andere
Hallo,

danke für die super Anleitung. Also erst mal habe ich einiges erfahren was ich vorher so nicht wusste. Das hat mich in meinen Überlegungen schon mal etwas weiter gebracht! Vielen Dank dafür.

Allerdings habe ich zur Zeit das Thema HEVC (h.265) im Kopf. Testweise habe ich mal ein Videofile was ca. 25 GB groß war zu einem HEVC MKV-File umcodiert. Das Ganze habe ich mit Handbrake Standardeinstellungen gemacht:

screenshot.png

Ich war erstaunt darüber wie groß die Videodatei nach dem Umwandeln war. Jedoch dauerte das Ganze bei meiner aktuellen CPU Xeon E3-1231v3 unheimlich lange. Jetzt kam mir die Überlegung eventuell auf eine Kaby Lake CPU umzusteigen. Allerdings kann ich im Internet keine Angaben darüber finden, wieviel schneller Skylakes/Kaby Lakes mit Hardwareencodern sind.

Hat jemand dazu irgendwelche Tests, Benchmarks oder andere Berichte gefunden aus denen hervorgeht wie viele schneller so eine CPU mit Hardwareencoder für HEVC (h.265) ist?

Liebe Grüße
Jerry
 
sofern kein spezieller befehlssatz verwendet wird, kann man codieren mit rendern gleichsetzen. schau mal nach cinebench und co. ergebnissen.

Ich war erstaunt darüber wie groß die Videodatei nach dem Umwandeln war. Jedoch dauerte das Ganze bei meiner aktuellen CPU Xeon E3-1231v3 unheimlich lange.

hevc ist doch noch in der entwicklung und so gut wie kein endgerät kann das abspielen. vllt liegt es gar nicht an deiner cpu, vllt ist die installierte FFmpeg version einfach schon ziemlich alt?
 
Zuletzt bearbeitet:
Einen kleinen Fehler habe ich im Tutorial gefunden: CQ bedeutet Constant Quantizer, es wird der selbe Quantizer dauerhaft verwendet. Nicht unbedingt vorteilhaft. Bei CRF wird ein nominaler Quantizer genommen, ein Richtwert. Er schwankt um den eingestellten Wert. Deswegen kann man auch bei CRF z.B 18.4 einstellen, ansonsten sind nur ganze Zahlen erlaubt.
 
Auch von mit ein Dank für die tolle Anleitung und verständlichen Infos. Hatte zuvor eine ganze Weile mit diversen Werten (etwa Bildqualität) bei der Umwandlung experimentiert und gute Hilfen gefunden, um die Medien-Digitalisierung erfolgreich abschließen zu können.

Eine kleine Frage habe ich allerdings noch zum Abschnitt der Decodierung, was über die Grafikkarte läuft. Was wäre in dem Bereich eine brauchbare Karte, die solide / brauchbare Konvertierungsergebnisse für 1080p erzielt? Aktuell dauert es bei 1080p-Material doch recht lange (~12fps / GF 8600 GT). Gespielt wird am Rechner nicht.
 
Zuletzt bearbeitet:
M@rsupil@mi schrieb:
Eine kleine Frage habe ich allerdings noch zum Abschnitt der Decodierung, was über die Grafikkarte läuft. Was wäre in dem Bereich eine brauchbare Karte, die solide / brauchbare Konvertierungsergebnisse für 1080p erzielt? Aktuell dauert es bei 1080p-Material doch recht lange (~12fps / GF 8600 GT). Gespielt wird am Rechner nicht.

da die gf 8600 ein dinosaurier ist, bin ich mir nicht sicher, ob du decodieren meinst oder codieren (konvertieren). du hast beides geschrieben.

decodieren ist das reine abspielen von fertigem material, dass kann jede zeitgemäße IGP. wie es sich mit dem konvertieren auf der GPU verhält, da bin ich überfragt, benutze die cpu.
 
Zuletzt bearbeitet:
coole Anleitung
finde es toll, dass sich Leute mit Ahnung die Zeit nehmen und da was zusammen schreiben :)

aber eins fand ich komisch:
Mediadateien werden grundsätzlich komprimiert gespeichert, da unkomprimiertes Speichern enormen Speicherplatz benötigen würde. Beispiels:

Audio: MP3, AAC, FLAC, AC3
Video: siehe Liste bei Wikipedia: https://de.wikipedia.org/wiki/Liste_der_Videocodecs
Flac ist doch lossless, also kein Verlust in der Qualität
aber wie geht das?
dachte beim komprimieren geht unweigerlich was verloren

zuerst dachte ich FLAC wäre unkomprimiert, aber ist es ja nicht^^
 
Ja, Komprimierung finde ich auch immer faszinierend. Keine Ahnung, wie es bei FLAC unktioniert, aber eine ganz einfache, verständliche verlustfreie Komprimierung wäre:

011101100111010
0302003010

Die "0" wird wie gehabt geschrieben, die "1"en werden zusammengefasst und nur die Größe des Einserblocks gespeichert. Es gehen keine Informationen verloren, obwohl die zweite Reihe eindeutig weniger Zeichen hat.
 
Vielen Dank für die Anleitung! Sehr gelungen! Ich wolle schon die ganzen Jahre dazu mal ein wenig rumprobieren und hab das jetzt auch zum Anlass genommen es mal zu machen :)

Zum Testen hatte ich mir jetzt mal ein paar kurze Clips von hier gegoogelt (http://www.4ktv.de/testvideos/)

Da gibt es z.B. diesen Clip (Jellyfish Bitrate Test 120Mbps) , welchen ich mal für eine erste Testreihe (da kurz und klein) verwendet habe.

Kann mir jemand erklären, warum das Source-File 430 MB hat, der Output aber (ohne Einschränkung der Qualität - d.h. CQ =CRF 00, Profile "[High 4.0] FHD, Progressive", als MKV) jetzt eine Größe von 560 MB hat?

Jelly.png

Und noch ne Frage: So wie ich das sehe, verwendet das Programm die CPU (ich habe einen Xeon 1230 V3 @ Stock), kann man die GPU (bei mir ne NV 1070) auch zur Mitarbeit überreden? Oder macht das ggf. keinen Sinn?

Danke schon mal!
 
Zuletzt bearbeitet:
zur größe: 00 ist "verlustfrei". da konvertieren immer mit verlusten verbunden ist (auch wenn man sie mit dem bloßen auge nicht sieht), versucht das programm durch eine höhere bitrate dies auszugleichen. eine andere ursache könnte sein, dass das quellvideo mit 2pass konvertiert wurde. dürfte sogar wahrscheinlich sein, anders lassen sich die verschiedenen bitraten (45, 75, 90 und 120) gar nicht genau erreichen.

encoden mit gpu: ja, geht. aber nicht mit ripbot. staxrip unterstützt das. geschwindigkeitsvorteil ist riesig. beispiel: mein i5-4590 schafft 40-50fps, die igp rund 200fps. ne richtige graka dürfte 1000 und mehr schaffen. allerdings soll die qualität - insbesondere bei nvidia - sehr viel schlechter sein als mit cpu. musst du selbst entscheiden, was dir wichtiger ist (qualität oder geschwindigkeit)
 
Zuletzt bearbeitet:
x264 ist immer noch allgegenwärtig wegen der hohen Unterstützung. Verbesserungen am Codec kommen mit den entsprechenden Softwareupdates (falls verfügbar). x265 ist mMn weiterhin nicht zu gebrauchen (kein Platzersparnis, keine bessere Qualität,, nur am PC abspielbar). An Ripbot selbst hat sich nix geändert soweit ich das sehen kann.
 
Zurück
Oben