VP8 ist offener Standard

[Coda]

Google hat's auf der I/O gerade verkündet. Es heißt absofort WebM. YEAH!

Edit: Opera hat schon ein Labs-Release http://labs.opera.com/news/2010/05/19/

[DanMan]

Oha, das wird ja interessant. Bin mal gespannt ob das W3C noch reagiert, oder ob es bei Theora/h264 bleibt.

edit: krass, dass Opera schon einen Build und einen dev-Artikel (http://dev.opera.com/articles/view/opera-supports-webm-video/) am Start hat. Da muss doch hintenrum schon gemauschelt worden sein.

Dass man dafür aber auch einen neuen Container (WebM) benötigt find ich spontan erstmal nicht so toll. Erst recht, wenn es Matroska-basiert ist. Warum nicht gleich Matroska? Das würde dem Container gleich auch noch den Schub geben, den es verdient.

[Coda]

Das Container-Format ist offenbar Matroska.

[Ric]

Die Frage lautet natürlich, wie setzt man das durch, oder auch:

Konvertiert Youtube im Hintergrund schon zu VP8?

Oder wie soll es sonst zu einer Marktdurchdringung kommen. Eines ist klar - Adobe Flash (mit h.264) ist ein Fels in der Brandung, da benötigt es mehr als ein Sturm, als dass dieser abbricht.

[DanMan]

Konvertiert Youtube im Hintergrund schon zu VP8?
Jup, YouTube ist schon am konvertieren (http://www.googlewatchblog.de/2010/05/19/google-io-vp8-wird-open-source--youtube/).

@Coda: bei Opera heißt es Matroska-basiert. Die Videos enden auch nicht auf mkv sondern webm.

[Coda]

Die Frage lautet natürlich, wie setzt man das durch
Keine Lizenzgebühren und fast so gut wie H.264 sind ziemlich gute Argumente.

Konvertiert Youtube im Hintergrund schon zu VP8?
Mit Sicherheit.

@Coda: bei Opera heißt es Matroska-basiert. Die Videos enden auch nicht auf mkv.
Matroska ist schon immer erweiterbar. Ich denke da wird nichts grundlegendes eingeführt worden sein. Der Dateiname ist auch nur Schall und Rauch.

[nutel]

http://www.webmproject.org/

mit youtube anleitung :)

http://www.webmproject.org/users/

[DanMan]

Matroska ist schon immer erweiterbar. Ich denke da wird nichts grundlegendes eingeführt worden sein. Der Dateiname ist auch nur Schall und Rauch.
Schon, aber warum den Markt fragmentieren? Würd mich interessieren, was hinter dieser Entscheidung steckt. Hoffentlich nicht bloß rechtliche Bedenken.

[Coda]

Ich gehe bisher davon aus, dass webm einfach VP8 + Vorbis in Matroska ist. Das .webm dient nur zur eindeutigen Indentifizierung in Verbindung mit dem MIME-Typ.

[Ric]

Kein Youtube, kein "Apple", wird ne harte Nummer für Adobe.

Ich bin mal gespannt. Das ähnelt schon fast einer Revolution, als Evolution.

[Coda]

At initial release, WebM supports a subset of the Matroska specification. Support for additional Matroska functionality will be under consideration as the project matures.

Es ist also keine Erweiterung sondern ein Subset. Jeder Matroska-Demuxer sollte also damit zurecht kommen.

[Ric]

Nochmal eingeworfen: Hardwarebeschleunigung. Das machst mir schon wieder Kopfschmerzen. Wenn ich so an ATI denke (sitze gerade an einem Xpress 1150 Notebook) dann bekomme ich wieder das Graussen, wann das bei ATI angefasst wird - und bestimmt wieder ohne "legacy" - Support.

[Coda]

Ja, da wird sich Google aber schon dafür einsetzten, dass entsprechende Chips produziert werden die VP8 dekodieren können.

Vor allem für ihre Android-Geräte brauchen sie das ja sogar.

[DanMan]

Kein Youtube, kein "Apple", wird ne harte Nummer für Adobe.

Ich bin mal gespannt. Das ähnelt schon fast einer Revolution, als Evolution.
Erstaunlicher Weise steht unter den webm Unterstützern (http://www.webmproject.org/about/supporters/) sogar Flash. Hat Adobe etwa vor webm in Flash zu unterstützen? Wär zwar nett, aber nur bedingt interessant, wenns der Browser selbst auch kann.
Ich gehe bisher davon aus, dass webm einfach VP8 + Vorbis in Matroska ist. Das .webm dient nur zur eindeutigen Indentifizierung in Verbindung mit dem MIME-Typ.
Es ist also keine Erweiterung sondern ein Subset. Jeder Matroska-Demuxer sollte also damit zurecht kommen.
Hmm, dein Wort in Googles Ohren. Ich kanns zwar verstehen, dass man es den Benutzern möglichst einfach machen wollte, indem man so die Codecs auf VP8 und Vorbis beschränkt. Trotzdem finde ich es schade.

Unterm Strich überwiegt aber das Positive für meinen Geschmack. So wie alle (Google (Chrome), Opera und Mozilla) Gas geben steht der Video-Standard fürs Web wohl jetzt fest.

Jedenfalls ein mächtig dicker Schiss vor den Bug der MPEG. :D

[Ganon]

Hmm... aber die Patent-Frage scheint noch ungeklärt zu sein?

http://www.golem.de/1005/75243.html


Florian Müller vom europäischen Projekt NoSoftwarePatents kritisiert allerdings, dass Google keine konkreten Aussagen zu Patenten auf VP8 gemacht hat. Google habe lediglich darauf hingewiesen, dass das Unternehmen einige Patente an WebM halte, aber keine Angaben zu möglicherweise von anderen gehaltenen Patenten gemacht. Er fordert Google auf, eine gut dokumentierte Patentrecherche durchzuführen, auf die sich Drittentwickler bei möglichen Angriffen berufen können.


Ansonsten wäre eine endgültige Lösung natürlich zu begrüßen. Müssen dann nur noch Apple und Microsoft nachziehen ;)

[(del)]

Erstaunlicher Weise steht unter den webm Unterstützern (http://www.webmproject.org/about/supporters/) sogar Flash. Hat Adobe etwa vor webm in Flash zu unterstützen? Wär zwar nett, aber nur bedingt interessant, wenns der Browser selbst auch kann.He he :smile: Das hab ich schon letzten Monat hervorgesagt.
Das mit der "Browser selbst kann" kannst du mal an paar Theora-Seiten austesten. Die build-in PlayerGUIs stinken gegenüber Flash-GUIs komplett ab. Auch das "Vorstreamen", Cachen, Einbettung usw. kannn sich noch kaum sehen lassen.

[DanMan]

Hmm... aber die Patent-Frage scheint noch ungeklärt zu sein?
http://www.golem.de/1005/75243.html

Ansonsten wäre eine endgültige Lösung natürlich zu begrüßen. Müssen dann nur noch Apple und Microsoft nachziehen ;)
Das ist natürlich bedenklich, aber ich nehme mal an, dass das noch folgen wird, sonst wären Opera und Mozilla wohl kaum mit eingestiegen.

Ich glaube nicht, dass Apple und MS sich WebM verschließen können werden. Der Fakt, dass Google mit drin steckt, wiegt eine Menge. Da spricht allerdings die Hoffnung mit aus mir. Beide haben außer der Arbeit, die investiert werden muss, keinen Grund nicht mit zu machen, wenn sich die rechtlichen Bedenken als unbegründet herausstellen.
Are you encouraging people to simply test WebM or actually use it?

The VP8 and WebM specifications as released on May 19th, 2010 are final and we encourage everyone to use them for developing applications. Google, Mozilla and Opera are all adding WebM support to their browsers and all videos that are 720p or larger uploaded to YouTube after May 19th will be be encoded in WebM as part of its HTML5 experiment.
Wenns nach denen geht kann man also schon los legen. :eek:

Außerdem:
If I have a video card that accelerates video playback, will it accelerate VP8?

The performance of VP8 is very good in software, and we’re working closely with many video card and silicon vendors to add VP8 hardware acceleration to their chips.

[(del)]

Ah du Kacke :D
Google, Mozilla and Opera are all adding WebM support to their browsers and all videos that are 720p or larger uploaded to YouTube after May 19th will be be encoded in WebM as part of its HTML5 experiment.Ich glaub der WebM-Flash kommt noch diese Woche :ulol:

[Coda]

Denke dass das Chrome-Update auch nicht lange auf sich warten lässt ;)

[Sephiroth]

Mozilla macht mit: http://blog.mozilla.com/blog/2010/05/19/open-web-open-video-and-webm/

Test-Builds gibt es unter http://nightly.mozilla.org/webm/ bzw. http://releases.mozilla.org/pub/mozilla.org/firefox/releases/devpreview/1.9.3a4webm/

tracking bug 566243 - Merge mozilla-webmedia repository to mozilla-central (https://bugzilla.mozilla.org/show_bug.cgi?id=566243)

[steve.it]

The first in-depth technical analysis of VP8
http://x264dev.multimedia.cx/?p=377#more-377

[Benedikt]

Microsoft ist mit im Boot! (http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx)

[Rooter]

Das Container-Format ist offenbar Matroska.
Es ist also keine Erweiterung sondern ein Subset. Jeder Matroska-Demuxer sollte also damit zurecht kommen.Hmm, kann das bitte mal jemand überprüfen und eine .webm-Datei nach .mkv umbenennen und mit einem Programm öffnen das .mkv's weiterverarbeiten kann!?

Keine Lizenzgebühren und fast so gut wie H.264 sind ziemlich gute Argumente.Leider ist die Marktmacht der bestimmende Faktor, das kennt man ja schon von früher (Video2000 vs. VHS fällt mir spontan ein). Ich sehe zwei Namen die beeinflussen werden ob WebM groß wird oder nicht: Internet Explorer und YouTube. Wenn der IE WebM aus Sturheit dem großen Konkurrenten gegenüber ablehnt wird es wohl nie richtig groß werden.
Anderseits, wenn YouTube (Google) ihren Content bevorzugt in dem neuen Format ausliefert statt als Flash oder H264 wird M$ den Codec integrieren müssen denn obwohl sie immer noch Marktführer bei den Webbrowsern sind werden sie eine so große Plattform wie YouTube ihren Kunden nicht vorenthalten können ohne Gefahr zu laufen dass diese in Scharen zu anderen Browsern abwandern.

Naja, es bleibt auf jeden Fall spannend. :)

EDIT:
Microsoft ist mit im Boot! (http://windowsteamblog.com/windows/b/bloggingwindows/archive/2010/05/19/another-follow-up-on-html5-video-in-ie9.aspx)Wenn das wirklich bedeutet dass der IE9 WebM unterstützen wird ist der Dropps imho gelutscht! =)
Wenn Adobe das Format nicht spätestens mit Flash 11 unterstützt brechen für die schwere Zeiten an...
MfG
Rooter

[Ganon]

Nunja,

In its HTML5 support, IE9 will support playback of H.264 video as well as VP8 video when the user has installed a VP8 codec on Windows.

Das heißt nur, dass sie es nicht blocken ;) Offiziell unterstützen heißt auch mitliefern. Sonst kann man auch sagen, dass Microsoft Java, QuickTime und was weiß ich was offiziell unterstützt. Der User kann es ja installieren. Solange der Codec nicht Teil vom IE9 wird, heißt das gar nix.

Aber dass der IE9 HTML5-Video unterstützten wird, ist schonmal gut.

[Coda]

"nicht blocken" ist falsch. Sie erlauben es explizit. Sonst ist nämlich nur H.264 möglich.

Aber dass der IE9 HTML5-Video unterstützten wird, ist schonmal gut.
Und schon länger bekannt ;)

The first in-depth technical analysis of VP8
http://x264dev.multimedia.cx/?p=377#more-377
Oh je. Der Codec und die Spec scheinen ja nicht gerade das Gelbe vom Ei zu sein. Aber besser als nix.

[Ganon]

http://x264dev.multimedia.cx/?p=377


But first, a comment on the spec itself.

AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!


:D

Na mal gucken, ob sich jetzt was an der allgemeinen Einstellung ändert.

[basti333]

Hmm... aber die Patent-Frage scheint noch ungeklärt zu sein?

http://www.golem.de/1005/75243.html



Ansonsten wäre eine endgültige Lösung natürlich zu begrüßen. Müssen dann nur noch Apple und Microsoft nachziehen ;)


