Element "video" z HTML 5 v praxi

Ars Technica rozebírá výhody nasazení elementu <video> z HTML 5. Vyzdvihuje nezávislost na proprietárních technologiích a nasazení společně s formáty Ogg.

2.6.2009 07:49 | Fluttershy, yay! | Zajímavý článek

Komentáře

[camlost]

mam dojem, ze v prednasce o google wave byly vyhody novych "multimedialnich" tagu zmineny take. je to ve forme videa nekde na googlu [1h 20 min].

[houska]

<video>@youtube.com

[xm]

Jojo, <video> verze Youtube (i když zatím jen testovací) může hodně pomoct s postupnou eliminací nemoci jménem Flash, alespoň tam kde jde jen o přehrávání videa (a na nic jiného stejně Flash nepotřebuji). Tímhle mě Google hodně mile překvapil, snad půjdou v jeho šlépějích i další...

[Jakub Lucký]

No, doufám že FF3.5 už to bude umět... Protože Iceweasel 3.0.9 na tom stávkuje...

[newman]

To zalezi, co si predstavujes pod "umet". Mam tady firefox-3.5-0.20.beta4.fc11.x86_64 a video se mi nespusti, vsechny odkazy jsou nejak za zavisle na JavaScriptu a vypadaji asi takhle "http://www.youtube.com/html5#", pokud je ke spusteni treba ten Googli SW "o3d", tak jako 64-bit user mam smulu (na zadnou magii, a la http://code.google.com/p/o3d/wiki/Linux64NSPluginWrapper naladu nemam)

[Grunt]

FF stávkuje a stávkovat bude, protože je v něm pouze implementace Ogg kontejneru, Vorbisu jako audia a Theory jako videa. Google zase jako na truc na YouTube nasadil mp4 jako kontejner, AAC jako audio a H.264 jako video. Jediná volba je WebKitový přehrávač, Gstreamer a do něj patentované pluginy bůhví odkuď(Pokud používáte distribuci, která si snaží držet čistý štít, tak blahopřeju. Video si nepřehrajete, pokud si všechno sám nezkompilujete). V žádné verzi Firefoxu(mám v. 3.6 a ani ťuka) si to video prostě nepřehrajete. Už jsem se o tom nejednou zmiňoval.

[dustin]

A co nějaký addon na spouštění v externím playeru, např. mplayeru? Pokud to technicky lze, pak se asi velice rychle objeví.

[Grunt]

addon

Pokud vím, tak to je proti celé myšlence video tagu.

[Kvakor]

A proč? Podle mně je hlavní myšlenkou video tagu zbavení se flashových přehrávačů a jiných nesystémových příšerností. A mně osobně by se to určitě líbilo, už jen z toho důvodu, že MPlayer při provozu ve vlastním okně může naplno použít veškerou dostupnou HW akceleraci, kdežto uvnitř prohlížeče jsou jeho možnosti silně omezeny (efektivně je to většinou stejné jako vystup v neakcelerovaných Xkách). Při zobrazení videa v rozlišením větším než malém a na slabšich strojích je to už dost silně znát ...

[Grunt]

A proč? Podle mně je hlavní myšlenkou video tagu zbavení se flashových přehrávačů a jiných nesystémových příšerností.

Já bych řekl, že ne. Vždyť flash vadí jen Linuxákům. Ale teď vážně. Já jsem četl, že hlavním údělem tagu video je udělat z videa věc zcela nativní a integrovanou. Stejně jako je tomu třeba u JPEG a PNG u obrázků. Na ty není také potřeba žádný plugin, každý prohlížeč má integrované jejich vykreslování. A stejně tak by tomu mělo být u video tagu.

A mně osobně by se to určitě líbilo, už jen z toho důvodu, že MPlayer při provozu ve vlastním okně může naplno použít veškerou dostupnou HW akceleraci, kdežto uvnitř prohlížeče jsou jeho možnosti silně omezeny (efektivně je to většinou stejné jako vystup v neakcelerovaných Xkách).

Dávám Vám za pravdu, že každý prohlížeč, který jsem doposud zkusil to měl implementované jako RGB pixmapu, ale nutnost to není zcela určitě:

WebKit/WebCore/platform/graphics/gtk/VideoSintGStreamer.cpp:

**
 * SECTION:webkit-video-sink
 * @short_description: GStreamer video sink
 *
 * #WebKitVideoSink is a GStreamer sink element that sends
 * data to a #cairo_surface_t.
 */

#include "config.h"
#include "VideoSinkGStreamer.h"

#include <glib.h>
#include <gst/gst.h>
#include <gst/video/video.h>

static GstStaticPadTemplate sinktemplate = GST_STATIC_PAD_TEMPLATE("sink",
        GST_PAD_SINK, GST_PAD_ALWAYS,
        GST_STATIC_CAPS(GST_VIDEO_CAPS_RGBx ";" GST_VIDEO_CAPS_BGRx));

…

    // TODO: consider priv->rgb_ordering?
    cairo_surface_t* src = cairo_image_surface_create_for_data(GST_BUFFER_DATA(buffer), CAIRO_FORMAT_RGB24, priv->width, priv->height, (4 * priv->width + 3) & ~ 3);

stačí místo GST_VIDEO_CAPS_RGBx použít GST_VIDEO_CAPS_YUV a volat /usr/lib/gstreamer-0.10/libgstxvimagesink.so místo /usr/lib/gstreamer-0.10/libgstpango.so(nebo možná to volá /usr/lib/gstreamer-0.10/libgstximagesink.so…ví bůh). Teoreticky by mělo stačit upravit pár řádků. Výstup lze použít jakýkoliv(kdyby v gstreameru bylo VDPAU, tak klidně i VDPAU). Nevím proč to všichni rvou do pixmapy.

Při zobrazení videa v rozlišením větším než malém a na slabšich strojích je to už dost silně znát ...

Ale není to zas tak strašné. 800Mhz, jedno jádro, X11 pixmapa, yuv420p -> rgb32 special converter a 1280x534 => 1280x534 BGRA:

BENCHMARKs: VC: 110.470s VO:   9.997s A:   0.000s Sys:   2.683s =  123.150s
BENCHMARK%: VC: 89.7032% VO:  8.1178% A:  0.0000% Sys:  2.1790% = 100.0000%

Stejná kombinace, jen Xvideo:

BENCHMARKs: VC: 109.998s VO:  43.125s A:   0.000s Sys:   2.642s =  155.765s
BENCHMARK%: VC: 70.6181% VO: 27.6859% A:  0.0000% Sys:  1.6960% = 100.0000%

Se mi zdá, že oni tam používají nějaké jiné zpomalováky.

[Grunt]

A stejně tak by tomu mělo být u video tagu.

A stejně tak by tomu mělo být i u videa.

[xkucf03]

<video> nepřináší nic nového a jak to vypadá, je celkem na nic. Co ti brání využít už (roky) existující standardní značky <object data="soubor.ogg"></object> ? Prohlížeč si načte plugin pro přehrávání videa a je to.

Pokud budeme chtít, aby přehrávání videa fungovalo stejně jednoduše jako zobrazování obrázků, stačí, když prohlížeč nějaký přehrávací plugin bude obsahovat už ve výchozí instalaci.

Ve skutečnosti totiž nejde o výmýšlení nových HTML značek, ale o to, aby se dohodnula nějaká konvence, jaký kontejner a jaký kodek pro video a audio se bude obecně používat → pro ty vybrané pak nebude potřeba instalovat zvláštní plugin a pro ostatní ano.

[Grunt]

Pokud se dobře pamatuji, tak o tom už jednou řeč byla. Ale bylo by to docela dobré jako fallback content. A nebo implementace jakou používá Wikimedia. Ta je také parádní.

[dustin]

Dokud tam ta podpora nebude, tak by mi addon vůbec nevadil. Flash nevadí jen linuxákům, přehrávání videa ve flashi je náročné na CPU i ve windows, zatímco mplayer to na obou platformách zvládá úsporně. Stačí porovnat nativní flash a zde uvedený skript na stahování pořadů z archívu novy.

[GeBu]

Myslel jsem, že ta norma je i o kontejnerech a kodecích :(. To znamená, že každý prohlížeč bude muset implementovat všechny kontejnery a kodeky, které se ustálí? Bude možné mít v tagu <video> i proprietární videa? Myslel jsem, že věci souvisejícís MPEG4 (mp4, aac a h.264) podléhají patentům - google za tu implementaci něco platí?

[Fluttershy, yay!]

Myslel jsem, že ta norma je i o kontejnerech a kodecích :(. To znamená, že každý prohlížeč bude muset implementovat všechny kontejnery a kodeky, které se ustálí?

Není. Původně měl být Ogg součástí standardu, ale některé firmy se trhly (Nokia, tuším) kvůli patentům nebo čemu. Takže to vypadá tak, jak to vypadá.

Bude možné mít v tagu <video> i proprietární videa?

Ano, v elementu video lze mít odkazy na několik souborů (v různých formátech), přičemž se vybere ten podporovaný systémem.

Myslel jsem, že věci souvisejícís MPEG4 (mp4, aac a h.264) podléhají patentům - google za tu implementaci něco platí?

Co by platil? Google má video v daném formátu a v prohlížeči je de facto odkaz na toto video. Implementace se tedy týká prohlížeče... za Chrome Google možná něco opravdu platí, ale to nevím.

[GeBu]

 

 za Chrome Google možná něco opravdu platí, ale to nevím.

Tak jsem to myslel.

 

[Grunt]

Není.

Byla.

kvůli patentům nebo čemu

Skrytá patentová hrozba. To už je horší jak strašení. U strašení aspoň člověk ví, čeho se má bát.

ten podporovaný systémem

Bohužel prohlížečem. WebKit je výjimka(a docela dobrá).

Co by platil?

Já mám pocit, že za licence na AAC+ a H.264 opravdu platí. Ale už je má zaplacené pro použití HD videa na YouTube, tak to je jen pakatel.

[Grunt]

Skrytá patentová hrozba

Oprava: Nokia tvrdí, že skryté patenty na VP3. Sakra, jaktože mi to zas ušlo?

[Mandarinka]

http://forum.doom9.org/showthread.php?p=1296267#post1296267

Tohly by naznačovalo, že On2 použil pro VP3 i cizí patenty, aniž by je licencoval Xiph.org. To by byl asi pro Theoru konec, pokud by se to potvrdilo.

[J. M.]

Není. Původně měl být Ogg součástí standardu, ale některé firmy se trhly (Nokia, tuším) kvůli patentům nebo čemu.

Nokia se trhla právě s tím kuriózním zdůvodněním, že Ogg je proprietární formát. Vydala tehdy to legendární pédéefko, kde před „proprietárním“ Oggem varovala... Tím to zazdila. Škoda, že na to lidé rychle zapomněli (zejména příznivci Qt/KDE, kteří si naivně myslí, že Nokia je nějakým přítelem open-source komunity, nějakou morálně nezkaženou firmou).

[Grunt]

Dodal bych ještě odkaz na to PDFko(snad je to ono) a malé shrnutí z Ars Technica:

What Nokia wants

The position paper that Nokia submitted to the W3C touches on a variety of topics and mentions Ogg only briefly. The paper's arguments can be summarized as follows:

1. W3C shouldn't make any standards relating to codecs. Leave that to other standards bodies like ITU-T and ISO/IEC.
2. There are over a billion PCs in the world today, many connected to the web, but these numbers are tiny compared to traditional video playback devices like DVD players.
3. This industry is used to paying license fees and royalties for video codecs like MPEG-2.
4. This industry is used to making money, and it doesn't care about keeping things free.
5. Web codec standards should be either free or low-cost to implement.
6. Web codec standards should support DRM to placate Hollywood, but DRM implementations should be optional.
7. H.264 for video and AAC for audio would be Nokia's recommendations for codecs.

Nevím jak kdo, ale já dnešním dnem, ať už jsem měl pochybnosti jakékoliv, měním stanovisko na: Softwarové patenty, licence a intelektuální vlastnictví musí zemřít. Mít tu čest a jít kolem domu toho krypla co tohle vymyslel, tak mu bez váhání vybiju okna.

BTW: Neměl by někdo čísla těch patentů na VP3? Nějak se mi je nedaří najít.

[J. M.]

Ten odkaz na PDFko mi zobrazuje jenom PNG obrázek s pozadím... Ale je to tohle:

Nokia.pdf

Z něj pak vybírám zejména tu největší perlu, která tehdy vzbudila největší rozruch (byly toho plné zprávičky všude):

„the active endorsement of proprietary technology such as Ogg, ... , by W3C, is, in our opinion, not helpful for the co-existence of the two ecosystems (web and video) and therefore not our choice“

„aktivní schalování proprietární technologie jako Ogg organizací W3C podle našeho názoru nepomáhá koexistenci těchto dvou ekosystémů (web a video) a tudíž není naší volbou“

A co tedy navrhují místo toho hnusného proprietárního Oggu?

„Considering our requirements, we believe the widespread use of technically competitive, but not necessarily "free" open standards, such as H.264 for video and AAC for audio, would serve the community best“

„Vzhledem k našim požadavkům věříme, že široké použití technicky konkurenceschopných, byť ne nutně „svobodných“ otevřených standardů jako H.264 pro video a AAC pro audio by komunitě posloužilo nejlépe“

Ano, namísto proprietárního Oggu bude pro komunitu lepší otevřený standard jako H.264. Orwell by měl radost.

Podle mě to je dostatečný důvod na to celou Nokii ignorovat do té doby, než se za tenhle pamflet veřejně omluví. Ani to slovo „krypl“ na tohle nestačí. To je klasický mafiánský newspeak, kterým vládnou jenom ty nejzlotřilejší korporace (a státy) světa.

[Grunt]

Ten odkaz na PDFko mi zobrazuje jenom PNG obrázek s pozadím

Nádhera, že?

Podle mě to je dostatečný důvod na to celou Nokii ignorovat do té doby, než se za tenhle pamflet veřejně omluví. Ani to slovo „krypl“ na tohle nestačí. To je klasický mafiánský newspeak, kterým vládnou jenom ty nejzlotřilejší korporace (a státy) světa.

Kdy, v kolik a hlavně na který?

[hydrandt]

Opravte mě, jestli se pletu, ale pokud by do budoucna google chtěl na youtube poskytovat obsah přes video tag, nebylo by moc únosné převádět všechna ta videa ze současného formátu (pokud vím tak je to stejný, jako popisujete vy, tedy h264+AAC) do Theory+Vorbisu. Takže to nevidím jako krok "na truc", připadá mi to celkem logické.

[Grunt]

Na YouTube se používá On2 Technologies VP6 (ano, ten On2, který uvolnil VP3 ze kterého se přepracováním pod záštitou Xiph.org vyklubala Theora. Jen tak pro zajímavost, aktuální verze, kterou mají je VP8 a to je prej ještě efektivnější než H.264). Jen pro HD Videa(trailery, oficiální videa) se používá H.264 a ty většinou dělali z originálů, tak by to neměl být problém. Ani překódování z těch H.264 videí by to nebylo tak strašné(ale originál je originál).

[Milan Vít]

Nemyslím si, že to je pravda. Google tak rok, rok a půl zpátky překódoval všechny videa (nebo přinejmenším velkou část) do H.264, aby mohly být přehrány na iPhonu – tomu se posílá jen H.264 verze videí.

[Grunt]

Tak o tom nic nevím. Ale o to menší problém by to měl být překonvertovat do Theory. Dailymotion neměl s 300 000 videi žádný problém(Theora je docela rychlá).

[Grunt]

Dailymotion

A vůbec. Pokud to v reálu bude vypadat takto(pozor, nejede to ani na WebKitu - FF3.5,FF3.6 potřeba), tak budu chrochtat blahem. Jen kdyby tam chtělo být Xv a Full-screen.

[J. M.]

Na YouTube se používá On2 Technologies VP6

Asi na nějakém jiném YouTube, než navštěvuji. Já si z YouTube stahuji spoustu videí a stále, i dnes, jich je většina v H.263 (a kontejneru FlashVideo), tedy tom původním formátu. Novější a kvalitnější videa pak jsou často v H.264 (buď v kontejneru FlashVideo, nebo v MP4). Na VP6 jsem tam ještě nikdy nenarazil, tedy aspoň ne mezi těmi videi, která jsem si stáhnul.

[J. M.]

Mimochodem, když se tak namátkou dívám na ta videa z poslední doby, tak všechna jsou v H.264. V H.263 pak jsou ty „legacy“ kousky.

Mimochodem, ani Wikipedia v článku o YouTube, sekci Formáty neříká o VP6 ani slovo. Myslím, že sis to prostě s něčím spletl. Matně si vzpomínám, že Živě.cz kdysi zamýšlelo svoje flashová videa vysílat ve VP6...

[Grunt]

No opravdu. Ale přísahal bych bohu, že tam byly VP6ky. Momentálně mi u nich Mplayer píše ffflv (Že by to byly H.263 mě ani ve snu nenapadlo, když mplayer samotný má implementací H.263 hned několik a ani slůvkem se o nich nezmínil). Ale někde jsem je musel nabrat(dodnes jsem si myslel, že z YouTube):

~/Videa$ mediainfo *.flv | grep H.263 | wc -l
16
$ mediainfo *.flv | grep H.263 | wc -l
9

[Mandarinka]

Youtube je skutečně původně vp6 (nativní video formát flashe před verzí 9 nebo 10 - kdy přibylo h.264 a mp4 kontejnér), a není to nic moc. Poté experimentálně nasadili h.264 enkodér, který napsal jeden z Googlových lidí jako hobby projekt, nicméně to za moc nestálo, ani to uspokojivě nepředčívalo onen vp6. Jako vtípek ta videa obsahovala v userdata řetězec "xvid avc", ale to byl skutečně jen hoax/fórek.

Pro HD video konečně youtube nasadil x264, protože jinak to prostě nešlo, při tom datovém toku, co byl k dispozici :)

[Grunt]

protože jinak to prostě nešlo, při tom datovém toku, co byl k dispozici :)

Nominální bitrate 2Mbps a ještě VBR? To už by měl zvládnout kdekdo.

[J. M.]

Ne, to máš opravdu popletené. YouTube bylo původně v H.263 (respektive Sorenson, což bylo jenom převlečené H.263). To je taky ten původní nativní videoformát Flashe (taky známý jako FLV1, tedy FlashVideo 1). Až poté (ve verzi 8) do Flashe přibyla podpora VP6, a nakonec (ve 3. aktualizaci verze 9) pak podpora H.264 (která pak na YouTube začala nahrazovat původní H.263).

[Grunt]

Tak Sorenson Spark jsem potkal všude možně, ale na YouTube ještě ne. Ale asi na tom něco bude.

[J. M.]

Až do relativního nedávna (tak 1, maximálně 2 roky nazpátek) na YouTube nic jiného než Sorenson Spark (alias H.263, alias FLV1) nebylo. Sám jsem tam tehdy řadu videí nahrával a tenkrát to ještě fungovalo tak, že kdyžs to video poslal přímo ve FLV1 (alias H.263, alias Sorenson) s přesně vyhovujícími parametry (rozlišení, maximální bitrate, audio formát), tak to tam pak bylo přímo bez překódování (v opačném případě to automaticky zkonvertovalo na FLV1 svých standardních parametrů).

[Grunt]

To [ffflv](asi to bude FLV1) je Sorenson Spark?

[J. M.]

To je asi jako říct, že FFmpeg MPEG-4 (FMP4) je DivX. Nebo že Firefox je Internet Explorer.

FLV1 je zkratka označující původní FlashVideo, které používalo video formát H.263, ve Flashi reprezentovaný kodekem Sorenson Spark. Sorenson Spark je Sorenson H.263, tedy softwarová implementace H.263 od Sorensonu. Zatímco ffflv je softwarová implementace FLV1 (tedy H.263 používaného ve Flashi) z FFmpegu. Jestli je to úplně 100% standarní H.263, to ale nevím, je to dost obskurní záležitost, o které se dá těžko něco dohledat (leda si snad přečíst zdroják FFmpegu).

Každopádně, opět - je potřeba rozlišovat mezi softwarovým produktem a formátem, který ten softwarový produkt používá.

[Grunt]

Jasně, díky za vyjasnění.

Jestli je to úplně 100% standarní H.263, to ale nevím, je to dost obskurní záležitost, o které se dá těžko něco dohledat

Proto se radši bavím o Soronsen Sparku než H.263.

leda si snad přečíst zdroják FFmpegu

Už jdu na to.

[Grunt]

Já osobně bych byl pro VP3/Theoru/Thusneldu pro standardní videa v SD rozlišení(je neuvěřitelně rychlá a tak by fungovala dobře v mobilních zařízeních, je zcela volná bez patentových a licenčních zatížení a ještě pro zpětnou kompatibilitu(Theoru už podporují všechny prohlížeče) - prostě to na jaké úrovni je dneska VP6 na YouTube) a pro VP8 pro HD rozlišení(a nebo možná naopak). Bohužel pochybuju, že On2 bude s VP8 vůbec nějak hýbat a nakonec skončí podobně jako VP5.

[David Jaša]

BTW na tinyvid.tv, na kterou jsi odkazoval z jiné diskuse, jsou videa v čem? Beta od safari je "nevidí", přestože kodek pro ogg v systému mám (díky ffdshow-tryouts), tak jsem jim poslal bug. Kdyby to udělalo víc lidí, možná jablíčkářům dojde, že je hloupé .ogg neznat.

[Grunt]

BTW na tinyvid.tv, na kterou jsi odkazoval z jiné diskuse, jsou videa v čem?

Kontejner Ogg, audio je Vorbis a video je Theora(snad 1.0 nebo nějaká alpha).

Beta od safari je "nevidí"

A podporuje Safari HTML5 a hlavně pak ten video tag? GtkWebKit z.B. nemá žádnou implementaci ovládacích prvků a ty videa u nich nemají atribut autoplay, takže video se načte a zastaví na prvním snímku a pak to vypadá, že to nefunguje(ale ono to ve skutečnosti funguje moc dobře). Není to tento případ?

[David Jaša]

Přílohy:

• tytrubko_html5.png (762871 bytů)
• safari_tinyvid.tv.png (142014 bytů)

Safari umí minimálně TyTrubko/html5 - jenom jim blbnou ty ovládací prvky, ale video jede, teď už i s resizem. Oproti tomu na tinyvid.tv ukáže prostě jen bílou plochu a podle wiresharku se .ogg ani nepokusí stáhnout. Na té absenci alespoň fallbackových ovládátek asi taky něco bude...

[Grunt]

Jsem chtěl doporučit stáhnout stránku a přidat atribut autoplay do tagu video, ale teď jsem si vzpomněl na:

Apple, Nokia, Microsoft a další velké společnosti uvedly, že nebudou podporovat Theoru uvedenou v naší specifikaci. Zda tam tedy tento požadavek budeme či nebudeme mít, neovlivní nezávislé autory. Navíc požadavek způsobuje potíže těm, kteří se snaží najít skutečné řešení

[David Jaša]

Nj, tak to fak nezbývá, než otravovat s tím čudlíkem s mravencem tak dlouho, až to tam přidají.

[Grunt]

Tak to hodně štěstí. Vypadají, že to opravdu myslí vážně.

[David Jaša]

Ode mě budou mít bug za každou stránku, kde bude bílo. Když to bude dělat dostatek lidí, bude zahazování těch bugů žrát většinu času jablečných webkitích hackerů a něco takového možná hne i s tak velkou společností.

[Grunt]

Bohužel nemám k Safari přístup, nebyl by link? Napsal bych nějakého bota.

[David Jaša]

http://www.apple.com/safari/download/

Bug se dá nahlásit přes web jen když máš registraci v Apple Developer Connection. Pro běžné smrtelníky, co se nechcou registrovat u další velké společnosti, to jde pouze přes ten čudlík v browseru. Když mi dáš tip na další stránku s videem v <video> a oggu, tak ti to odchytím wiresharkem.

[xkucf03]

to jde pouze přes ten čudlík v browseru

To by mělo jít odchytit přes Wireshark a nasimulovat i bez Safari.

[Grunt]

Když mi dáš tip na další stránku s videem v <video> a oggu, tak ti to odchytím wiresharkem.

tip

[David Jaša]

Chm, měl jsem dodat, že ten tip by neměl mířit na zjevně testovací stránku. To by bylo moc průhledný.

[Grunt]

Hmm, pak tu existuje PRÉ BETA verze Dailymotion, která používá <video> a Ogg/Theoru. Je tam už přes 300,000 připravených videí, to by snad mohlo stačit.

[Grunt]

Other unencumbered free software codecs, such as the BBC's wavelet-based Dirac, could deliver competitive high-quality video support in the future. The BBC's original reference implementation is said to be impractical for real-world use, but the BBC is also funding the development of a real-world open source version called Schrodinger that is becoming quite mature. According to some experts, Dirac has the potential to deliver encoding quality that is comparable (or maybe even superior) to H.264.

Co?

[bhy]

no tohle, ne? nebo jak jako co?

[Grunt]

According to some experts, Dirac has the potential to deliver encoding quality that is comparable (or maybe even superior) to H.264.

[J. M.]

A co jako?

[xm]

Na tom není nic divného. Wavelet komprese (kterou právě Dirac používá) by teoreticky měla být lepší než metody používané v H.264 nebo VC1. Problém je ovšem trochu v hardwarové náročnosti, která je pokud vím větší.

[Grunt]

Na tom není nic divného. Wavelet komprese (kterou právě Dirac používá) by teoreticky měla být lepší než metody používané v H.264 nebo VC1.

O tom žádná(viz. už několikrát zde mnou zmiňovaný snow. I o Diracu jsem se zde nejednou už vyjadřoval). Bohužel Dirac má problémy s MC(a možná i jiné problémy) a díky tomu není zrovna moc použitelný u nižších bitrate(pod jedno mega vůbec). O to víc mě štve, že se o něm všude píše kdyby to náhodou z Theorou nevyšlo a přitom o sněhu jsem neviděl zmínku ani jednu. Přiznávám, že ještě jsem Dirac nezkoušel porovnávat na HD videu při nominální bitrate 2Mbps, ale to hned napravím.

Problém je ovšem trochu v hardwarové náročnosti, která je pokud vím větší.

Rozlišení 1280x534, obě jádra při 2Ghz úplně naplno(Dirac, resp. implementace kodeku Schröedinger od Davida Schleefa jako jedna ne z mnoha dovede plně využívat vlákna(a když už jsme u toho, tak také experimentálně CUDu a OpenGL)) a ještě to jede pár snímků pod 24fps. Pokud by to výrazně nezlepšili, tak o Diracu nejde uvažovat vůbec. Škoda, že někde nemám víc místa, hned bych tam naházel ukázky.

[Grunt]

Přílohy:

• 1.png (218061 bytů)
• 2.png (221015 bytů)
• 3.png (185383 bytů)
• 4.png (238614 bytů)
• 5.png (217727 bytů)
• 6.png (200110 bytů)
• 7.png (326614 bytů)

Jak jsem řekl. Dirac pod jedno mega prostě vůbec. Na druhou stranu mě zase překvapilo jak ukládá některé detaily do míst do kterých ani jeden z kodeků a náročnost u tak malého videa jen o 11% větší než u sněhu. No, nevím. Zaujímám neutrální postoj.

[Mandarinka]

Jo, Dirac je nepoužitelný, stejně jako Theora. Když ty kodeky potřebují víc jak dvakrát tolik datového toku, aby vyopadaly srovnatelně, nebo vůbec koukatelně (proti h.264), proč se vůbec někdo diví, že neprošly jako univerzální formát pro internetové video? Ogg kontejnér navíc není ideální (ale neapmatuju si už proč). Navíc ani nejsou rychlé, stejně jako není žádný HW dekodér pro mobilní telefony a jinou verbež.

Navíc i mezi h.264 kodeky je kopa balastu (až na x264, hehe). Když už to chcete mít bez patentové hrozby, nejšpíš bude lepší použít mpeg1, u kterého jes ituace známá, a ochrana už vypršela.

[Grunt]

Netvrdil bych, že je Theora přímo nepoužitelná.(Osobně bych si ji zatím dovolil označit za nejvhodnějšího kandidáta) Pokud se to neškáluje, tak 648x270 je u nominální bitrate 850kbps víc než sledovatelné(viz. třeba Matrixovskou sérii). Samozřejmě H.264 a nebo jiný MPEG-4 formát by byl nejideálnější, ale bohužel se vyřadili se z boje sami. V Diracu s největší pravděpodobností sedí nějaká žába na kameni v MC.

Ogg kontejnér navíc není ideální (ale neapmatuju si už proč)

Proč? Ale i kdyby ne, tak furt zbývá Matroška nebo NUT. Tady si starosti nedělám.

Navíc ani nejsou rychlé, stejně jako není žádný HW dekodér pro mobilní telefony a jinou verbež.

Co? Pokud najdete nějaký rychlejší kodek (samozřejmě ale srovnatelný co do kódování) než je Theora 1.1(a ještě se má zrychlovat) budu Vám dlužen pivo. Jinak pro Vorbis existuje implementace počítající s celými čísly jménem Tremor, která je právě vhodná do podobných zařízení a jiné verbeže. U Theory je to dle mého názoru jen otázka času.

Když už to chcete mít bez patentové hrozby, nejšpíš bude lepší použít mpeg1, u kterého jes ituace známá, a ochrana už vypršela.

No tak to by byla opravdu výhra. Ono ani s těmi patenty na Theoru to není tak žhavé. Osobně se mi žádný patent na VP3 nepodařilo najít a samotné On2 Technologies se Xiph.org zaručilo, že nikoho nebude s patenty týkajícími se VP3 nikoho otravovat. Mně by se zase líbilo použití Sorenson Video Codec(dříve se používalo v QuickTimu). To je z roku 1998 a je dost možné, že patenty už vypršely.

[J. M.]

Je důležité rozlišovat softwarový produkt (kodek, implementace) a formát (standard, specifikace). Co se týče třeba toho tagu video a webového videa, nejde o kodek (konkrétní softwarový produkt, který se použije), ale o formát videa, který se použije. Lidé si ty dvě věci strašně často pletou. Konkrétně Sorenson ve svých kodecích, včetně tohoto, převážně implementoval různé verze H.263 a H.264. Čili se na něj vztahují i příslušné patenty.

[Grunt]

Jasně. Rozlišuji a nebo se alespoň snažím. Konkrétně jsem myslel SVQ3(ten kodek má snad i svůj formát a není to jen nějaká jiná implementace standardu), ale jak jsem záhy zjistil tak si ho pletu s SVQ1(ten byl zveřejněn 1998, SVQ3 v roce 2001)

[Grunt]

Přílohy:

• 788.png (168394 bytů)
• 788-HD.png (583018 bytů)
• 2221-HD.png (579566 bytů)
• 2356.png (227464 bytů)
• 2356-HD.png (675994 bytů)

Tak teď nevím jestli dělám něco blbě já, něco hodně špatně tam mají oni a nebo je to zdrojem. HD verze o 2Mbps vyprodukuje naprosto stejný bazmek, dokonce i se stejnými (negativními) efekty akorát to víc žere a je to ve větším rozlišení.

[Petr]

Tady ukázky toho,co lze udělat za pomoci HTML5,Canvas,SVG a postupně se tak zbavit té neuvěřitelné prasárny zvané Flash.Ukázky funguji v Chrome,FF a Opera,jiné kromě IE jsem nezkoušel,ale všichni lidé z oboru se vzděláním vědí,že IE v životě nebyl prohlížeč.Ti co to vzdělání nemají nebo si jen na něco hrají budou neustále dokola tvrdit,že to prohlížeč je,ale znáte tu větu od Einsteina o lidské blbosti,ne?

 

http://www.chromeexperiments.com/

 

PS: Flash jako takový není špatný pro OMEZENÉ a SPECIALIZOVANÉ využití,ale trotlové,kteří si jen na web tvůrce hrají a vědí houby o standardech a neudělají ani alternativu stránky pro lidi bez Flashe nebo JS umožnili svou neschopností jeho rozmach ve špatném směru

[Lukáš Zapletal]

Tak jak to tedy je? Který kodek z dnešních prohlížečů (a technologií Flash), když započítáme i Theoru, je nejlepší z pohledu nejvyšší komprese při zachování dobré kvality?

Vychází mi z toho (z této diskuse), že Theora je rychlá, ale nemá takový kompresní poměr, jako kodeky ve Flashi...

[Grunt]

Asi nebudu daleko od pravdy, když řeknu H.264/MPEG-4 AVC.

Vychází mi z toho (z této diskuse), že Theora je rychlá

Pokud nezapočtu MPEG-1 a neunikl mi nějaký experimentální kodek, tak ze všech reálných variant nejrychlejší.

ale nemá takový kompresní poměr, jako kodeky ve Flashi...

A to zas jo. No na druhou stranu VP3 vs. VP6(H.263, H.264) - to je jako srovnávat MPEG2 a MPEG4. Ty čísla tam nejsou pro nic za nic. Kompresní poměry by byly ale za cenu rozmazání hran u Theory 1.0 a nebo vzniku švů a blokových artefaktů u Theory 1.1. Ono to není vůbec snadné když nejsou v Theoře implementovány různé důležité algoritmy(třeba Theora nepoužívá B-Frames, ale jen P-Frames - pro to je asi také tak rychlá).

[Mandarinka]

Theora má prý nějaký rudimentární loopfilter, což mluví proti tomu, že by byla rychlejší než mpeg4 part2 ("divx") o stejném rozlišení, bez b-snímků, gmc a qpel. Na druhou stranu, Theora má prý o dost horší entropy coder a také nemá predikci vektorů pohybu, což jí asi nějaký čas ušetří. Pak je tu samozřejmě otázka efektivity dekodéru; divx/xvid dekodér v libavcodecu je velmi rychlý, iirc.

Jenže také je pravda, že špatné technologie mohou být pomalé a neoptimalizovatelné. Například real video 10 je obšlehnutá ranná forma h.264, ale udělali tam pár změn, které sice nepomáhají kompresi, ale zenmožňují paralelizace (SSE2 optimalizace) v dekodéru.

[Grunt]

bez b-snímků, gmc a qpel.

Přesně. Je nejrychlejší z toho prostého důvodu, že v ní není implementována většina pokročilejších algoritmů. Možná by mohlo být rychlejší MPEG1/2. Defaultní MPEG4 ASP/AVC určitě ne.

Na druhou stranu, Theora má prý o dost horší entropy coder

Otázka je, co Theora horší nemá. Někdy mám pocit, že On2 Technologies vypustilo VP3 jako jistý druh záškodnictví v OSS. S CABACem nebo CAVLC se srovnávat určitě nedá. Vlastně:

Theora currently uses a semantic-token based backend encoder with minimal entropy coding. This is a previous-previous generation scheme that would have been ill considered even in VP3's early days.

no na druhou stranu:

flexible entropy encoding (Theora supports 80 VLC tables selectable per-frame, MPEG-4 ASP has just one)

Doporučuji přečíst toto(má to sedm dílů, stačí za demo přidávat čísla). Monty si nad tím zanadával jako špaček.

také nemá predikci vektorů pohybu

Tak drastické to zas není:

HalfPixel Motion Search Precision (MPEG-4 ASP/AVC supports HalfPixel or QuarterPixel)

[Grunt]

Doporučuji přečíst toto

Jo, na to jste původně odkazoval Vy. Tak aspoň předpokládám, že to máte nastudované.

[Mandarinka]

Predikce je něco jiného než motion search. Motion search vám ty vektory hledá, ale musí být zapsány do do bitsreamu. Když se vám je ale podaří předpovědět z těch, které už  zapsané máte (třeba protože sousední směřují stejným směrem, což se velmi často stává), tak ho zapisovat nemusíte a bity se použijí na něco jiného :)

