Hier wird immer von der Bildqualität geredet. Man muss schon ganz,
ganz, ganz genau hinschauen, um hier gravierende Unterschiede zu
finden. Entweder das, oder 8-facher Zoom. Zum einen schaut aber kein
Mensch Standbilder bei Videos an und zum anderen werden Videos auch
selten 8-fach gezoomed und wenn doch, erwartet kein vernünftiger
Mensch dann noch gute Qualität. Wenn man sich bewegte Videos
anschaut, dann kann man, wenn überhaupt, nur selten Unterschiede
zwischen VC-1, H264 oder VP8 ausmachen, die wirklich (meist störend)
auffallen. Bei ausreichend Bitrate spielt selbst teilweise Theora
noch in dieser Liga mit, obwohl er eigentlich den 3 unterlegen sein
müsste und oft auch faktisch ist.
Wer sich aber den Bericht von Jason Garrett-Glaser durchgelesen hat,
der wird ganz andere gravierende Mängel feststellen. Das die
Dokumentation ein Witz ist, was sie faktisch ist(!), ist dabei auch
noch nicht das ganze Ausmaß. Ich zitiere mal aus Chat-Mitschnitten,
die auch auf Jason's Seite zu finden sind:
05:28 < derf> Gumboot: You’ll be disappointed to know they got the
loop filter ordering wrong again.
05:29 < derf> Dark_Shikari: They ordered it such that you have to
process each macroblock in full before processing the next one.
oder
<derf> gmaxwell: It survives it with a patch that causes artifacts
because their encoder doesn’t clamp MVs properly.
<gmaxwell> ::cries::
<derf> So they reverted my decoder patch, instead of fixing the
encoder.
<gmaxwell> “but we have many files encoded with this!”
<gmaxwell> so great.. single implementation and it depends on its own
bugs. :(
This is just like Internet Explorer 6 all over again — bugs in the
software become part of the “spec”!
Derartige Dinge töten einen Standard ganz schnell!
VP8 is not ready for prime-time; the spec is a pile of copy-pasted C
code and the encoder’s interface is lacking in features and buggy.
They aren’t even ready to finalize the bitstream format, let alone
switch the world over to VP8.
With the lack of a real spec, the VP8 software basically is the
spec–and with the spec being “final”, any bugs are now set in stone.
Such bugs have already been found and Google has rejected fixes
Auf dieser Basis will ich nichts von VP8 wissen :-(
Man kann ja den MPEG Konsortium viel vorwerfen, aber in einer Sache
haben sie gezeigt, wie man wirklich bombensichere Standards schaffen
kann:
1. Man spezifiziert das Bitstream Format, und zwar nicht in Form von
Code, man spezifiziert es ganz neutral, unabhängig von einer
Programmiersprache.
2. Man spezifiziert alles was ein Decoder wissen oder können muss, um
aus diesen Bitstream wieder Videobilder zu machen. Auch hier, kein
Code, keine spezf. Programmiersprache.
3. Man spezifiziert den Encoder GAR NICHT. Ein Encoder ist valide,
wenn er einen Bitstream erzeugt, der (1) entspricht und der sich nach
(2) wieder in Bilder umwandeln lässt. Wie er das macht, ist sein
Problem.
Dieses Verfahren hat zum einen den Vorteil, dass jeder dank 1 und 2
einen Decoder schreiben kann, ohne überhaupt die geringste Ahnung
davon zu haben, wie ein Encoder funktioniert oder funktionieren
könnte. Und es hat den Vorteil, dass es über die Jahre hinweg immer
bessere Encoder geben wird, die immer bessere Qualität produzieren
bei gleicher Bitrate, und dennoch der erste Decoder, der jemals
geschrieben wurde, diese perfekt wiedergeben kann, weil sich eben an
(1) und (2) nichts geändert hat, nur der Weg dorthin hat sich
geändert, aber der war ja von Anfang an auch nie spezifiziert.
Wenn Google will, dass sich VP8 ernsthaft durchsetzt, dann sollen sie
mal ein paar Leute dahinter klemmen, die eine echte Spec schreiben.
Dann sollen *ANDERE* anhand dieser Spec einen Decoder schreiben und
dann sollen wieder *ANDERE* einen Encoder schreiben. Wenn das, was
letzterer erzeugt, nicht sauber vom Decoder wiedergegeben wird, dann
müssen die Leute prüfen ob es entweder daran liegt, dass der Decoder
sich nicht nicht an die Spec hält, dann ist das ein Bug im Decoder.
Oder dass der Encoder keine Daten wie von der Spec verrlang erzeugt,
dann ist das ein Bug im Encoder. Und wenn beide das tun und es
funktioniert trotzdem nicht, dann enthält die Spec an sich einen
fundamentalen Denkfehler und muss gefixed werden. Aber es gibt immer
genau einen schuldigen, der sein "Werk" fixen muss und wenn es dann
endlich funktioniert, dann ist die Spec gut.
Im Moment teilen sich En- und Decoder den selben Code und dieser ist
zeitgleich auch die Spec. D.h. jeder Bug im Encoder ist auch ein Bug
im Decoder und keiner von beiden kann gefixed werden, weil damit
würde man die Spec ändern. So kann das nie funktionieren.
Sorry Google, aber das ist *echt unprofessionell*.
/Mecki
ganz, ganz genau hinschauen, um hier gravierende Unterschiede zu
finden. Entweder das, oder 8-facher Zoom. Zum einen schaut aber kein
Mensch Standbilder bei Videos an und zum anderen werden Videos auch
selten 8-fach gezoomed und wenn doch, erwartet kein vernünftiger
Mensch dann noch gute Qualität. Wenn man sich bewegte Videos
anschaut, dann kann man, wenn überhaupt, nur selten Unterschiede
zwischen VC-1, H264 oder VP8 ausmachen, die wirklich (meist störend)
auffallen. Bei ausreichend Bitrate spielt selbst teilweise Theora
noch in dieser Liga mit, obwohl er eigentlich den 3 unterlegen sein
müsste und oft auch faktisch ist.
Wer sich aber den Bericht von Jason Garrett-Glaser durchgelesen hat,
der wird ganz andere gravierende Mängel feststellen. Das die
Dokumentation ein Witz ist, was sie faktisch ist(!), ist dabei auch
noch nicht das ganze Ausmaß. Ich zitiere mal aus Chat-Mitschnitten,
die auch auf Jason's Seite zu finden sind:
05:28 < derf> Gumboot: You’ll be disappointed to know they got the
loop filter ordering wrong again.
05:29 < derf> Dark_Shikari: They ordered it such that you have to
process each macroblock in full before processing the next one.
oder
<derf> gmaxwell: It survives it with a patch that causes artifacts
because their encoder doesn’t clamp MVs properly.
<gmaxwell> ::cries::
<derf> So they reverted my decoder patch, instead of fixing the
encoder.
<gmaxwell> “but we have many files encoded with this!”
<gmaxwell> so great.. single implementation and it depends on its own
bugs. :(
This is just like Internet Explorer 6 all over again — bugs in the
software become part of the “spec”!
Derartige Dinge töten einen Standard ganz schnell!
VP8 is not ready for prime-time; the spec is a pile of copy-pasted C
code and the encoder’s interface is lacking in features and buggy.
They aren’t even ready to finalize the bitstream format, let alone
switch the world over to VP8.
With the lack of a real spec, the VP8 software basically is the
spec–and with the spec being “final”, any bugs are now set in stone.
Such bugs have already been found and Google has rejected fixes
Auf dieser Basis will ich nichts von VP8 wissen :-(
Man kann ja den MPEG Konsortium viel vorwerfen, aber in einer Sache
haben sie gezeigt, wie man wirklich bombensichere Standards schaffen
kann:
1. Man spezifiziert das Bitstream Format, und zwar nicht in Form von
Code, man spezifiziert es ganz neutral, unabhängig von einer
Programmiersprache.
2. Man spezifiziert alles was ein Decoder wissen oder können muss, um
aus diesen Bitstream wieder Videobilder zu machen. Auch hier, kein
Code, keine spezf. Programmiersprache.
3. Man spezifiziert den Encoder GAR NICHT. Ein Encoder ist valide,
wenn er einen Bitstream erzeugt, der (1) entspricht und der sich nach
(2) wieder in Bilder umwandeln lässt. Wie er das macht, ist sein
Problem.
Dieses Verfahren hat zum einen den Vorteil, dass jeder dank 1 und 2
einen Decoder schreiben kann, ohne überhaupt die geringste Ahnung
davon zu haben, wie ein Encoder funktioniert oder funktionieren
könnte. Und es hat den Vorteil, dass es über die Jahre hinweg immer
bessere Encoder geben wird, die immer bessere Qualität produzieren
bei gleicher Bitrate, und dennoch der erste Decoder, der jemals
geschrieben wurde, diese perfekt wiedergeben kann, weil sich eben an
(1) und (2) nichts geändert hat, nur der Weg dorthin hat sich
geändert, aber der war ja von Anfang an auch nie spezifiziert.
Wenn Google will, dass sich VP8 ernsthaft durchsetzt, dann sollen sie
mal ein paar Leute dahinter klemmen, die eine echte Spec schreiben.
Dann sollen *ANDERE* anhand dieser Spec einen Decoder schreiben und
dann sollen wieder *ANDERE* einen Encoder schreiben. Wenn das, was
letzterer erzeugt, nicht sauber vom Decoder wiedergegeben wird, dann
müssen die Leute prüfen ob es entweder daran liegt, dass der Decoder
sich nicht nicht an die Spec hält, dann ist das ein Bug im Decoder.
Oder dass der Encoder keine Daten wie von der Spec verrlang erzeugt,
dann ist das ein Bug im Encoder. Und wenn beide das tun und es
funktioniert trotzdem nicht, dann enthält die Spec an sich einen
fundamentalen Denkfehler und muss gefixed werden. Aber es gibt immer
genau einen schuldigen, der sein "Werk" fixen muss und wenn es dann
endlich funktioniert, dann ist die Spec gut.
Im Moment teilen sich En- und Decoder den selben Code und dieser ist
zeitgleich auch die Spec. D.h. jeder Bug im Encoder ist auch ein Bug
im Decoder und keiner von beiden kann gefixed werden, weil damit
würde man die Spec ändern. So kann das nie funktionieren.
Sorry Google, aber das ist *echt unprofessionell*.
/Mecki