Tja, das ist nun aber Googles problem. Wenn am ende wirklich noch jemand Patente hält die auch gerichte anerkennen, muss Google halt blechen. Das werden die schon verkraften. Gute Anwälte haben sie ja sowieso.

Bzgl. Adobes Support: Ob sie Flash schon halb aufgegeben haben und jetzt das beste daraus machen wollen?

[Nightspider]

Nochmal jetzt für Noobs:

Ist das ein Format welches von Grafikkarten unterstützt wird und braucht man da erst wieder passende Hardware dafür?

Wird VP8 auf Iphone und Ipad laufen?

[DanMan]

Nunja,

Das heißt nur, dass sie es nicht blocken ;) Offiziell unterstützen heißt auch mitliefern. Sonst kann man auch sagen, dass Microsoft Java, QuickTime und was weiß ich was offiziell unterstützt. Der User kann es ja installieren. Solange der Codec nicht Teil vom IE9 wird, heißt das gar nix.
So siehts aus. Wenns nicht im IE eingebaut ist, dann kann man sich als Webentwickler auch nicht drauf verlassen - ist also fürn Arsch. Mal schauen was Apple noch sagen wird.

Der Bericht von dem x264 Entwickler liest sich in der Tat nicht besonders gut. Dass der Codec nicht ganz an h264 high profile ranreicht, aber wenigstens etwas besser als Theora ist, das war ja eigentlich schon im Voraus klar. Nur, dass patentrechtliche Probleme nicht unwahrscheinlich sind, das klingt bitter. Da kann man nur hoffen, dass sich die Entwickler das gut vorher angeschaut haben. Laut dem einen Kommentar muss man ja alle Patentinhalte verletzen um anklagbar zu sein.

[basti333]

Nochmal jetzt für Noobs:

Ist das ein Format welches von Grafikkarten unterstützt wird und braucht man da erst wieder passende Hardware dafür?

Wird VP8 auf Iphone und Ipad laufen?


Zu 1. Noch nicht, aber das lässt sich AFAIK per Treiberupdate nachrüsten. Was mobile Geräte angeht so wird ein Hardware Support sicher kommen, spätetens wenn genügend Software-Giganten aufspringen (Microsoft, Apple...)

Zu 2. Siehe 1. wenn Apple das will werden auch iPhone und iPad das können. Wenn es "nur" per Software nachgerüstet wird dürfte aber AFAIK die Performance nicht so gut sein. Wenn ich scheiße laber, verbessert mich.

[looking glass]

Ist ja wohl ein dickes Ding was die haben platzen lassen und das die das wirklich geheim halten konnten, immerhin gibt es schon Builds für FF, Opera macht auch mit, weia.

Gute Sache das.

[Ganon]

Aber das die genannten Browser das können ist doch recht egal, oder? Ich meine, die unterstützten doch afaik auch Theora sofort...

Nur MS mit seiner "Halbunterstützung" kommt jetzt noch dazu.

[Avalox]

Video ist nun auch im Internet angekommen.
Da werden wir noch schöne Produkte in Zukunft zu sehen bekommen.

[DanMan]

Aber das die genannten Browser das können ist doch recht egal, oder? Ich meine, die unterstützten doch afaik auch Theora sofort...

Nur MS mit seiner "Halbunterstützung" kommt jetzt noch dazu.
Es ist aber nicht wirtschaftlich für zig verschiedene Formate Videos zu erstellen und zu speichern.

[Benedikt]

Zu 2. Siehe 1. wenn Apple das will werden auch iPhone und iPad das können. Wenn es "nur" per Software nachgerüstet wird dürfte aber AFAIK die Performance nicht so gut sein. Wenn ich scheiße laber, verbessert mich.
Sehr interessante Sache, das. Viele werden wahrscheinlich sofort aufspringen und sagen "aber Apple würde VP8 doch niemals unterstützen (H.264-Boardmember u.a.)". Aber warum eigentlich nicht? Zwar sind wahrscheinlich die Decoder-Chips in den iDevices für VP8 nicht geeignet, aber zumindest ein grundlegender Support basierend auf CPU-decoding - wäre dies so abwegig?

Oder ist der Google-Hass mittlerweile dort so weit gediegen, dass dies nur über Jobs' Leiche passieren würde? :wink:

[basti333]

Sehr interessante Sache, das. Viele werden wahrscheinlich sofort aufspringen und sagen "aber Apple würde VP8 doch niemals unterstützen (H.264-Boardmember u.a.)". Aber warum eigentlich nicht? Zwar sind wahrscheinlich die Decoder-Chips in den iDevices für VP8 nicht geeignet, aber zumindest ein grundlegender Support basierend auf CPU-decoding - wäre dies so abwegig?

Oder ist der Google-Hass mittlerweile dort so weit gediegen, dass dies nur über Jobs' Leiche passieren würde? :wink:


Naja, Google profitiert ja nicht wirklich davon, ein bisschen Image-Gewinn, aber das war es. Außerdem könnte Apple Flash so noch schneller ausrotten. Hängst jetzt davon ab wen sie mehr hassen, Adobe oder Google.

Btw. Ich denke die paar millionen aus den H.264 lizenzen gehen Apple getrost am A..... vorbei.

[looking glass]

Kann sich das Apple leisten? Glaube nicht, eben bei fefe gelesen, das auch der IE webM unterstützen wird - wir hätten also FF, Opera, Chrome und IE, dagegen stünde nur Safari...

http://gizmodo.com/5542688/google-wants-to-save-web-video-with-the-new-webm-format

Apple dürfte angepisst sein, weil sie bei MPEG mit im Konsortium sitzen und an den Patenten logischerweise verdienen.

[DanMan]

Kann sich das Apple leisten? Glaube nicht, eben bei fefe gelesen, das auch der IE webM unterstützen wird - wir hätten also FF, Opera, Chrome und IE, dagegen stünde nur Safari...

Apple dürfte angepisst sein, weil sie bei MPEG mit im Konsortium sitzen und an den Patenten logischerweise verdienen.
Hatten wir vorhin schon, dass die IE-Implementation ihren Namen nicht verdient.

Außerdem hab ich vorhin gelesen, dass Apple scheinbar nur 1 Patent bei der MPEG für h.264 hält, während MS glaub 32 hat. Letztere müssen aber mehr an Lizenzgebühren zahlen, als sie wieder herauskriegen... So viel dazu.

[(del)]

:D

Na mal gucken, ob sich jetzt was an der allgemeinen Einstellung ändert.Wir brauchen erstmal etwas um h.264 als Webvideo vermeiden zu können. Was wir sonstnoch nutzen spielt erstmal keine Geige. Hast du alles von DivX auf FLV umkodiert als Youtube populär wurde? ;) Oder sonstjemand hier nach WMV9? Oder von MP3 nach Vorbis? :|

Bis VP8 den Stand vom aktuellen x264 svn erreicht hat wird noch mächtig viel Zeit vergehen. Selbst wenn Google voll ranklotzt. Macht nichts. Wir haben ja beides bzw. halt alles was wir brauchen :up: Man darf nicht vergeßen, daß x264 eigentlich mit das beste Stück x86-Code auf dem Planeten ist. Das Zeug ist fast schon übererdisch =)

edit1:
Ok. Eingelesen =) Ah, und Jason...:
"this is still significantly better than Theora"
"it will undoubtedly be a major upgrade as compared to Theora"
"Though I am not a lawyer, I simply cannot believe that they will be able to get away with this, especially in today’s overly litigious day and age. Even VC-1 differed more from H.264 than VP8 does, and even VC-1 didn’t manage to escape the clutches of software patents."
"While the C code isn’t half bad, the assembly is clearly written by retarded monkeys." :D

Das was Heise bei Jason rausgelesen hat "Garrett-Glaser gesteht jedoch ein, dass VP8 bei seinen ersten Tests durchaus besser abschneidet als x264 bei Nutzung des einfachsten H.264-Profils (Baseline Profile)" sehe ich aber nicht auf seinen Beispielbildern. Signifikant besser als Theora, aber zu h.264 baseline fehlt noch ein gutes Stück.

edit2:
Adobe hat angeblich verlauten lassen, daß Flash vermutlich noch vor Fx4final VP8/Vorbis/Matroska können wird. Damit unterstützt MS WebM genauso wie FLV voll und ganz ;) Und genauso wie z.B. Fx 3.6.x.

[Hydrogen_Snake]

Ja, ein stück Alientechnologie das in zig Containern z.B. im offenen .flv daherkommt.

Hmm, kann das bitte mal jemand überprüfen und eine .webm-Datei nach .mkv umbenennen und mit einem Programm öffnen das .mkv's weiterverarbeiten kann!?

Leider ist die Marktmacht der bestimmende Faktor, das kennt man ja schon von früher (Video2000 vs. VHS fällt mir spontan ein). Ich sehe zwei Namen die beeinflussen werden ob WebM groß wird oder nicht: Internet Explorer und YouTube. Wenn der IE WebM aus Sturheit dem großen Konkurrenten gegenüber ablehnt wird es wohl nie richtig groß werden.
Anderseits, wenn YouTube (Google) ihren Content bevorzugt in dem neuen Format ausliefert statt als Flash oder H264 wird M$ den Codec integrieren müssen denn obwohl sie immer noch Marktführer bei den Webbrowsern sind werden sie eine so große Plattform wie YouTube ihren Kunden nicht vorenthalten können ohne Gefahr zu laufen dass diese in Scharen zu anderen Browsern abwandern.

Naja, es bleibt auf jeden Fall spannend. :)

EDIT:
Wenn das wirklich bedeutet dass der IE9 WebM unterstützen wird ist der Dropps imho gelutscht! =)
Wenn Adobe das Format nicht spätestens mit Flash 11 unterstützt brechen für die schwere Zeiten an...
MfG
Rooter

Ich dachte auf der IO wurde Adobe ebenfalls genannt.

[aths]

VP8 unterstützt keine adaptive Quantisierung – wtf? Selbst DXT1-Texturkomprimierung unterstützt das.

[SavageX]

VP8 unterstützt keine adaptive Quantisierung – wtf? Selbst DXT1-Texturkomprimierung unterstützt das.

Doch, geht. So eine Spezifikation will erstmal gelesen werden (bin noch dran), aber AQ geht.

[Chris Lux]

Addendum C: Summary for the lazy

VP8, as a spec, should be a bit better than H.264 Baseline Profile and VC-1. It’s not even close to competitive with H.264 Main or High Profile. If Google is willing to revise the spec, this can probably be improved.

VP8, as an encoder, is somewhere between Xvid and Microsoft’s VC-1 in terms of visual quality. This can definitely be improved a lot, but not via conventional means.

VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much.

With regard to patents, VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free.

VP8 is definitely better compression-wise than Theora and Dirac, so if its claim to being patent-free does stand up, it’s an upgrade with regard to patent-free video formats.

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

Google made the right decision to pick Matroska and Vorbis for its HTML5 video proposal.


Update: it seems that what I forsaw is already coming true:

<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”!


klingt fuer mich alles andere als rosig. warum sollte man beim web-video standard derartige rueckschritte zu h264 zulassen?

[SavageX]

klingt fuer mich alles andere als rosig. warum sollte man beim web-video standard derartige rueckschritte zu h264 zulassen?

Immer dran denken, wer das geschrieben hat und was er so den ganzen Tag tut.

Er selbst sagt, dass der derzeitige Encoder schon besser ist als H.264 Baseline (was YouTube derzeit verwendet, die *gewinnen* also jetzt schon Qualität) und VC-1... und dabei sieht der Encoder derzeit nichtmal besonders clever aus.

Weiterhin ist H.264 einfach eine derartige Lizenzkatastrophe, dass man hier und da Abstriche locker hinnehmen kann.

[Chris Lux]

wenn ich mir die vergleichsbilder ansehe will ich eigentlich solche abstriche nicht hinnehmen. mich als nutzer interessieren die rechtlichen sachen nicht. die sollen wenn schon einen offenen standard bringen, der die qualitaet erreichen kann.

[Pinoccio]

Ich vermute mal, daß Google mit seiner Manpower und den zur Verfügung stehenden Resourcen einen brauchbaren Codec hinbekommt, auch wenn es vielleicht derzeit noch nicht danach aussieht. Ich meine - wer, wenn nicht Google? ^^

mfg

[SavageX]