Je, je hezké vidět, že to někam směřuje, ale když o 100% vylepšíte formát, který je naprosto archaický, neznamená to, že bude výsledek užitečný... Četl jsem vyjádření vývojáře x264 a ffmpegu. Řekl, že theora je horší formát než mpeg4 asp (xvid), ale že by se mohla přes horší kompresní schopnost dostat blízko, pokud by měla hodně dobré psychovizuální optimalizace (což zatím nemá). Pak se ale dozvěděl, že tam chybí ta predikce vektorů a vzal to zpět :)

[Grunt]

Přílohy:

• 1697-theora1.0.png (231732 bytů)
• 1697-theora1.1.png (223978 bytů)
• 1698-mpeg2.png (261040 bytů)
• 1698-orig.png (297325 bytů)

Predikce je něco jiného než motion search. Motion search vám ty vektory hledá, ale musí být zapsány do do bitsreamu. Když se vám je ale podaří předpovědět z těch, které už zapsané máte (třeba protože sousední směřují stejným směrem, což se velmi často stává), tak ho zapisovat nemusíte a bity se použijí na něco jiného :)

Aha, no tak to vypadá, že něco takového opravdu Theora nemá. Ale řekl bych, že celé vektory také nezapisuje. Možná jen odchylky od předchozího MV.

