Ich hab hier einiges an MPEG2-Material, welches ich mittels Handbrake nach H.264 konvertieren muss. Dabei tauchte allerdings eine Frage auf, auf die ich in den Weiten des Internets bisher keine klare Antwort gefunden habe: wie hoch ist denn in etwa der "Umrechnungsfaktor" der Bitrate zw. MPEG2 und H.264? Sprich: welche Bitrate muss mein H.264-Video mindestens aufweisen, um die gleiche Qualität wie MPEG2 mit 4Mbit/s zu erreichen?
Benjamin
Antwort von Hans-Georg Michna:
On Sat, 13 Sep 2008 09:48:48 0100, Benjamin Gawert wrote:
>Ich hab hier einiges an MPEG2-Material, welches ich mittels Handbrake >nach H.264 konvertieren muss. Dabei tauchte allerdings eine Frage auf, >auf die ich in den Weiten des Internets bisher keine klare Antwort >gefunden habe: wie hoch ist denn in etwa der "Umrechnungsfaktor" der >Bitrate zw. MPEG2 und H.264? Sprich: welche Bitrate muss mein >H.264-Video mindestens aufweisen, um die gleiche Qualität wie MPEG2 mit >4Mbit/s zu erreichen?
Grob geschätzt die Hälfte bis vielleicht sogar ein Viertel, je nachdem, wieviel Qualitätseinbußen du hinnehmen willst.
Falls jemand konkrete Beispielzahlen hätte, wäre das allerdings immer noch interessant.
Am Rande bemerkt, frage ich mich aber auch, wieso du diese Frage überhaupt stellst. Wen kümmert denn noch, wie groß ein MPEG-2-Video ist? Die haben doch bestenfalls DVD-Auflösung und sind daher sowieso nicht sehr groß. Wenn ich mir die Preise der Festplatten mit 1 bis 1,5 TB so ansehe, um die 10 Cent je Gigabyte, dann dürfte das kaum noch ins Gewicht fallen, und auch die Bandbreite für Internetanschlüsse wächst von Jahr zu Jahr.
Mit anderen Worten, ich würde mir lieber Gedanken über echte Probleme machen und an dieser Stelle keinerlei weitere Qualitätseinbußen in Kauf nehmen.
Hans-Georg -- No mail, please.
Antwort von Heiko Nocon:
Benjamin Gawert wrote:
>Sprich: welche Bitrate muss mein >H.264-Video mindestens aufweisen, um die gleiche Qualität wie MPEG2 mit >4Mbit/s zu erreichen?
Das kann man so einfach nicht sagen. Zum einen hängt es stark davon ab, wie gut der H.264-Encoder ist und zum anderen von den Eigenschaften des zu encodierenden Materials selber. Der sich ergebende Wert wird irgendwo zwischen 1/2 und 1/4 der MPEG-2-Bitrate liegen.
Wobei aber bei ein- und demselben Material und jeweils gleichem Encoder wiederum zwischen der wahrgenommenen Qualität bei 1/2 und 1/4 auch schon wieder Welten liegen können.
Kurz: Es gibt keine allgemein gültige Faustformel. Wie immer bei verlustbehafteter Kompression ist der beste Wegweiser für die günstigste Bitrate für ein konkretes Material und einen konkreten Encoder die Erfahrung. Für ein optimales Ergebnis muß man sich das Material vorher anschauen, da führt kein Weg dran vorbei. Wenn man die Eigenschaften des Encoders genau kennt, kann das "Anschauen" allerdings auch eine Software erledigen, die die relevanten Eigenschaften des Materials objektiv mißt.
Am besten kennt allerdings die Eigenschaften des Encoders der Encoder selbst. Deswegen ist die mit Abstand sinnvollste Methode, ihm keine Bitrate vorzugeben, sondern eine Zielqualität. Er benutzt dann einfach die Bitrate, die er benötigt, um diese Zielqualität zu erreichen.
Antwort von Dennis Reinhardt:
Heiko Nocon schrieb:
> Am besten kennt allerdings die Eigenschaften des Encoders der Encoder > selbst. Deswegen ist die mit Abstand sinnvollste Methode, ihm keine > Bitrate vorzugeben, sondern eine Zielqualität. Er benutzt dann einfach > die Bitrate, die er benötigt, um diese Zielqualität zu erreichen.
Was nimmt der Encoder da als Qualitätsmaß? Pixelwischiwaschi vor/nach dem Encoden des einzelnen Frames?
Antwort von Heiko Nocon:
Dennis Reinhardt wrote:
>Was nimmt der Encoder da als Qualitätsmaß? Pixelwischiwaschi vor/nach >dem Encoden des einzelnen Frames?
Nein.
Stark vereinfacht: Es gibt bei der qualitätsbasierten Kompression keinerlei Vorher/Nachher-Vergleiche. Das Qualitätsmaß wird im Wesentlichen dadurch bestimmt, daß der maximal zulässige Informationsverlust für den primären Weglass-Algorithmus (;die sog. Quantifizierung) fest vorgegeben wird.
In Wirklichkeit ist es etwas komplizierter, denn zumindest bei der temporalen Kompression spielen Vorher/Nachher-Vergleiche doch eine Rolle. Das allerdings unabhängig davon, ob qualitätsbasiert encodiert wird oder nicht.
Antwort von Dennis Reinhardt:
Heiko Nocon schrieb:
> Nein. > > Stark vereinfacht: Es gibt bei der qualitätsbasierten Kompression > keinerlei Vorher/Nachher-Vergleiche. Das Qualitätsmaß wird im > Wesentlichen dadurch bestimmt, daß der maximal zulässige > Informationsverlust für den primären Weglass-Algorithmus (;die sog. > Quantifizierung) fest vorgegeben wird. > > In Wirklichkeit ist es etwas komplizierter, denn zumindest bei der > temporalen Kompression spielen Vorher/Nachher-Vergleiche doch eine > Rolle. Das allerdings unabhängig davon, ob qualitätsbasiert encodiert > wird oder nicht. >
Ah, daher für wichtiges Material stell ich den Regler einfach in die Ecke mit der maximalen Qualität und gut is?! :)
Mich würde mal interessieren inwiefern Mainconcept H.264 Pro und x264 sich unterscheiden, so qualitätsmäßig. Gabs da schon in den (;Print-?)Medien Tests zu?
Gruß, Dennis
Antwort von Benjamin Spitschan:
Dennis Reinhardt schrieb: > Mich würde mal interessieren inwiefern Mainconcept H.264 Pro und x264 > sich unterscheiden, so qualitätsmäßig. Gabs da schon in den > (;Print-?)Medien Tests zu?
=> Mainconcept liegt ist etwas schneller und liegt qualitiv im Mittel ganz leicht vorne.
Grüße, Benjamin
Antwort von Dennis Reinhardt:
Marcus Jodorf schrieb:
> Für SD Video kann das noch funktionieren. Aber falls Du bei HD Material > alle Parameter in Sachen Qualität an den Anschlag drehst, dauert nicht > nur das Kodieren absolut ewig, sondern Du produzierst dann u.U. auch > Material, das selbst sehr schnelle aktuelle Rechner kaum noch flüssig > abspielen können.
Ja, das kann gut sein. Selbst schon erlebt. Aber ich denke, genau dafür/dagegen haben die Codecs die Systemprofile?
Mein bisheriges Material ist auch noch SD (;von MiniDV). Alleine für das Kopieren aller Bänder wird wohl die eine 500GB HD nicht ausreichen. :) Was viel mehr nervt, ist das Warten... Echtzeitkopieren ist blöd. Will endlich eine FullHD-Cam mit optischen Bildstabilisator, HD und/oder Flashkarte und Filtergewinde. :)
> Mit h.264 kann man halt beim Encoden momentan auch den schnellsten > Rechner noch in eine Schnecke verwandeln.
Unterstützen die Codecs mitlerweile eigentlich Quadcores? Evtl. steht da für mich demnächst nämlich ein AMD Phenom oder was passendes ins Haus sofern sich das lohnt. Für den Fall der Fälle das die im 64Bit Modus nochmal nen Zacken schneller arbeiten, überleg ich auch ein WinXPx64 zu nehmen.
> Nebenbei, falls es wirklich maximale Qualität sein soll: x264 kann auch > lossless. Dann sind die Ergebnissdateien aber nat. auch entsprechend > sehr viel größer.
Das ist aber noch kleiner als RGB24, oder? Wenn das nicht zufällig an die Dateigrößen von MiniDV (;daher so 25Mbit/Sek) rankommt ist das eher unpraktisch.
> Mainconcept und x264 liegen etwa gleich auf und gehören zu den besseren > Codecs. Beide sind relativ schnell und beide schaffen sehr gute > Qualität. > Unterm Strich ist da der x264 vielleicht in einigen Bereichen (;Video und > speziell HD in maximaler Qualität) auch noch minimal besser. > > Wenn man natürlich den Anschaffungswiderstand (;aka Preis) noch mit > einkalkuliert, dann ist das Ergebnis IMHO absolut glasklar. > > Der letzte alljährliche Qualitätstest der Moscow State University: > > http://compression.ru/video/codec comparison/pdf/msu mpeg 4 avc h264 codec comparison 2007 eng.pdf
Sei bedankt, sowas hab ich gesucht. Na, da bleib ich mal beim x264. :)
Gruß, Dennis
Antwort von Benjamin Spitschan:
Marcus Jodorf schrieb: >> Ah, daher für wichtiges Material stell ich den Regler einfach in die >> Ecke mit der maximalen Qualität und gut is?! :) > > Für SD Video kann das noch funktionieren. Aber falls Du bei HD Material > alle Parameter in Sachen Qualität an den Anschlag drehst, dauert nicht > nur das Kodieren absolut ewig, sondern Du produzierst dann u.U. auch > Material, das selbst sehr schnelle aktuelle Rechner kaum noch flüssig > abspielen können.
Kurze Frage: Was ist da der begrenzende Faktor? IMHO nicht die Rechenleistung, sondern die zuliefernde Festplatte und der Durchsatz auf dem Systembus sowie die ganze Kopierei im RAM, oder? Die Prozessorlast dürfte doch relativ konstant sein, oder irre ich? Oder sogar bei niedrigen Datenraten noch ansteigen, weil mehr Bewegungskompensation gemacht werden muß.
Grüße, Benjamin
Antwort von Jens Semmler:
Dennis Reinhardt schreibte:
>> Mit h.264 kann man halt beim Encoden momentan auch den schnellsten >> Rechner noch in eine Schnecke verwandeln. > > Unterstützen die Codecs mitlerweile eigentlich Quadcores? Evtl. steht da > für mich demnächst nämlich ein AMD Phenom oder was passendes ins Haus
XviD läuft hier auf einem Phenom 4x2,2GHz mit ca. 50% Prozessorlast (;4Threads). X.264 dagegen mit 100%. DV-Material wird schneller als in Echtzeit codiert (;mit den Grundeinstellungen von x.264) und ist damit schneller als XviD fertig.
Gruß, Jens
Antwort von Andreas Erber:
Benjamin Spitschan wrote:
> > Kurze Frage: Was ist da der begrenzende Faktor? IMHO nicht die > Rechenleistung, sondern die zuliefernde Festplatte und der Durchsatz > auf dem Systembus sowie die ganze Kopierei im RAM, oder?
Bestimmt nicht. Festplatten schaffen ~100 Mbyte/sec und RAM mehrere Gigabyte/Sec.
> Die > Prozessorlast dürfte doch relativ konstant sein, oder irre ich? Oder > sogar bei niedrigen Datenraten noch ansteigen, weil mehr > Bewegungskompensation gemacht werden muß.
Wo mehr Details drinstecken muß man auch mehr Details auspacken und darstellen.
LG Andy
Antwort von Benjamin Gawert:
* Hans-Georg Michna: > Grob geschätzt die Hälfte bis vielleicht sogar ein Viertel, je > nachdem, wieviel Qualitätseinbußen du hinnehmen willst.
Einbussen will ich eigentlich keine hinnehmen. Bisher hab ich die Bitrate auf etwa 50-65% der originalen MPEG2-Bitrate gesetzt. Das scheint also garnicht so schlecht geschätzt.
> Am Rande bemerkt, frage ich mich aber auch, wieso du diese Frage > überhaupt stellst. Wen kümmert denn noch, wie groß ein > MPEG-2-Video ist? Die haben doch bestenfalls DVD-Auflösung und > sind daher sowieso nicht sehr groß.
Weil die Videos auf eine 2.5"-Platte passen müssen, und da wird es mit MPEG2 schon eng.