wenn ich mir die vergleichsbilder ansehe will ich eigentlich solche abstriche nicht hinnehmen. mich als nutzer interessieren die rechtlichen sachen nicht. die sollen wenn schon einen offenen standard bringen, der die qualitaet erreichen kann.

Auf den Vergleichsbildern siehst Du einen VP8 Encoder, der dem Anschein nach noch einiges an Optimierungen gebrauchen kann und einen H.264 Encoder, der bereits höchst liebevoll durchgeknetet wurde. Steht nicht umsonst "Developer Preview" über dem ganzen Zeug.

[aths]

Doch, geht. So eine Spezifikation will erstmal gelesen werden (bin noch dran), aber AQ geht.Ja so etwas Ähnliches geht, aber fürchterlich umständlich, wahrscheinlich impraktikabel.


Ich meine - wer, wenn nicht Google? ^^Eine Gruppe mit entsprechender Erfahrung. Immer wieder werden neue Codecs angespriesen, schon zu DOS-Zeiten ... die Fortschritte beziehen sich dabei auf Spezialfälle, die jeweilige MPEG-Version wird jedoch ingesamt nicht erreicht.

[SavageX]

Ja so etwas Ähnliches geht, aber fürchterlich umständlich, wahrscheinlich impraktikabel.

Ich denke irgendeinen Grund wird es dafür schon geben. Das Feature wäre nicht vorgesehen, wenn es nichts brächte ;-)

Den Rest mögen die Kodiermagier machen, man hat ja aus VP3 noch einiges rausgeholt, obwohl man von den Bitstreamfeatures eher *unter* MPEG-4 ASP liegt.

[aths]

Ich denke irgendeinen Grund wird es dafür schon geben. Das Feature wäre nicht vorgesehen, wenn es nichts brächte ;-)

Den Rest mögen die Kodiermagier machen, man hat ja aus VP3 noch einiges rausgeholt, obwohl man von den Bitstreamfeatures eher *unter* MPEG-4 ASP liegt.Aus einem schlechteren Verfahren mit einem guten Kompressor noch was rauszuholen ist weniger effizient als ein besseres Verfahren zu nutzen und dort noch was rauszukitzeln.

H.264 implementierte einige neue (wenn auch naheliegende) Ideen wie gewichtete Interpolation zwischen Bildern um Fade-ins oder Fade-Outs effizienter zu speichern.

[(del)]

mich als nutzer interessieren die rechtlichen sachen nicht.Du meinst die Lizenzen? Ja mich interessieren sie auch nicht. Außer ab 2012 wäre einiges nur per Paypal erreichbar... Das sind wiederum Sachen welche die Anbieter interessieren. Der Kunde ist nur König, wenn er bares rüberspringen läßt.

Der Vergleich ist doch in 1080p bei gleicher Vidgröße/Einstellungen/Bitraten? Es kann sein, daß VP8-Vids erstmal noch 10% größer werden und schon sehr vergleichbare Quali haben.

[SavageX]

Aus einem schlechteren Verfahren mit einem guten Kompressor noch was rauszuholen ist weniger effizient als ein besseres Verfahren zu nutzen und dort noch was rauszukitzeln.


Ehrlich gesagt ist das Segmentierungsmodell von VP8 so schlecht nun auch nicht, kriegt man ja pro Segment auch noch die Stärke und Art des Loopfilters gleich mitkonfiguriert, was ja auch Sinn macht (stärker quantisierte Teile wollen vielleicht einen stärkeren Loopfilter etc.). Die Entropiekodierung dürfte mit den paar Segmenten und der Zuordnung zu den Makroblöcken ganz gut klarkommen.

[Hydrogen_Snake]

Wird mit Gingerbread auch im Android Browser Einzug halten.

[Coda]

Ich vermute mal, daß Google mit seiner Manpower und den zur Verfügung stehenden Resourcen einen brauchbaren Codec hinbekommt, auch wenn es vielleicht derzeit noch nicht danach aussieht. Ich meine - wer, wenn nicht Google? ^^
Anscheinend ist das Bitstream-Format schon in Stein gemeiselt.

[SavageX]

Anscheinend ist das Bitstream-Format schon in Stein gemeiselt.

Der Encoder aber natürlich nicht ;-)

Fatale Genick-brechende Ungeheuerlichkeiten sehe ich im Bitstream derzeit nicht, auch wenn manche Sachen etwas ungewöhnlich sind. Aber irgendwas muss man ja tun, um um die bestehenden Patente herumzukommen.

[Coda]

Der Encoder aber natürlich nicht ;-)
So wie sich der x264-Mensch anhört ist das aber nur ein Teil des Übels.

[SavageX]

So wie sich der x264-Mensch anhört ist das aber nur ein Teil des Übels.

Der x264-Mensch ist bekannt für seine starken Meinungen und gibt gelegentlich Grund an seiner Neutralität zu zweifeln. Ich habe das Vergnügen, mit ihm einige IRC-Channels zu teilen.

[steve.it]

Ich denke ideal wäre folgendes Szenario:

Unabhängig von der Patentfrage und davon wie gut VP8 tatsächlich ist, dürfte die breite Unterstützung dennoch Eindruck auf die H.264-Patentinhaber machen. Möglicherweise können diese sich nun doch dazu durchringen, wenigstens das H.264 Baseline Profile dauerhaft lizenzkostenfrei für die Web-Nutzung freizugeben und so den Streit um einen Webvideostandard beizulegen.
http://www.heise.de/newsticker/meldung/Google-I-O-Open-Web-Media-Project-soll-VP8-als-Videostandard-fuers-Web-etablieren-Update-1003785.html

[SavageX]

Ja, eine freie H.264 Baseline wäre sicherlich noch ein hübsches nice-to-have.

[Benedikt]

Könnte die ganze VP8-Geschichte am Ende nur ein Druckmittel für die MPEG-LA sein, dies zu tun - und sich doch H.264 auf breiter Front im Netz durchsetzen?

[Avalox]

Ich denke ideal wäre folgendes Szenario:


http://www.heise.de/newsticker/meldung/Google-I-O-Open-Web-Media-Project-soll-VP8-als-Videostandard-fuers-Web-etablieren-Update-1003785.html

Ideal finde ich dieses nicht.

Ein gedeckelter Codec. Ganz sicher dann auch nicht frei, sondern nur kostenlos in der vorbestimmten Verwendung.
VP8 erreicht nach dem zitierten Artikel, eine höhere Qualität, bei identischer Bandbreite als H.264 in der heutigen Verwendung im Web.
VP8 soll sich mal als tatsächlich freier Codec, ohne Deckelung etablieren. Mit allen Vorteilen eines freien Verfahrens und natürlich auch einer anwedungskonformen Weiterentwicklung, ohne an irgend welche Grenzen von Rechteinhabern zu stoßen.
Über die Hälfte allen Video Traffics im Netz wird ja allein von Youtube generiert, dass ist schon das Totschlagargument des neuen Codecs.
Android wird auch in der Lage sein VP8 wiederzugeben, also schon klare Tatsachen.
Kann ja jeder mitmachen wenn er will.

[(del)]

Es gibt eine Nightly Build von Firefox 3.7 mit WebM alias VP8.
http://nightly.mozilla.org/webm/

[Tesseract]

So wie sich der x264-Mensch anhört ist das aber nur ein Teil des Übels.
so wie sich der anhört will er einfach seinen h264 schönreden.
überall wo er sagt, es lässt sich schwer einschätzen was sinnvoller ist, ist dann trotzdem h264 "einfach mal besser".
was beim VP8 flexibel ist, ist unnötig. was beim h264 flexibel ist, ist ein killer-feature.
alles soll von h264 abgekupfert sein aber trotzdem beschwert er sich darüber, dass der code teilweise älter als h264 und trotzdem nicht ganz ausgereift ist?
usw.
dass der h264 in summe von der kompression her trotzdem noch besser ist mag ja sein, aber der text ist großteils einfach nur egozentrisches blahblah.

[(del)]

Schönreden? Das Teil ist in nahezu jeder Hinsicht perfekt. So Kacke ist VP8 aber trotzdem nicht. Paar Bits mehr als AVC und es paßt schon.

[aths]

dass der h264 in summe von der kompression her trotzdem noch besser ist mag ja sein, aber der text ist großteils einfach nur egozentrisches blahblah.Finde ich nicht. Der Autor hat Ahnung. VP8 sollte laut On2 natürlich mal wieder alles besser machen. Stimmt aber nicht.

[Ganon]

dass der h264 in summe von der kompression her trotzdem noch besser ist mag ja sein, aber der text ist großteils einfach nur egozentrisches blahblah.

Er belegt doch seine Argumente sehr ausführlich...

[Exxtreme]

Er belegt doch seine Argumente sehr ausführlich...
Das mag ja sein. Aber IMHO ist es so, dass sich nicht immer die technisch beste Lösung durchsetzt sondern das bessere Gesamtpaket. Ansonsten hätten wir Beta2000 anstatt VHS oder Firewire anstatt USB. ;)

Und zweitens, es geht hier um Webvideos. Diese sollen wohl keine BR-Qualität erreichen und VP8 ist immer noch tendenziell besser als x264 base. Und Letzteres sollte ursprünglich in den HTML-Standard hinein. VP8 bringt also für Webvideos eine bessere Qualität.

Mag ja sein, dass die höheren Qualitätsstufen von x264 besser sind. Sie sind aber teurer. AFAIK werden jetzt schon bei Videos ab 10 Minuten Länge Lizenzgebühren fällig.

[(del)]

VP8 sollte laut On2 natürlich mal wieder alles besser machen. Stimmt aber nicht.Ich bin schon sehr überzeugt davon, daß Google ganz genau wußte was sie da kaufen.

[san.salvador]

[...]

Mag ja sein, dass die höheren Qualitätsstufen von x264 besser sind. Sie sind aber teurer. AFAIK werden jetzt schon bei Videos ab 10 Minuten Länge Lizenzgebühren fällig.

... weshalb Videos mit mehr als zehn Minuten auf youtube recht selten sind. ;)

[Pinoccio]

AFAIK werden jetzt schon bei Videos ab 10 Minuten Länge Lizenzgebühren fällig.12 Minuten (http://blog.fefe.de/?ts=b5219580) (Warum auch immer ...)

mfg

[steve.it]

Hey Steve,
What did you make of the recent VP8 announcement?

Die (angebliche) Antwort gibt es hier: http://www.theregister.co.uk/2010/05/20/jobs_on_vp8/

[SavageX]

Finde ich nicht. Der Autor hat Ahnung. VP8 sollte laut On2 natürlich mal wieder alles besser machen. Stimmt aber nicht.

Der Autor ist höchst-H.264 verhaftet und hat neigt zu Troll-Mentalität ("AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!", "the assembly is clearly written by retarded monkeys"). Natürlich hat er Ahnung von H.264, aber er nimmt den Mund schon ziemlich voll, was z.B. die H.264 Patente und ihre Anwendung auf VP8 betrifft. Er ignoriert die Details (kleine Änderungen machen *den* Unterschied) und geht anscheinend davon aus, dass weder On2 noch Google mal in die H.264 Patentpools geguckt hat, was ich ziemlich lächerlich finde.

Die ordentlichen Sachen sind natürlich von H.264 nur schlecht kopiert, was abweicht ist immer eine schlechte Wahl.

Ich denke (mein Bauchgefühl, keine Zahlen!) er überschätzt den Aufwand für die adaptive Quantisierung über die Segmente und glaube, dass man damit halbwegs gut leben kann - zumal man durch den eingekauften Overhead wenigstens auch den Loop-filter gleich mit einstellen kann. Die Definition für die Segmente sollte für die Entropiekodierung gut packbar sein, da hier in der Regel nur Deltas zu den Basiswerten angeben werden, die üblicherweise klein sein dürften.

Er verschweigt, dass man auch in VP8 einen "kleinen, armen Bruder" von B-Frames halbwegs billig hinbekommt: Einen zukünftigen Frame codieren, frame_display auf false setzen, dann Flags setzen, um diesen Frameinhalt nach altref zu kopieren und fertig ist der Referenzframe für Vorwärtsprädiktion. Wenn dann der zukünftige Frame kommt: Einfach ohne Änderungen von altref kopieren. Vermutlich nicht so effizient wie "echte" B-Frames, aber bestimmt nützlich, zumal sich die Referenzframes sehr flexibel updaten lassen.

Er beschwert sich über die Geschwindigkeit, dabei steht schon auf der Homepage von WebM, dass hier noch Änderungen ausstehen. "VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much." - auf welcher Basis ist er sich da sicher?

So oder so: Schon ein kostenfreier Codec auf H.264 Baseline oder VC-1 Augenhöhe ist ein enormer Zugewinn für das Web. Das ist schon ein ziemlich großer kleinster gemeinsamer Nenner ;-)