Je, je hezké vidět, že to někam směřuje, ale když o 100% vylepšíte formát, který je naprosto archaický, neznamená to, že bude výsledek užitečný...

Pozor. Formát Theory 1.0 byl zmražen a už se s ním nebude hýbat, ale s formátem Theory 1.1 určitě, takže pokud máte nápady, tak zasílejte a implementujte.

Četl jsem vyjádření vývojáře x264 a ffmpegu. Řekl, že theora je horší formát než mpeg4 asp (xvid)

Theora se s jakýmkoliv MPEG-4 nedá vůbec srovnávat. Možná tak s MPEG1/2. Vždyť jak sám říkáte, nemá MVP, GMC ba dokonce ani B-frames. To se potom těžko srovnává. Dokonce se divím, že se dá srovnat s MPEG2. Na druhou stranu je také dobré ptát se proč tyto funkce Theora(a pokud vím já, tak ani žádný jiný otevřený formát) nemá zahrnuté a nejsou v žádném kodeku implementované.[1],[2],[3]

[Mandarinka]

Myslím, že Dirac má b-frames a predikci vektorů (ač je psaný tak, aby se vyhnul patentům). GMC nebylo užitečné, však ho taky nedali do h.264...

[Mandarinka]

Co se týče toho entropy kodéru, tak koluje bonmot, že je schopný vygenerovat data, která jsou větší než vstup...

