Frage von Benjamin Gawert: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?
http://compression.ru/video/codec comparison/mpeg-4 avc h264 2007 en.html
=> 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.
Benjamin