Edit: Oh, und mit der Qualität von x.264 im Baselineprofil ist man natürlich schon mitten im Terrain anderer H.264 Encoder. Für gratis nicht schlecht.

[Ganon]

Er will ja nicht sagen, dass VP8 jetzt dermaßen schlecht ist. Er widerspricht einfach nur On2/Google, dass VP8 >deutlich besser< als H.264 sei.

Sollte VP8 wirklich "frei" (so weit es halt geht) von Patenten sein, und somit auch auf YouTube Videos länger als 10min sein, dann hat doch sicher niemand was dagegen. Aber auch diese Frage ist ja noch nicht geklärt, nicht mal Google garantiert es.

[SavageX]

Sollte VP8 wirklich "frei" (so weit es halt geht) von Patenten sein, und somit auch auf YouTube Videos länger als 10min sein, dann hat doch sicher niemand was dagegen. Aber auch diese Frage ist ja noch nicht geklärt, nicht mal Google garantiert es.

http://www.theregister.co.uk/2010/05/20/google_confident_on_vp8_and_patents/


Today, when The Reg asked if VP8 was vulnerable to patent attack, Google product manager Mike Jazayeri indicated this isn't a big concern for the company.

"We have done a pretty through analysis of VP8 and On2 Technologies prior to the acquisition and since then, and we are very confident with the technology and that's why we're open sourcing," he said.



Eine absolute Garantie gibt niemand für irgendeinen Codec, aber zumindest ist Google sicherlich besser als viele anderen Firmen in der Lage, sich im Falle des Falles gütlich zu einigen (oder alternativ den Gegner auseinanderzunehmen).

Eine "12-Minuten-Beschränkung" wie bei H.264 gibt es selbstverständlich nicht - dafür müsste ja erstmal ein Claim von ausserhalb auftauchen (viel Spass mit Google) und sollte sich Google nicht erfolgreich verteidigen können, dann müssten Lizenzbedingungen ausgehandelt werden, welche dann eine entsprechende Klausel enthalten müssten. Ich vermute, dass Google eher das Format abändert, als sowas mitzumachen.

[svenw]

IMHO ist die resultierende Größe eh bei weitem nicht mehr so wichtig wie früher. Plattenplatz kostet wenig und Traffic auch. Natürlich ließe sich mit h264 auch da sparen, aber falls Youtube irgendwann Gebühren für h264 zahlen müßte dürfte sich der Aufwand für VP8 innerhalb von 2 Tagen rechnen. :tongue:

Die Unterschiede zwischen h264 und VP8 sind klein aber vorhanden, nur sieht man sie wirklich? Auf einem Standbild sehe ich sie, aber in einem bewegten Film vielleicht sogar auf einem Handy oder anderem mobilen Teil? Ich glaube kaum. Von normalen Betrachtungsabständen bei Fernsehern kann man ja schon prinzipiell keine Pixel mehr unterscheiden und ob man da noch was sieht? Leute geben auch x-tausend Euro für Mega-Boxen und anderen Kram aus und sind dennoch nicht in der Lage gut komprimierte Musik vom Original verläßlich zu Unterscheiden. VP8 ist neu und man mag über Google sagen was man will, von Software verstehen sie was. Laß deren Progger erst mal über den Code rübergehen und dann sehen wir weiter. BTW: an der Verbesserung von h264 wird gearbeitet und nach VP8 wir VP9 kommen (oder wie immer der dann heißt).

[Ganon]

BTW: an der Verbesserung von h264 wird gearbeitet und nach VP8 wir VP9 kommen (oder wie immer der dann heißt).

Du vergisst das Patent-Problem. Es wird schon ziemlich schwer werden, den Codec weiterzuentwickeln, ohne Patente zu verletzten. Nicht umsonst ist die "Spezifikation" festgesetzt ohne wenn und aber.

[SavageX]

Du vergisst das Patent-Problem. Es wird schon ziemlich schwer werden, den Codec weiterzuentwickeln, ohne Patente zu verletzten.

Schwer ja, unmöglich nein. On2 hat bisher höchst erfolgreich gearbeitet (keine einzige Patentklage, obwohl z.B. VP6 auf praktisch jedem PC zu finden ist) und jetzt brechen die Jahre an, in denen gehäuft MPEG-Patente ablaufen.

Nicht umsonst ist die "Spezifikation" festgesetzt ohne wenn und aber.

Jein. VP8.0 ist fest, aber auf der Entwicklerliste wird durchaus erwägt kleinere Modifikationen vorzunehmen (derzeit vornehmlich kleine Sachen), wenn es sich lohnt.

[Avalox]

Der Autor ist höchst-H.264 verhaftet und hat neigt zu Troll-Mentalität ("AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!", "the assembly is clearly written by retarded monkeys"). Natürlich hat er Ahnung von H.264, aber er nimmt den Mund schon ziemlich voll,

Er ist Student im 8. Trimester. Das was er dort macht ist eine Initiativbewerbung. Welche bestimmt mit ein paar Lösungsvorschlägen, zu den von ihn gesehenen Problemen noch besser ankommen würde.


Die Bedeutung des Themas als solches wird ja ausgezeichnet unterlegt, von denjenigen welche nun alle diese Leistung kommentieren.

[steve.it]

Google’s “Royalty-Free” WebM Video May Not Be Royalty-Free For Long
"Indeed, Larry Horn, CEO of MPEG LA, the consortium that controls the AVC/H.264 video standard, tells me that the group is already looking at creating a patent pool license for VP8."
http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long/

[aths]

Der Autor ist höchst-H.264 verhaftet und hat neigt zu Troll-Mentalität ("AAAAAAAGGGGGGGGGGGGGHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!", "the assembly is clearly written by retarded monkeys"). Natürlich hat er Ahnung von H.264, aber er nimmt den Mund schon ziemlich voll, was z.B. die H.264 Patente und ihre Anwendung auf VP8 betrifft. Er ignoriert die Details (kleine Änderungen machen *den* Unterschied) Die Bildqualität wird bei halbwegs brauchbarem Kodierer primär von der grundlegenden Idee bestimmt, weniger von Details.

Die ordentlichen Sachen sind natürlich von H.264 nur schlecht kopiert, was abweicht ist immer eine schlechte Wahl.Er begründet warum es schlechter ist oder gibt zu wenn VP8 in einem Detail besser ist.

Ich denke (mein Bauchgefühl, keine Zahlen!) er überschätzt den Aufwand für die adaptive Quantisierung über die Segmente und glaube, dass man damit halbwegs gut leben kann - zumal man durch den eingekauften Overhead wenigstens auch den Loop-filter gleich mit einstellen kann. Die Definition für die Segmente sollte für die Entropiekodierung gut packbar sein, da hier in der Regel nur Deltas zu den Basiswerten angeben werden, die üblicherweise klein sein dürften.Adaptive Quantisierung ist der Bringer. Das erkannte ich als ich mich 2005 im Zuge von Texturkomprimierung allgemein mit Bildkomprimierung beschäftigte (allerdings ging es um Standbilder.) Adaptive Quantisierung erfordert dass der Faktor pro Tile mitgespeichert wird aber die Bildqualität steigt erheblich.

Er verschweigt, dass man auch in VP8 einen "kleinen, armen Bruder" von B-Frames halbwegs billig hinbekommt: Einen zukünftigen Frame codieren, frame_display auf false setzen, dann Flags setzen, um diesen Frameinhalt nach altref zu kopieren und fertig ist der Referenzframe für Vorwärtsprädiktion. Wenn dann der zukünftige Frame kommt: Einfach ohne Änderungen von altref kopieren. Vermutlich nicht so effizient wie "echte" B-Frames, aber bestimmt nützlich, zumal sich die Referenzframes sehr flexibel updaten lassen.Die Idee von B-Frames verstehe ich so, dass man Dinge aus dem nächsten I-Frame nutzen kann. Es entfällt doppelte Speicherung. Deine "einfache" Idee, B-Frames zu emulieren kommt mir nicht gerade einfach vor.

Er beschwert sich über die Geschwindigkeit, dabei steht schon auf der Homepage von WebM, dass hier noch Änderungen ausstehen. "VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much." - auf welcher Basis ist er sich da sicher?Er hat die Specs gelesen die zum Großteil aus Code besteht und kann das zukünftige Optimierungspotenzial abschätzen.

So oder so: Schon ein kostenfreier Codec auf H.264 Baseline oder VC-1 Augenhöhe ist ein enormer Zugewinn für das Web. Das ist schon ein ziemlich großer kleinster gemeinsamer Nenner ;-)

Edit: Oh, und mit der Qualität von x.264 im Baselineprofil ist man natürlich schon mitten im Terrain anderer H.264 Encoder. Für gratis nicht schlecht.Ohne adaptive Quantisierung werden wir weiterhin viele verwaschene Stellen haben wie in Youtube und anderen Plattformen sichtbar.

[SavageX]

Adaptive Quantisierung ist der Bringer. Das erkannte ich als ich mich 2005 im Zuge von Texturkomprimierung allgemein mit Bildkomprimierung beschäftigte (allerdings ging es um Standbilder.) Adaptive Quantisierung erfordert dass der Faktor pro Tile mitgespeichert wird aber die Bildqualität steigt erheblich.


VP8 hat adaptive Quantisierung natürlich vorgesehen und im Gegensatz zum Blogautor bin ich nicht der Meinung, dass es zu indirekt drangeflanscht ist. Nun kannst Du natürlich sagen "der Autor hat aber Ahnung", aber er hat vor allem Ahnung von H.264. Die Leute bei On2 sind keine Idioten und kennen ihre Codecs natürlich auch genau - und die sind natürlich von der Anwendbarkeit von AQ überzeugt, sonst stünde es nicht prominent in der Spezifikation.


Die Idee von B-Frames verstehe ich so, dass man Dinge aus dem nächsten I-Frame nutzen kann. Es entfällt doppelte Speicherung. Deine "einfache" Idee, B-Frames zu emulieren kommt mir nicht gerade einfach vor.


Hmmm? Ist doch sehr einfach: Zukünftigen Frame kodieren aber nicht anzeigen und nur als Referenz vorsehen. Ist direkt im Bitstream vorgesehen.


Er hat die Specs gelesen die zum Großteil aus Code besteht und kann das zukünftige Optimierungspotenzial abschätzen.


Die Spezifikation enthält stellenweise unoptimierten Code, um Sachverhalte klarer darzustellen.


Ohne adaptive Quantisierung werden wir weiterhin viele verwaschene Stellen haben wie in Youtube und anderen Plattformen sichtbar.

VP8 unterstützt adaptive Quantisierung. Wie gesagt, ich bin nicht der Meinung, dass dies zu ineffizient gelöst wurde.

[(del)]

Darf ich am Ende nochmals kurz einwerfen, daß es darum geht ein leistungsfähiges Bitstreamformat zu schaffen (nach 1/4 des Contents irgendwo im letzten Viertel klicken und es geht nach einer Sekunde weiter), bei dem man nur unwesentlich niedriger kodieren muß, um an h.264 Baseline ranzukommen und man den Dekoder noch um ~10% effizienter programmieren sollte? Bevor man es ganz den GPUs oder dafür zurecht gelegten OMAPs überläßt?
Danke :rolleyes:

EOD

[_DrillSarge]I[]

"Indeed, Larry Horn, CEO of MPEG LA,
nuff said. die scheinen auch voll nett zu sein:

First, the MPEG-LA would engage with independent experts to ensure only essential patents would be placed in the MPEG-2 pool. They told the DOJ that the MPEG-2 pool constituted of 53 essential patents. Second, independent experts would "weed out nonessential patents" from the pool. Third, licensing terms would be "fair, reasonable, and nondiscriminatory".

Nero claims none of these safeguards were honoured, and here's where it gets juicy; "absolute power has corrupted the MPEG-LA absolutely", according to Nero. First of all, the so-called independent expert was anything but independent. The expert helped form the MPEG-LA, helped in drafting the first MPEG-LA licensing agreements, answers questions from licensees on behalf of the MPEG-LA, has attended business settlement meetings on behalf of the MPEG-LA, and has testified before US congress on behalf of the MPEG-LA. Heck, he is listed on the MPEG-LA website as "MPEG-LA's US patent counsel".