Myslím, že VP3 hodně věcí dělalo s cílem být jiný než mpeg - díky tomu asi taky mají tenkodek patentově pokrytý a mohli ho dát k dispozici. Něco jako vývojáři Diracu. Záškodnictvím bych to nenazýval, je prostě velice starý, přes deset let. Kdosi poznamenal, že vyvíjet to dál je jako vyvíjet Indeo5 nebo podobnou zapomenutou technologii. Zkrátka divné. Ten kodek bude vždy potřebovat podstatně víc bitrate než h.264 (pokud se nepoužije quicktime, hehe), takže pro internetovou distribuci bude vždycky přinášet vyšší náklady, i když bude bezplatný...

P.S. Doporučuje se usadit v kanále #x264 na irc.freenode.net (případně taky #ffmpeg a #mplayer), často se tam tyhle věci probírají, stačí poslouchat ten cvrkot :).

[Grunt]

Myslím, že VP3 hodně věcí dělalo s cílem být jiný než mpeg - díky tomu asi taky mají tenkodek patentově pokrytý a mohli ho dát k dispozici.

Přesně tak. Je chyba obviňovat Theoru z něčeho za co nemůže a naopak místo toho blahořečit novodobé digitální mafiány/výběrčí výpalného.

je prostě velice starý, přes deset let.