Nero also claims that the MPEG-LA has unlawfully extended its patent pools by adding non-essential patents to the MPEG-2 patent pool. Even though the MPEG-LA told the DOJ there were only 53 essential MPEG-2 patents, the non-independent expert added round and about 800 more patents to the pool, extending the duration of the patent pool, since the old, 53 essential patents expired.
http://www.osnews.com/story/23346/Nero_Files_Antitrust_Case_Against_MPEG-LA
;D

[(del)]

Da muß ich aber nochmal =)

GEIL! Schönes Vorspiel gegen die Patent-Trolle vor der (wohl anstehenden) VP8-Schlacht. Das wird nachhaltig wirken :up:

[aths]

VP8 hat adaptive Quantisierung natürlich vorgesehenJa über Umwege. Mir sieht es nicht so aus als ob der Encoder das effizient oder überhaupt nutzt. Aber ok, hoffen wir dass die vorgesehen Möglichkeit der adaptiven Quantisierung doch genutzt wird. Im Zusammenhang mit gesenkter räumlicher Farbauflösung ist das der psychovisuelle Trick überhaupt.

[Pinoccio]

sOT, aus heises Artikel zum Fall Nero vs MPEG-LA (http://www.heise.de/newsticker/meldung/Nero-verklagt-MPEG-LA-wegen-Kartellrechtsverletzung-1006637.html):
So umfasse [...] der unter anderem für HDTV, Blu-ray Disc und Internetvideo verwendete H.264 sogar schon 1300 [Patente].
Ich wünsche Google viel Kraft und Erfolg, ich bin mir sicher, daß es genug Richter gibt, die bei VP8/webM was auszusetzen finden. :-(

mnfg

[basti333]

Diese Patente auf codecs oder auf bestimmte mathemetische Algorhytmen in Codecs, dass sind doch alles Software-Patente oder?

[san.salvador]

Algorithmen, ja.

[basti333]

Demnach geht es bei diesen bescheuerten Patent-Streitereien nur um den "Leit"-Markt USA. Warum gibt es dann keine angepassten Brower für den Rest der Welt, halt Brower die jeden gängigen codec Unterstützen :confused:

[Pinoccio]

Demnach geht es bei diesen bescheuerten Patent-Streitereien nur um den "Leit"-Markt USA. Warum gibt es dann keine angepassten Brower für den Rest der Welt, halt Brower die jeden gängigen codec Unterstützen :confused:Nein. Siehe u. a.
heise.de: Bundesgerichtshof ebnet Weg für Softwarepatente (http://www.heise.de/newsticker/meldung/Bundesgerichtshof-ebnet-Weg-fuer-Softwarepatente-1003190.html) oder heise.de: Europäisches Patentamt hält Kurs bei Softwarepatenten (http://www.heise.de/newsticker/meldung/Europaeisches-Patentamt-haelt-Kurs-bei-Softwarepatenten-999795.html). Noch mehr bei der ffii (http://patinfo.ffii.org/heise.html).

mfg

[basti333]

Nein. Siehe u. a.
heise.de: Bundesgerichtshof ebnet Weg für Softwarepatente (http://www.heise.de/newsticker/meldung/Bundesgerichtshof-ebnet-Weg-fuer-Softwarepatente-1003190.html) oder heise.de: Europäisches Patentamt hält Kurs bei Softwarepatenten (http://www.heise.de/newsticker/meldung/Europaeisches-Patentamt-haelt-Kurs-bei-Softwarepatenten-999795.html). Noch mehr bei der ffii (http://patinfo.ffii.org/heise.html).

mfg

Die Urteile mögen den Weg ebnen, aber sie sorgen ja nicht dafür das wir von heute auf morgen US-Verhältnisse haben.

[SavageX]

Nein, MPEG-Patente laufen unter dem Label der "Verfahrenspatente". Unabhängig davon, was mit "Softwarepatenten" (genaue Definition?) passiert sind sie so oder so auch hier schon gültig und werden auch eingetrieben.

[SavageX]

sOT, aus heises Artikel zum Fall Nero vs MPEG-LA (http://www.heise.de/newsticker/meldung/Nero-verklagt-MPEG-LA-wegen-Kartellrechtsverletzung-1006637.html):
So umfasse [...] der unter anderem für HDTV, Blu-ray Disc und Internetvideo verwendete H.264 sogar schon 1300 [Patente].
Ich wünsche Google viel Kraft und Erfolg, ich bin mir sicher, daß es genug Richter gibt, die bei VP8/webM was auszusetzen finden. :-(

In diesen Pools schwimmt auch viel Müll herum, die zum Kern nichts beizutragen haben. Es ist ja gerade ein Vorwurf von Nero, dass die Patentpools (anders als versprochen) nicht nur die tatsächlich notwendigen Sachen enthalten, sondern künstlich mit uninteressantem Zeug aufgeblasen wurden.

Gerade über die Patente, die im Pool der MPEG-LA herumschwirren, mache ich mir die wenigsten Sorgen. Diese Patente wurden ganz sicherlich abgeklopft.

[basti333]

Dann scheint die klage von Nero ja gute chancen zu haben, auch wenn es bis zu einer rechtskräftigen entscheidung noch jahre dauern könnte und es sowieso nichts grundsätzliches ändern würde.

[SavageX]

Dann scheint die klage von Nero ja gute chancen zu haben, auch wenn es bis zu einer rechtskräftigen entscheidung noch jahre dauern könnte und es sowieso nichts grundsätzliches ändern würde.

Na, über die Erfolgsaussichten möchte ich lieber keine Aussagen treffen ;)

Es zeigt zumindest, dass die MPEG-LA keineswegs Everybody's Darling ist.

[pest]

sehe ich das richtig, VP8 unterstützt keine B-Frames? LOL

[Pinoccio]

sehe ich das richtig, VP8 unterstützt keine B-Frames? LOLSo halb, siehe oben (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8038997#post8038997).

mfg

[pest]

aber extrem halb, das wären dann sowas wie F(orward)-Frames

edit1: und fehlende Weighted-Prediction tut den Rest, nunja


Adaptive Quantisierung ist der Bringer.


AQ ist erst einmal eins, verdammt schwierig zu implementieren wenn es immer funktionieren soll. Selbst x264 hatte bis vor einiger Zeit kein brauchbares AQ.
edit2: "normales" AQ führt außerdem zu Blocking innerhalb von texturarmen Flächen


Die Idee von B-Frames verstehe ich so, dass man Dinge aus dem nächsten I-Frame nutzen kann.


das geht etwas weiter. man kann B-Frames, vor allem höher Quantisieren. In H.264 können B-Frames auch andere B-Frames referenzieren usw.


Ohne adaptive Quantisierung werden wir weiterhin viele verwaschene Stellen haben wie in Youtube und anderen Plattformen sichtbar.


die Qualität hängt entscheident vom n-Pass-Verfahren ab. Das ist der Schlüssel, und da lässt sich x264 nicht lumpen. AQ ist nettes Feature.

[(del)]

Nochmal kurz. Wegen Heise, Nero, usw. Obwohl alle es bereits wissen, traut sich im deutschsprachigen Raum kaum jemand die News zu bringen. Das ist Internet...

@pest
Das sind erfreuliche Nachrichten. VP8 braucht mal bisschen mehr kbits und (nach der Bereinigung des Codes, schätze ich) wenige % mehr Leistung, um an die Baseline von h.264 zu kommen. Das weiß man jetzt schon bisschen länger, mit heutigem Tag. Jetzt wird mir langsam klar warum genau. Danke.
Ich dachte schon die haben echt alle skills implementiert und sind immernoch soviel schlechter als AVC. So geht es aber.

[(del)]

Mal ne Frage am Rande zu dem ganzen Zeug. Wenn ich z.B. ein Desktopvideo (meine "Copyrights") erstellt habe, um jemanden "live" zu zeigen wie irgendwas funzt und es nach Megaupload oder Rapid oder sonstwo schiebe, damit er sich die 50 MB saugen kann, darf ich das mit x264 kodieren? Oder verstoße ich damit schon gegen die Lizenbedingungen von MPEG LA?

[SavageX]

Für x264 muss wie jeder für jeden anderen H.264-Encoder auch eine Patentlizenz erworben werden (ähnliche Situation wie bei XviD). Die MPEG-LA lizenziert allerdings nicht an Privatpersonen.

Wenn Du ganz sicher gehen willst: Nimm den kostenlosen H.264-Kodierer von DivX (würg). Der ist natürlich nicht so pralle wie x264, aber DivX Networks drückt für Dich die Lizenzgebühren ab.

[Pinoccio]

Mal ne Frage am Rande zu dem ganzen Zeug. Wenn ich z.B. ein Desktopvideo (meine "Copyrights") erstellt habe, um jemanden "live" zu zeigen wie irgendwas funzt und es nach Megaupload oder Rapid oder sonstwo schiebe, damit er sich die 50 MB saugen kann, darf ich das mit x264 kodieren? Oder verstoße ich damit schon gegen die Lizenbedingungen von MPEG LA?IMHO nein. Lizenzbestimmungen (http://www.mpegla.com/main/programs/AVC/Documents/AVC_TermsSummary.pdf).

mfg

[(del)]

Nochmal. Ich schreibe kein x264, ich kompiliere kein x264, ich hab keine Vidseite wo das Video zum Abspielen bereitsteht, ich kriege keinen einzigen Cent dafür, MPEG LA hat nicht vor sich damit zu beschäftigen.

Ich lade eine h.264-Datei als Archiv nach FileuploadBlahblah, damit ein Bekannter aus Bremen sich das saugen und angucken kann und es ist nicht klar, ob irgendein Spacken (oder Fileupload selbst) mich nicht anschwärtzt (WTF?) und MPEG LA mir an die Karre pisst?

@Pinoccio
Das ist mir grad zu hoch. Welche Passage meinst du? Mir fiel dazu so als erstes selective enforcement ein (?) :|

@SavageX
Ich kann/soll DivX anschreiben, daß ich vor habe eine Datei zu dem und dem Filehoster zu laden und die klären das für mich, sagen mir bescheid und ich kann das dann schieben und dem Kumpel bescheid sagen?! :ucrazy4:

Was ist das für eine kranke surreale Scheiße?

[Pinoccio]

@Pinoccio
Das ist mir grad zu hoch. Welche Passage meinst du? Mir fiel dazu so als erstes selective enforcement ein (?) :|Meiner bescheidnene Meinung nach musst du keine Lizenzgebühren bezahlen, so würde ich die Lizenzbestimmungen lesen - aber ich bin auch kein Anwalt und weiß, daß ich nichts weiß.
Klarer?
(mehr Stoff z. B. bei streamingmedia.com (http://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=65357&PageNum=1))

mfg

[SavageX]

@SavageX
Ich kann/soll DivX anschreiben, daß ich vor habe eine Datei zu dem und dem Filehoster zu laden und die klären das für mich, sagen mir bescheid und ich kann das dann schieben und dem Kumpel bescheid sagen?! :ucrazy4:

Was ist das für eine kranke surreale Scheiße?

Nö, was ich meine: Der DivX-Encoder ist ordentlich bei der MPEG-LA lizensiert. Um eventuelle Vertriebsgebühren musst Du Dich aber selber kümmern.

Da der Vertrieb aber kostenfrei geschieht, sollten da keine Gebühren anfallen.

[(del)]

Ich hab beschlossen mich genauso drum zu kümmern wie Google...

Vielleicht werde ich mal berühmt als Ikone und Galeonsfigur im Kampf gegen diese Trolle :up:

[DanMan]

Präsentation über WebM. (http://code.google.com/intl/de-DE/events/io/2010/sessions/webm-open-video-playback-html5.html)

[SavageX]

WebM nun in Firefox nightlies: http://blog.pearce.org.nz/2010/06/webm-has-landed-on-firefox-nightlies.html

[(del)]

Hab mir mit dem letzten 6er Chromium auf Youtube paar WebM/VP8 Sachen angeguckt. Wie ichs mir dachte, das Gequatsche über die Quali ist bei 720p egal. Es sieht sehr gut aus. Auch das "Reiten" mit dem Schieber war ok. Bild sprang sauber und schnell hin und her. Ton kam sofort nach, in guter Quali. Alles gut.

Komisch nur, daß die Beispiele alle 360 und 720p haben. Was ist mit 480? :|

Was mir aber wirklich auffiel, und das übel, war die CPU-Auslastung. Auf einem 3.9 Ghz E8400... :freak:

[SavageX]

Was mir aber wirklich auffiel, und das übel, war die CPU-Auslastung. Auf einem 3.9 Ghz E8400... :freak:

Alle aktuellen Browser skalieren <video> rein über Software, und nicht immer gut optimiert.

[Konami]

Komisch nur, daß die Beispiele alle 360 und 720p haben. Was ist mit 480? :|
http://www.abload.de/img/webmqh5h.jpg

;)

[Deinorius]

Was hat das mit dem Container zu tun? WebM läuft ja mit MKV. Ist 480p etwa auf MP4 begrenzt?

[Konami]

Was hat das mit dem Container zu tun? WebM läuft ja mit MKV. Ist 480p etwa auf MP4 begrenzt?
Whatever, ich hab jetzt einfach mal den Screenshot aus der Google I/O reingestellt.
(Soll heißen: Keine Ahnung warum 480p nicht geht - ist halt so. X-D)

[Deinorius]

Aha, komische Willkürlichkeit.

[(del)]

@SavageX
Läuft denn beim 10.0 Flash und 720P etwas auf der GPU? Auf einer 3870?

@Deinorius
Mein Reden. Statt das Zeug endlich komplett auszurotten und SD mit 480p anzubieten gibts 2010 WebM, mit einer 360p Spezifikation. Der Lacher der Woche.

[SavageX]

@SavageX
Läuft denn beim 10.0 Flash und 720P etwas auf der GPU? Auf einer 3870?


Nö, aber Flash ist keine HTML-Engine, der man mal eben Video angewöhnt hat ;)

Adobe hat schon ein bisschen Erfahrung damit, Grafik schnell in Software zu zeichnen.


@Deinorius
Mein Reden. Statt das Zeug endlich komplett auszurotten und SD mit 480p anzubieten gibts 2010 WebM, mit einer 360p Spezifikation. Der Lacher der Woche.

Soll ja noch Leute mit eingeschränkter Bandbreite geben und WebM gibt es ja demnächst auch mit Android...

Zumal man YouTube noch ein bisschen Zeit gönnen muss, bis alle Videos in allen Varianten neu kodiert sind. Es ist ja schon schlimm genug, dass die Varianten, die YouTube zur WebM-Vorstellung kodiert hat, von http://xiphmont.livejournal.com/51160.html betroffen sind. Man stelle sich vor, die hätten schonmal den ganzen Katalog mit allen Geschmacksrichtungen kodiert.

[(del)]

Nö, aber Flash ist keine HTML-Engine, der man mal eben Video angewöhnt hat ;)

Adobe hat schon ein bisschen Erfahrung damit, Grafik schnell in Software zu zeichnen.Meine Rede. Da ich zum Glück keine Softinge bin berühren mich die Gründe auch garnicht so sehr wie das, daß es nicht so bleibt, wenn wir Flashvids zum Friedhof tragen.
Eine Aufbruchstimmung kriegt man davon jedenfalls nicht.

Soll ja noch Leute mit eingeschränkter Bandbreite geben und WebM gibt es ja demnächst auch mit Android...Das kommt ja nicht per GSM an. Und die Displayauflösung... Ich weiß nicht, ob es mich freut, daß die sich bei WebM noch so um mein W995i kümmern :|

[bluey]

http://blogs.gnome.org/rbultje/2010/06/27/googles-vp8-video-codec/

Tja ging schnell.

[(del)]

Meint fefe ;) Ist wegen "Wegflug" schon einige Male gefixt worden. So einfach ist das alles nicht. Der aktuelle Build tuts aber brauchbar.

Ich halte das vor allem für Mozilla-basierte und Chromium wichtig. Sie dürfen damit copy&paste spielen =)

[(del)]

Geht doch, wenn echte Experten sich damit doch noch beschäftigen. War mir irgendwie klar, daß er alleine fürs Rumjammern zu ehrgeizig ist ;)

http://x264dev.multimedia.cx/?p=499

[h'lore]

Geht doch, wenn echte Experten sich damit doch noch beschäftigen. War mir irgendwie klar, daß er alleine fürs Rumjammern zu ehrgeizig ist ;)Weniger spannend, die Diagramme. Viel eher würde mich interessieren, wie der ffvp8 auf ARM performt. Google hatte ja versprochen, dass der libvpx-Decoder hierbei ziemlich stark sei. Getestet hab ich das aber noch nicht.

[DanMan]

Weniger spannend, die Diagramme.
Was? Immerhin macht es auf einer Atom CPU den Unterschied zw. flüssig und stotternd abspielend bei einem 1080p Video. Das find ich schon interessant.

[(del)]

Wollt ich doch gerade schreiben. Die X-Achse der Diagramme fängt mit 0 an, meine Herren.

Spannender finde ich aber, daß Kollege Fachmann vor nicht allzulanger Zeit so klang, als wenn man dem Dekodieren nicht mehr helfen könnte ;) Wahrscheinlich hat ihm dann einer erklärt, daß VP8 keine 100%ige Konkurrenz zu seinem geleibten x264 sein will.

[Rooter]

Was? Immerhin macht es auf einer Atom CPU den Unterschied zw. flüssig und stotternd abspielend bei einem 1080p Video. Das find ich schon interessant.
Wollt ich doch gerade schreiben. Die X-Achse der Diagramme fängt mit 0 an, meine Herren.Okay, er ist schneller, aber ein Weltwunder stellen die Zahlen ja jetzt noch nicht gerade dar, zumindest nicht auf dem Atom:

Atom N270 (1.6Ghz), Linux, 32-bit:
Parkjoy ffvp8: 15.29 +/- 0.01
Parkjoy libvpx: 12.46 +/- 0.01
Sintel ffvp8: 26.87 +/- 0.05
Sintel libvpx: 20.41 +/- 0.02

MfG
Rooter

[Pinoccio]

Okay, er ist schneller, aber ein Weltwunder stellen die Zahlen ja jetzt noch nicht gerade dar, zumindest nicht auf dem Atom:

Atom N270 (1.6Ghz), Linux, 32-bit:
Parkjoy ffvp8: 15.29 +/- 0.01
Parkjoy libvpx: 12.46 +/- 0.01
Sintel ffvp8: 26.87 +/- 0.05
Sintel libvpx: 20.41 +/- 0.02Ja, aber fürden ATOM ist noch nicht optimiert worden, das wird vermutlich noch deutlich schneller werden.

mfg

[Coda]

Spannender finde ich aber, daß Kollege Fachmann vor nicht allzulanger Zeit so klang, als wenn man dem Dekodieren nicht mehr helfen könnte
Red kein Blech. Das hat er nie gesagt.

In terms of decoding speed I’m not quite sure; the current implementation appears to be about 16% slower than ffmpeg’s H.264 decoder (and thus probably about 25-35% slower than state-of-the-art decoders like CoreAVC). Of course, this doesn’t necessarily say too much about what a fully optimized implementation will reach, but the current one seems to be reasonably well-optimized and has SIMD assembly code for almost all major DSP functions, so I doubt it will get that much faster.

I would expect, with equally optimized implementations, VP8 and H.264 to be relatively comparable in terms of decoding speed. This, of course, is not really a plus for VP8: H.264 has a great deal of hardware support, while VP8 largely has to rely on software decoders, so being “just as fast” is in many ways not good enough. By comparison, Theora decodes almost 35% faster than H.264 using ffmpeg’s decoder.

[SavageX]

Red kein Blech. Das hat er nie gesagt.

Nun, gelegentlich kann man aber schon ein "viel schneller geht es nicht" herauslesen.

Decoder: Seems to be straightforward enough. Nothing jumped out at me as particularly bad, slow, or otherwise, besides the code quality issues mentioned above.

edit:


VP8, as a decoder, decodes even slower than ffmpeg’s H.264. This probably can’t be improved that much; VP8 as a whole is similar in complexity to H.264.


edit2: Natürlich ist es fantastisch, dass er nicht "nur nörgelt", sondern aktiv mitentwickelt.

[Coda]

Man sollte das ganze auch im Kontext sehen :rolleyes:

libvpx ist vor allem lahm, weil es alles als Multipass macht. Natürlich gibt's dann an den einzelnen Passes nicht so unglaublich viel zu meckern.

Das Fazit ist für mich dagegen eindeutig. Aber interpretiert rein was ihr wollt.

[DanMan]

Atom N270 (1.6Ghz), Linux, 32-bit:
Parkjoy ffvp8: 15.29 +/- 0.01
Parkjoy libvpx: 12.46 +/- 0.01
Sintel ffvp8: 26.87 +/- 0.05
Sintel libvpx: 20.41 +/- 0.02
Ja, kein Weltwunder, aber beim Sintel Trailer macht es einen spürbaren Unterschied.

[(del)]

Das Fazit ist für mich dagegen eindeutig. Aber interpretiert rein was ihr wollt.Man sollte das ganze auch im Konterxt sehen

[Coda]

Was genau ist daran noch im Context zu sehen?
Overall verdict on the VP8 video format
...
I would expect, with equally optimized implementations, VP8 and H.264 to be relatively comparable in terms of decoding speed.

Eindeutiger geht es doch wohl nicht. Macht euch nicht lächerlich.

[(del)]

Sorry, aber am Anfang des Threads haben die meisten seiner Anbeter den damaligen Review ebenfalls noch so ausgelegt, als wenn es kaum möglich wäre "equally optimized implementations" 2010 zu erreichen. Der Text ist ja auch nicht pure Technik ;)
Hast du da nicht auch selbst bisschen mitgewirkt bei dieser Meinung?

Ich schätze ihm war bei dem Hype wie einigen anderen z.B. hier (du nicht) noch nicht klar, daß es garnicht darum geht x264 nach und nach ad acta zu legen und es eigentlich um eine sinnvolle Koexistenz geht.

Der Meinung bin ich übrigens auch. Da wo man x264 am besten gebrauchen kann führt noch lange kein Weg dran vorbei. Es ist einfach noch viel zu perfekt gegenüber anderen Lösungen =)

Bis später mal.

[Coda]

Ich bin der Meinung, dass VP8 ein ziemlicher Haufen Schrott gegenüber H.264 ist.

Allein was da an Implementierungsdetails nach oben geschwemmt wurde inzwischen lässt mich nur zu dem Schluss kommen, dass On2 hochgradig inkompetent ist und ihre Behauptungen der Qualität gelogen sind.

Aber das darf ja nicht sein, dass der neue tolle "freie" Codec nicht toll ist, und deshalb bezichtigt man den x264-Menschen voreingenommen zu sein. Ist ja auch viel einfacher. Bonuspunkte gibt's dann auch dafür, das immer noch zu behaupten, nachdem sie innerhalb von ein paar Wochen On2 so in Performance zerstört haben, dass sie eigentlich im Boden versinken müssten.

[SavageX]

Ich bin der Meinung, dass VP8 ein ziemlicher Haufen Schrott gegenüber H.264 ist.

Kann man so sehen, muss aber nicht. Da stecken einige "nicht so schön"-Geschichten drin (wobei man es leider der Phantasie überlassen muss zu entscheiden, was nun aus IP-Gründen etwas schräg realisiert oder weggelassen wurde - und was tatsächlich nur ein Versehen ist), aber hier und da sieht man auch neue, gute Ideen.

Ein Codec vom Schlage von VC-1 oder H.264 Baseline für Omme ist jedenfalls nichts worüber man sich verächtlich zeigen muss.



Allein was da an Implementierungsschrott nach oben geschwemmt wurde inzwischen lässt mich nur zu dem Schluss kommen, dass On2 hochgradig inkompetent ist und ihre Behauptungen der Qualität gelogen sind.


Man sollte nicht vergessen, dass libvpx (man achte auf das x) *eigentlich* mehr als nur VP8 erzeugt und dass die herausgegebene Variante in kurzer Zeit heruntergekocht wurde und insgesamt eher einem Spielplatz für Codec-Entwicklung gleicht als einer ausoptimierten Variante.

Ich werfe auch mal kurz die Frage in den Raum, ob das VP8, was veröffentlich worden ist, auch das VP8 ist, was 2008-2009 angedacht wurde. Hier mag jeder seine eigene Antwort finden (meine kann ich nicht preisgeben).

edit: Übrigens ganz interessant, dass alle Codecs, die in einem kommerziellen Umfeld entstanden sind, eher mau gegen x.264 und (seinerzeit) XviD aussehen - und da ist auch VPx bisland keine Ausnahme. Da werden die Prioritäten anders gesteckt.


Aber das darf ja nicht sein, dass der neue tolle "freie" Codec nicht toll ist, und deshalb bezichtigt man den x264-Menschen voreingenommen zu sein. Ist ja auch viel einfacher.

Wirf "uns" nicht alle in einen Topf, da machst Du Dir es zu einfach. Dieser "x264-Mensch" hat gerade übrigens mal eben 10% mehr Speed für meinen Phenom rausgequetscht ;-)

[Coda]

FYI, it seems some of the asm is very badly optimized for Phenom; in 5 minutes I wrote up a patch that made Phenom about ~6% faster, so more should be coming there too.
:rolleyes:

Ein Codec vom Schlage von VC-1 oder H.264 Baseline für Omme ist jedenfalls nichts worüber man sich verächtlich zeigen muss.
Nö, mich stört nur die Flame-Welle gegen die H.264-Entwickler, nur weil er die Wahrheit sagt.

Da werden die Prioritäten anders gesteckt.
Wie denn? Gleich lahm und trotzdem schlechtere Bildqualität?

[SavageX]

:rolleyes:

Heh, er schreibt schnell. Mit ~6% zeigt er sich meiner Ansicht nach übrigens ziemlich bescheiden, auf meiner Kiste steht es ~50 fps vor und ~55 fps nach unser kleinen IRC-Sitzung ;)

[SavageX]

Nö, mich stört nur die Flame-Welle gegen die H.264-Entwickler, nur weil er die Wahrheit sagt.


Kommt halt nicht jeder gut mit "strong opinions" klar ;-)


Wie denn? Gleich lahm und trotzdem schlechtere Bildqualität?


"Es kostet 80% mehr Aufwand, die letzten 10% rauszukitzeln." oder "tut doch". Ungefähr die gleiche Einstellung, die Apples Encoder auszeichnen oder die von DivX. Weiterhin hatte On2 niemals ein wirklich gewichtiges Interesse daran, die Implementierung von VP{n} auszupolieren, weil man für VP{n+1} neue Lizensierungsdeals abschließen konnte. Man mag denken, dass deshalb (eigentlich "tief hängende") Optimierungen gerne mal ins "n+1" Projekt verschleppt wurden.