No a? Vždyť MPEG4 ASP je ještě starší a MPEG1/2 sahá snad někam do poloviny osmdesátých let(a je tak mnohem starší než Theora a přitom efektivnější). Stáří s tím nemá co dělat.

Kdosi poznamenal, že vyvíjet to dál je jako vyvíjet Indeo5 nebo podobnou zapomenutou technologii.Zkrátka divné.

Bohužel, v dnešní době je to jediná možnost. A nebo snad máte lepší nápad?

Ten kodek bude vždy potřebovat podstatně víc bitrate než h.264 (pokud se nepoužije quicktime, hehe), takže pro internetovou distribuci bude vždycky přinášet vyšší náklady, i když bude bezplatný...

Pokud se to u nižších rozlišení nechá v okně a neškáluje, tak ten rozdíl není tak patrný a nebo aspoň dle samotného přehrávání nejde moc poznat, že se jedná o Theoru. A navíc bych řekl, že lidé už jsou z YouTube zvyklí na ledacos, takže Theora nemůže nikoho vyvést z rovnováhy. U HD videa už jsou sice v obou variantách(zatím) dost problematické blokové artefakty, ale zase pro HD video se dá použít jiný formát(sníh, Dirac)

P.S. Doporučuje se usadit v kanále #x264 na irc.freenode.net (případně taky #ffmpeg a #mplayer), často se tam tyhle věci probírají, stačí poslouchat ten cvrkot :).

No, nevím. Zrovna řeším jeden bug mezi ffmpeg a x264 a když jsem tam přišel tak se řešili nějaké problémy s UTF a PHP, tak jsem to vzal oklikou radši do dev.

[Mandarinka]

Ale jistě že s tím stáří má co dělat. Za deset let se vyrojilo spoustu konkurence a slabší kodeky byly vytlačeny. Před deseti lety nebylo nic moc použitelného. Videa s 4cc "DIV3" jsou škaredým svědectvím dob, než přišel divx5 a ještě spíš xvid. I ty mpeg2 enkodéry byly tenkrát špatné, viz leckteré DVD z té doby, byť má bitrate třeba přes 8mbit/s... To, co k něčemu bylo (mpeg4 asp jako formát), přežilo a drží se dokonce i dnes, když už jsou podstatně lepší alternativy. Dokonce i realvideo10 na webu žije, byť sehrává dost ostudnou roli (77MB předělávky obyčejně již poměrně nekvalitnách ripů). Naproti tomu VP3 moc nadčasové nebylo a rychlo zapadlo, jako ten Radius, Cinepak a co to ještě je defaultně v w98 :).