[(del)]

Ich bin der Meinung, dass VP8 ein ziemlicher Haufen Schrott gegenüber H.264 ist.Weil du vielleicht x264 kennst, nicht aber z.B. den h.264 von Mainactor, als sie noch selbstständig waren ;)

Es geht erstmal noch lange nur um VP8-Baseline und das wird h.264 2010 schon ausreichend packen.

Das Geflamme entstand nur, weil am Anfang weder die einen noch die anderen sich im Klaren waren worum es da überhaupt geht und Leute mit viel Wissen oft eine mangelhafte Sozialkompetenz besitzen und nur strong und strongest kennen. Deswegen auch brauchen wir jetzt nicht wieder von vorne mit "haufen Schrott" anfangen...

Bis die Tage.

[Coda]

Kommt halt nicht jeder gut mit "strong opinions" klar ;-)
Naja, gegen Herrn Linus - C++ führt immer zu schlechtem Code - Torvalds ist er ja harmlos X-D

"Es kostet 80% mehr Aufwand, die letzten 10% rauszukitzeln." oder "tut doch". Ungefähr die gleiche Einstellung, die Apples Encoder auszeichnen oder die von DivX. Weiterhin hatte On2 niemals ein wirklich gewichtiges Interesse daran, die Implementierung von VP{n} auszupolieren, weil man für VP{n+1} neue Lizensierungsdeals abschließen konnte. Man mag denken, dass deshalb (eigentlich "tief hängende") Optimierungen gerne mal ins "n+1" Projekt verschleppt wurden.
Was ich halt schlimm finde, ist dass sie offensichtliche Fehler jetzt im "Standard" haben, weil sie unbedingt bis zur Google I/O damit fertig sein mussten. Das kann doch einfach nicht wahr sein.

[SavageX]

Naja, gegen Herrn Linus - C++ führt immer zu schlechtem Code - Torvalds ist er ja harmlos X-D


Na, dann bietet D_S ja einen seichten Einstieg in diese schöne Welt ;)


Was ich halt schlimm finde, ist dass sie offensichtliche Fehler jetzt im "Standard" haben, weil sie unbedingt bis zur Google I/O damit fertig sein mussten. Das kann doch einfach nicht wahr sein.

Glücklicherweise sind diese Fehler aber jeweils mit einer handvoll Zeilen Code zu behandeln (z.B. das je nach Modus leicht unterschiedliche Zurechtschneiden von Bewegungsvektoren), unterm Strich ist da aber nichts, was den Hals bricht.

Wäre natürlich *schöner* gewesen, wenn man ein kleines Zeitfenster gewährt hätte, um der *Community* Gelegenheit zu geben, ein paar Schönheitsfehler auszubügeln.

Die größte Herausforderung für Google ist insgesamt das Community-Building. Es braucht einige Zeit, um die (vormals auf geschlossen- und verschwiegenhaftigkeit getrimmten) On2-Menschen etwas loszueisen und einen Prozess klarzustellen, wie man gemeinsam nach vorne geht. Zumindest sind Kernentwickler von On2 jetzt im IRC ;-)

[Coda]

Glücklicherweise sind diese Fehler aber jeweils mit einer handvoll Zeilen Code zu behandeln (z.B. das je nach Modus leicht unterschiedliche Zurechtschneiden von Bewegungsvektoren), unterm Strich ist da aber nichts, was den Hals bricht.
Es geht mir eher um den Qualitätsverlust der dadurch entsteht. Das mit dem tauschen der Frames mit dem Resultat dass dann beide Frames gleich sind beispielsweise.

[SavageX]

Es geht mir eher um den Qualitätsverlust der dadurch entsteht. Das mit dem tauschen der Frames mit dem Resultat dass dann beide Frames gleich sind beispielsweise.

Ich meine da eine Änderung in libvpx gesehen zu haben (ich suche noch in den logs, aber vielleicht war es pure Einbildung), die möglich ist, da der Encoder das sowieso nicht macht. D_S hat diese Anomalie aber sowieso unter "Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything" verbucht. Da goldref und altref verschiedene Anwendungsgebiete haben, vertauscht man ihre Inhalte schlicht nicht - üblicherweise tauscht man jeweils einen Buffer (oder beide) mit dem aktuellen Frame aus (was glücklicherweise funktioniert ;) ).

edit: Habe die Änderung nicht gefunden, also wohl Hirngespinst.

Andererseits finde ich im Bitstream guide auch keine "swap" Operation, sondern nur zwei zwei-Bit Flags, die jeweils für goldref und altref anzeigen, ob und womit sie überschrieben werden sollen und ich war sowieso davon ausgegangen, dass die Buffer der Reihe nach umkopiert werden (bzw. einfach die Zeiger umgebogen werden).


edit2: Vielleicht Hirngespinst doch kein Hirngespinst? Zumindest scheint ffvp8 das umtauschen der Referenzframes zu unterstützen:


// check if golden and altref are swapped
if (s->update_altref == VP56_FRAME_GOLDEN &&
s->update_golden == VP56_FRAME_GOLDEN2)
FFSWAP(AVFrame *, s->framep[VP56_FRAME_GOLDEN], s->framep[VP56_FRAME_GOLDEN2]);
else {
if (s->update_altref != VP56_FRAME_NONE)
s->framep[VP56_FRAME_GOLDEN2] = s->framep[s->update_altref];

if (s->update_golden != VP56_FRAME_NONE)
s->framep[VP56_FRAME_GOLDEN] = s->framep[s->update_golden];
}


Oder lese ich das falsch?

[Coda]

Es geht mir um das hier:
Most of the differences aren’t particularly important — they don’t have a huge effect on compression or anything — but make it vastly more difficult to implement a “working” VP8 decoder, or for that matter, decide what “working” really is. For example, Google’s decoder will, if told to “swap the ALT and GOLDEN reference frames”, overwrite both with GOLDEN, because it first sets GOLDEN = ALT, and then sets ALT = GOLDEN. Is this a bug? Or is this how it’s supposed to work? It’s hard to tell — there isn’t a spec to say so. Google says that whatever libvpx does is right, but I doubt they intended this.

[SavageX]

Es geht mir um das hier:

Davon rede ich doch :)

[Peterxy]

Hatte mir heut mal ein VP8 video konvertiert.
Na ja, viel einstellen kann man ja nicht, Geschwindigkeit ist aber okay und Quali irgendwo zwischen xvid und x.264.

Was mich aber irgendwie mal interessieren würde,
womit zum Teufel spielt man die VP8 videos eigentlich ab?

[Habs in nen Matroska gepackt mit nem MP3]
Auf dieser wbem-Page sind so directshow filter, die funzen aber nicht (anscheinend unterstützend die nur wbem + Vorbis, aber auch das wird nicht wiedergegeben). Bei Xiph.org gibts dann noch so en anderes DS Filterpack dafür, damit gibts immerhin im Windowsmedia Player ein Bild aber dummerweise kein Ton.
Auf der Haali Matroska Splitter-Page steht es unterstützt das ganze, damit tut sich aber auch nix.

Hab das ganze Geraffel dann wieder runtergekegelt und einfach den neuen VLC installiert. Ja, der spielt das nun alles brav ab - aber wie kriegt man die VP8 videos denn nun in anderen Playern zu laufen?

Geht das z.Z. noch gar nicht, oder wie? :confused:

[Coda]

http://www.webmproject.org/tools/#directshow_filters

[whatever]

[Habs in nen Matroska gepackt mit nem MP3]
Auf dieser wbem-Page sind so directshow filter, die funzen aber nicht (anscheinend unterstützend die nur wbem + Vorbis, aber auch das wird nicht wiedergegeben)
FYI:
Falls dein Video später direkt im Browser abgespielt werden soll, musst du Vorbis für Audio und webm statt mkv nehmen.

[Peterxy]

http://www.webmproject.org/tools/#directshow_filters
Wie oben geschrieben, die funktionieren nicht mit mkv´s, sondern sind anscheinend nur für webm (VP8 + Vorbis) was etwas "witzlos" ist.

Falls dein Video später direkt im Browser abgespielt werden soll,
Nein sollen sie nicht, sondern einfach nur im Media Player abspielbar sein was aber offensictlich etwas problematisch ist. Macht mir en sehr unfertigen Eindruck das ganze.

Normall ist sowas imo nicht das man zur Videolan Page gehen muß - weil anscheinend nur deren integrierter Filter auch wirklich funktioniert.

[SavageX]

Wie oben geschrieben, die funktionieren nicht mit mkv´s, sondern sind anscheinend nur für webm (VP8 + Vorbis) was etwas "witzlos" ist.


webm ist eine Untermenke von Matroska. Welches Feature von Matroska verwendest Du, dass Du nicht einfach webm einsetzen magst? Alles andere gibt unnötige Kopfschmerzen.

Das OpenCodecs Paket von http://xiph.org/dshow/ sollte mit Webm, Ogg, VP8, Vorbis, Theora, Speex und FLAC etc. umgehen können.

[Peterxy]

Kann es sein, das hier keiner bisher in VP8 was encoded hat oder wie meinst du das mit "sollte"? :confused:

Der VP8 ist ja schon einiges besser als der VP7, liegt daher nahe das ganze nicht nur für "Webcontent im Browser", sondern auch ev. für DVB-T Archivierungen o.ä. mal zu nutzen. Und ja, das Xiph DS-Filterpack aus dem Link den du gegeben hast liefert ein Bild - hat aber Probleme mit der Tonspur. Aber vergessen wir einfach mal die Tonspur, denn das Xiph Open Codecs Packs scheint ohnehin nur mit dem MS Windows Media Player zu funktionieren.

Andere Player (zoomplayer, crystal, BS Player & Co) können auch mit diesem Pack kein VP8 wiedergeben.
(zumindest kann ich das nicht erkennen)

[KraetziChriZ]

Warum nicht einfach h264 nehmen?

[SavageX]

Kann es sein, das hier keiner bisher in VP8 was encoded hat oder wie meinst du das mit "sollte"? :confused:


Als Linuxer habe ich einen schweren Stand, DirectShow-Filter zu testen - deshalb "sollte" ;)

[Peterxy]

Jep, nutze normallerweise auch nur h.264. :smile:
Das VP8 hatte mich halt mal so interessiert auszuprobieren, weil ich damals das VP7 bei On2 gekauft hatte.

Fürs VP7 wurde von On2 damals ja ein simpler (aber "überall" funktionierender) De/encoder ausgeliefert, dachte das wäre beim VP8 ähnlich - offensichtlich ist das wohl jetzt etwas "komplexer" seit VPx wohl nicht mehr von On2 weiterentwickelt wird sowie ich das verstehe.

[SavageX]

Fürs VP7 wurde von On2 damals ja ein simpler (aber "überall" funktionierender) De/encoder ausgeliefert, dachte das wäre beim VP8 ähnlich - offensichtlich ist das wohl jetzt etwas "komplexer" seit VPx wohl nicht mehr von On2 weiterentwickelt wird sowie ich das verstehe.

Jetzt geht es ja nicht "nur" um einen Videocodec, sondern der Audio-Part ist ja in Webm auch festgeschrieben.

Du hast geschrieben


Wie oben geschrieben, die funktionieren nicht mit mkv´s, sondern sind anscheinend nur für webm (VP8 + Vorbis) was etwas "witzlos" ist.


*Funktionieren* die Filter denn zumindest für webm?

[Peterxy]

Hatte auch ein webm (VP8 + Vorbis) erstellt, das läßt sich aber damit ebenfalls nicht abspielen. (die "älteren" Player können nach wie vor mit der webm Endung nix anfangen)

Der neue VLC Player hingegen spielt allerdings bei mir sowohl webm (VP8 + Vorbis) wie auch mkv (VP8 + MP3) absolut problemlos ab. Wieso beides nun ausgerechnet mit dem VLC sauber funktioniert aber keins mit den Filtern in nem anderen Player, weiß ich nicht.
(daher ja auch meine Frage :wink: )

[SavageX]

Der neue VLC Player hingegen spielt allerdings bei mir sowohl webm (VP8 + Vorbis) wie auch mkv (VP8 + MP3) absolut problemlos ab. Wieso beides nun ausgerechnet mit dem VLC sauber funktioniert aber keins mit den Filtern in nem anderen Player, weiß ich nicht.
(daher ja auch meine Frage :wink: )

Aaaah, okay.

Nun, VLC bringt im Kern ja libavcodec aus dem ffmpeg Projekt mit, hat also nativ Decoder für alle erdenklichen Formate an Bord. VLC greift nicht auf DirectShow zu, was ganz nützlich ist, wenn DirectShow verpuzzelt ist.

Winamp müsste übrigens auch mit eigenen Decodern für VP8 und Vorbis kommen, könnte also auch auf Anhieb funktioneren.

[Peterxy]

Jep, der neue Winamp müßte auch gehen.
Hatte halt nur irgendwie gedacht das über die DS-filter es ja ev. in anderen Playern wiedergegeben werden kann. Scheint aber in Verbindung damit wenn überhaupt nur auf den Windows Media Player zuzutreffen bzw. auf diesen MPlayer (bei den DS-Filtern liegt dafür ein "Patch" dabei)

Ist im webm eine bestimmte Bitrate im Audiostream vorgesehen?
Kommen eigentlich im encoder Neuerungen?
(iss ja en bißel dürftig was man da einstellen kann und an die Speed vom x.264 kommt ja auch noch nicht ran . .... )

[Stebs]

Der Mediaplayer Classic Homecinema kann in neuesten Versionen auch WebM intern abspielen, die Filter davon gibt es ja auch seperat als DirectShow-Filter.
FFdshow kanns mittlerweile auch, nur die üblichen Verdächtigen (Kompilierer) hängen diesen Monat etwas hinterher...

Insgesamt ist es sowohl bei En- wie auch Decodern für WebM (resp. VP8) noch sehr früh. Ich habe aber keine Zweifel daran dass es kurz- bis mittelfristig gute Tools für jeden Geschmack geben wird.

[DanMan]

Jep, nutze normallerweise auch nur h.264. :smile:
Das VP8 hatte mich halt mal so interessiert auszuprobieren, weil ich damals das VP7 bei On2 gekauft hatte.

Fürs VP7 wurde von On2 damals ja ein simpler (aber "überall" funktionierender) De/encoder ausgeliefert, dachte das wäre beim VP8 ähnlich - offensichtlich ist das wohl jetzt etwas "komplexer" seit VPx wohl nicht mehr von On2 weiterentwickelt wird sowie ich das verstehe.
Gibt mittlerweile schon ein paar Encoder/Konverter, die damit zurecht kommen. Meistens aber in der Tat webm Encoder - also nur VP8 und Vorbis. Beispiel (http://www.mirovideoconverter.com/)
Mit einem De-/Muxer sollte das aber kein Hindernis sein, da was anderes draus zu machen, so man denn will.

[Peterxy]

VP8 konvertieren ist ja nicht das Problem, gibt ja FFMPEG. :cool:
Mit Sachen wie Miroconverter kann man imo nicht soo viel anfangen. In FFMPEG ist ja angeblich eine Geschwindigkeitsoptimierte VP8 Version - wobei das ganze schon langsamer als x.264 ist (bei ähnlichen Qualisettings vorausgesetzt).

So wie er jetzt ist, machts zumindest nicht sooviel Sinn ihn privat zu nutzen - wenn man doch in kürzerer Encodingzeit mit x.264 ein (zumindest rein visuelles) besseres Endergebniss beim konvertieren erzielt.
Ich denke ist so wie Stebs sagt, da wird wohl noch einiges an Zeit ins Land gehen müssen.

[_DrillSarge]I[]

http://www.guadec.org/index.php/guadec/index

guadec live per webm :)

[#44]

H.264 webstreaming jetzt tatsächlich weiterhin kostenlos dank WebM!(?) (http://www.heise.de/newsticker/meldung/MPEG-LA-Dauerhaft-keine-Lizenzkosten-fuer-freies-Internet-Streaming-von-MPEG-4-AVC-H-264-1066889.html)

[Ganon]

Heißt das jetzt eigentlich auch, dass YouTube-Videos länger als 10/15min sein können?

[(del)]

Diese Information suche ich schon seit 2 Tagen...

[basti333]

heißt das, das auch brwoseranbieter wie mozilla H.264 ab sofort lebenslänglich umsonst verwenden dürfen?

[Coda]

Nein. Es werden nur keine Lizenzkosten für's Streaming fällig für den Webseitenbetreiber, solange es nichtkommerziell ist.

[basti333]

Naja, ob es dann erfolg hat sich als standard durchzusetzen? Mozilla hat bisher ja wenig interesse gezeigt H.264 zu lizensieren, da werden sie es jetzt auch nicht machen.

Auf der einen seite also der IE und Safari die kein WebM unterstützen und auf der anderen Seite Firefox, welches kein H.264 Unterstüzt. So werden Flash-streams wohl kaum abgeschaft werden.

[DanMan]

Naja, ob es dann erfolg hat sich als standard durchzusetzen? Mozilla hat bisher ja wenig interesse gezeigt H.264 zu lizensieren, da werden sie es jetzt auch nicht machen.

Auf der einen seite also der IE und Safari die kein WebM unterstützen und auf der anderen Seite Firefox, welches kein H.264 Unterstüzt. So werden Flash-streams wohl kaum abgeschaft werden.
Was dein letztes Bedenken angeht: HTML 5 sieht es vor, dass man für ein Video mehrere Quellen angeben kann. Man müsste ein Video also nur sowohl in H.264 als auch WebM (oder Theora, das scheinbar dort, wo es schon läuft, weiterhin unterstützt wird) bereitstellen, und der Browser pickt sich raus, was er versteht.

Amüsant, dass die MPEG LA plötzlich den Schwanz einzieht, jetzt wo ihnen die Bäche davonschwimmen. Hoffentlich setzt sich WebM auf dem Desktop trotzdem durch. Auf embedded Systems könnte das aber vielleicht zu einer zäheren WebM Verbreitung führen.

[SavageX]

Amüsant, dass die MPEG LA plötzlich den Schwanz einzieht, jetzt wo ihnen die Bäche davonschwimmen. Hoffentlich setzt sich WebM auf dem Desktop trotzdem durch. Auf embedded Systems könnte das aber vielleicht zu einer zäheren WebM Verbreitung führen.

Die MPEG-LA zieht gar nichts an, sie haben nur angekündigt, auch in Zukunft keinen Suizidversuch zu unternehmen. Durch die Ankündigung hat sich für niemanden die Kostenstruktur in irgendeiner Weise verändert.

Hier nochmal eine Sicht aus dem Mozilla-Camp: http://shaver.off.net/diary/2010/08/27/free-as-in-smokescreen/

[DanMan]

Die MPEG-LA zieht gar nichts an, sie haben nur angekündigt, auch in Zukunft keinen Suizidversuch zu unternehmen. Durch die Ankündigung hat sich für niemanden die Kostenstruktur in irgendeiner Weise verändert.

Hier nochmal eine Sicht aus dem Mozilla-Camp: http://shaver.off.net/diary/2010/08/27/free-as-in-smokescreen/
Die Verbreitung von h264 Material ist jetzt für immer kostenlos, oder nicht? Dass Encoder und Decoder weiterhin kosten ist mir bewusst.

[(del)]

Weiß jetzt irgendjemand etwas genaueres was private Nutzung angeht oder nicht? Ich werde draus immernoch nicht schlau.

Längenbeschränkung? Profile (main/high, 4.1/5.x)? Selbst erstellte "private" Videos als AVCHD/x.264 irgendwo zum Saugen ablegen (Desktopvids, AVCHDs der Cam, MP4 vom Handy usw. usw.)?

Ich meine 2sahred, Rapid, Megaupload usw.

[SavageX]

Die Verbreitung von h264 Material ist jetzt für immer kostenlos, oder nicht? Dass Encoder und Decoder weiterhin kosten ist mir bewusst.

Nur wenn Du das Material kostenfrei bereitstelltst. Ich habe keine Ahnung, inwiefern man z.B. mit Werbung auf der Seite davonkommt.

[(del)]

Auf der einen seite also der IE und Safari die kein WebM unterstützen und auf der anderen Seite Firefox, welches kein H.264 Unterstüzt. So werden Flash-streams wohl kaum abgeschaft werden.Was ist jetzt das Problem? FX-basierte/Opera oder IE/Safari? :|

http://my.opera.com/haavard/blog/2010/02/04/h264-trickery

[Ganon]

Ich warte ja immer noch auf einen Videodecoder der in JavaScript geschrieben ist ^^

[DanMan]

Nur wenn Du das Material kostenfrei bereitstelltst. Ich habe keine Ahnung, inwiefern man z.B. mit Werbung auf der Seite davonkommt.
Für die nicht-kommerzielle Nutzung also. Verstehe.

[Coda]

Ich warte ja immer noch auf einen Videodecoder der in JavaScript geschrieben ist ^^
Da kannst du lange warten. Zumindest in Sachen H.264.

[Ganon]

Da kannst du lange warten. Zumindest in Sachen H.264.

http://code.google.com/p/emscripten/

Wer weiß ^^

[Coda]

Es geht um die Performance, nicht darum dass es nicht möglich wäre.

[Steel]

MPEG-LA stellt VP8 Patentpool zusammen:

http://www.mpegla.com/main/pid/vp8/default.aspx

Let the games begin.

[(del)]

Das interpretiert fefe aber erstmal anders ;)
http://blog.fefe.de/?ts=b3ab9602

[Benedikt]

Das interpretiert fefe aber erstmal anders ;)
http://blog.fefe.de/?ts=b3ab9602
:facepalm: fefe...seufz...

Kann man eigentlich nur das dagegenhalten (http://fosspatents.blogspot.com/2011/02/mpeg-la-puts-googles-webm-video-format.html) - erklärt die Situation ganz gut.

[(del)]

Google hat damit begonnen, Videos der Plattform Youtube auf das offene WebM-Format zu konvertieren. Bereits 99 Prozent der meist gesehenen Clips bzw. 30 Prozent aller Inhalte wurden bereits umgewandelt, heißt es in einem Blog-Eintrag. (http://derstandard.at/1303291025448/Video-Format-Youtube-stellt-auf-WebM-um-Gut-fuer-die-User)

Welche Auflösungen werden von webm unterstützt, auf Youtube ist mir aufgefallen, dass nur 360p und 720p zu Auswahl stehen, 240p, 480p und 1080p fehlen gänzlich.

[Coda]

Beliebige