Theora - opět mrtvý formát

12.7.2010 19:47 | Přečteno: 2237× | Opensource | poslední úprava: 13.7.2010 15:03

Theora, jeden z mála open-source video formátů, byla po dlouhou dobu úspěšně ignorována i ze strany open-source komunity. Reinkarnace se dočkala až v poslední době, kdy její podporu v HTML 5 přinesli prohlížeče Firefox a Opera a očekávalo se, že se stane na webu dominantním formátem (dokonce byly snahy ze strany Mozilly tento formát přímo do specifikace HTML 5). Naštěstí se tak nestalo a tento formát snad už nadobro skončí v softwarovém nebi. Proč naštěstí? Nahradí jej totiž VP8 spolu s H.264, formáty o několik řádů kvalitnější. Stačí se podívat na následující dva obrázky, pocházející z videa se stejným bitratem. Zajisté hned poznáte, který snímek pochází z kterého videa.

Zdrojová videa:

• VP8
• Theora 1.1

Edit: Na posledním obrázku je ukázka z vývojové verze Theory 1.2. Výsledek je ještě horší než u verze současné.

       

Obrázky

Komentáře

[mirec]

Čítam tu samé podložené tvrdenia a transparentné metódy testovania :D

[=^..^= AmigaPower®]

Nepoznám! A upřímně řečeno, mam to v prdeli...

[jyrki]

+1

[Rastafan]

To je teda exaktni metoda. co kdyz v theore bylo uz nekolik vterin od klicoveho a v h.264 to je klicovy snimek?

[kotyz]

tak si pust ty dve videa, rozdil by nepoznal jen slepej. theora kostickuje jako prase a webm je hladky jako detska prdylka (samotnyho me to prekvapilo, protoze se vsude pise jak je webm minimalne o 30% horsi nez x264)

[kralyk z abclinuxu]

je hladky jako detska prdylka

Uáááááááá, rychle, kde mám to velký červený tlačítko "Nahlásit"... jo tady, ok dobrý, uff

[Grunt]

webm je hladky jako detska prdylka

Deblocking u VP8 je naprosto šílený. Já mám radši kostičky Theory, ale ještě radši kostičky MPEG-1/2.

[Mandarinka]

Ono to ani tak nebude ten loopfilter (ačkoliv, mám pocit, že ten jejich dekodér umožňuje a nedejbože možná že i defualtně používá i normální postprocessing, i když už má ve formátu loopfilter), jako spíš že to nemá žádné adaptive quantization, ani žádnou jinou optimalizaci na vzhled videa, takže všecko skončí rozmazané.

[Grunt]

No nevím. Myslím si, že ještě poznám sinusovku v bloku (kolik to může mít? 16x16?) od rozmazance přes půl obrazovky. VP8 používá opravdu velice silný deblocking.

[mirec]

Kvalita je často závislá aj od enkóderu a ten v súčanej verzii libtheora nie je ktovie aký, ale pracuje sa na tom.

[Dadam]

Který je který? Jeden je ostřejší, ale druhý má hezčí barvy

[kotyz]

to je subjektivni, me se vic libi barvy u toho webm ...

[Dadam]

To fakt? Mně to přijde jako kdyby přes něj přetáhli jemnou bílou fólii...

[AsciiWolf]

+1

[Grunt]

Jeden je ostřejší, ale druhý má hezčí barvy

Z toho si nic nedělej. To zas je jenom Acci lama a neumí používat nástroj png2theora.

[Mandarinka]

Barvy jsou špatně protože autor "testu" si nedal bacha na konverzi yv12 do rgb. Ten vybledlejší obrázek patrně používá TV-rozsah, zatímco ten kontrastnější PC-rozsah. Ve videu je to vše stejn=, jde skutečně jen o chybné nastavení rendereru (či kopnvertoru do rgb který používá screenshotovací utilita). Jinak samotřejmě je chyba, že není použit identický frame.

Viz bod 1 ;)

[Acci]

Máš pravdu, kaji se, jedno jsem pořídil přímo přes funkci VLC a druhé jako snímek obrazovky. Teď už jsou nahrány správné obrázky i ve stejný okamžik. OGV je totiž oproti WebM o jeden snímek posunut.

[Acci]

Špatné barvy byly způsobeny chybou v obrázku, už je to napraveno.

[#Tom]

To je zápisek na nic. Porovnání je značně subjektivní, zejména když jedinou zveřejněnou informací je stejný datový tok. O to víc, že na každém obrázku je zachycen jiný okamžik.

[Acci]

Zachytit stejný okamžik se mi bohužel nepodařilo, ani jeden z formátů nedokáže VLC nebo MPlayer pořádně přehrát a při seekování spadnou. Do článku jsem proto přidal odkazy na videa, ze kterých byly snímky pořízeny, abyste si to mohli porovnat sami.

[Jendа]

mplayer qos_480.webm -vo png nepomůže?

[Kvakor]

To by se dalo obejít nastavenim "výstupního zařízení" na výstup obrázků, pro porovnávání nejlépe do PNG, pomocí mplayer -nosound -vo png <jméno.videa>. Bohužel pro delší videa je to trochu nepohodlné, ale i to je řešitelné parametry -ss, -bs -endpos a -frames.

[kotyz]

sou tam odkazy na zdrojovy videa. podle tech sem se taky ridil, na obrazky sem dlabal (navic tam neni napsano z kteryho videa kterej pochazi, ikdyz je to naznaceno a kazdej si to asi domysli) ...

[robotics]

Theoru v Linuxu mplayerem přehraju, ale to druhé mi nejde , objeví se jen milion barevných kostek a to je vše.

[Jendа]

Máš blbý MPlayer, mně to jede (MPlayer z debian-multimedia pro sida).

[robotics]

Ja mam debian lenny...

[Jendа]

Škoda, starý MPlayer.

[Jendа]

Theora, jeden z mála open-source video formátů

Jak může být formát open-source? Theora není o nic víc open-source než třeba H.264, MPEG-4 Part 2 ASP, MPEG-2 video, MPEG-1 video, MJPEG a další.

[retroslava]

Pokud se nemýlím, tak na některé z těchto formátu drží někdo patent. Na Theoru nikdo patent nedrží.

[Jendа]

Jasně, ale open-source je něco jiného než bez patentů.

Na Theoru nikdo patent nedrží.

Drží, ale zavázal se, že nebude vybírat licenční poplatky.

[Amarok]

Proc by format nemohl byt open-source? Videoformat nekonci jen definici headeru, ale definuje i plno algoritmu a ty jsou jednoduse open-source (ke koderu Theory snad sezenes otevrene zdrojaky v C, ne?) a zaroven bez patentu, jak tu uz nekdo psal.

[Grunt]

Protože v tomto smyslu jsou všechny formáty MPEG Open-Source počínaje MPEG-1. Je to standard ve kterém se udává specifikace (a to jak audio/video formátu, tak formátu souborového, datových kanálů, synchronizace, …), conformance testing a většinou i nějaká referenční implementace (zatím nevím o případu, kdy by bylo použito něco jiného než Céčko) ze které ve valné většině případů vzniknout svobodné kodeky (x.264,LAME,TooLame,FAAD,FAAC,XviD,… – všichni tito nevznikli na zelené louce, ale právě z referenční implementace).

[otasomil]

Je nesmysl porovnavat dva uplne jine snimky z filmu.

Dokazete-li vybrat totozne snimky tak to prosim udelejte at muzeme skutecne porovnat.

A vsem je uplne jedno jake video jaky format, hlavne ze to pojede.

Bohuzel pravda je v tom ze treba celovecerni film o velikosti 700 MB (jez se da behem hodiny, dvou stahnout) je pro naprostou vetsinu lidi dostatecny a urcite nebudou sosat BR rip v mkv o velikosti 8 ci vice GB nehlede na skutecnost ze takovychto filmu je minimum ne-li vubec zadne.

Nikoho nezajima Xvid, Divx, mpg, mp4, mkv, ogv  .... hlavne ze to nejak hraje a je to ZADARA.

[robotics]

Mě teda mkv zajímá . A sosám ho převážně u filmů, kde chcu vidět efekty a potom u filmů, které mám oblíbené a chcu je v kvalitě.

[Grunt]

Mě teda mkv zajímá . A sosám ho převážně u filmů, kde chcu vidět efekty a potom u filmů, které mám oblíbené a chcu je v kvalitě.

Další takový expert. Matroška je kontejner a nemá vliv na jediný pixel z videa!

[Jendа]

A dole ještě jeden (kotyz). Já už jsem to vzdal…

[Grunt]

No jo, to holt důsledek toho, že nikoho nezajima Xvid, Divx, mpg, mp4, mkv, ogv  .... hlavne ze to nejak hraje a je to ZADARA.

Stejně je ta premisa nepravdivá, protože min. jeden tady je a naopak mě nezajímá jestli to je ZDARMA nebo ne a nebo jestli to nějak hraje.

[kotyz]

ale ma vliv, protoze se do ni cpe vyhradne x264 ktery mi to nestiha (720p flv nebo mov prehraju v pohode, 720p mkv ne) ...

[Jendа]

(aaaargh, x264 je kodek!!!)

Ale H.264 můžeš nacpat třeba i do AVI (fuj) nebo mp4.

720p flv nebo mov prehraju v pohode, 720p mkv ne

Protože v tom FLV je asi zabalené H.263 a co je v MOV si netroufám odhadovat.

[skonciljsem]

co je v MOV...

QuickTime Video (http://mov.extensionfile.net/), údajně jejich MPEG 4.

[Grunt]

Do QuickTime File Formatu se dá nacpat kde co. Dřív se tam cpaly Soronseny a bůh ví ještě co. Prostě co Apple potřeboval využít, to si tam nacpal.

[kotyz]

tjn, kdyz sem na ty 720p videa pustil mediainfo tak u tech flv/mov to psalo: Format: AVC, Format/Info: Advanced Video Codec, Format profile: Main@L3.1 pripadne Format: AVC, Format/Info: Advanced Video Codec, Format profile: High@L3.1 a u mkv zase: Format: AVC, Format/Info: Advanced Video Codec, Format profile: High@L4.0

[kotyz]

vim ze x264 je kodek, ale jinej kodek se na to h.264 snad ani nepouziva ...

[Grunt]

Ba naopak. Kodeků jiných než X264 se používá spousta. Především komerčních. Akorát u Warezu se nikomu nechtějí platit licence.

[Mandarinka]

No, dnes už to určitě není o prachách. Naopak to, že warezáci-rippeři newarezí i komerční enkodéry (proč by zrovna notoričtí "zloději" měli mít legální soft...) je důkazem kvalit x264 :) Ačkoliv jistě zapůsobilo i to, že šlo o přirozenou náhradu předtím zavedeného divxu a xvidu (avisynth jako vstup, původně vfw rozhraní pro virtualdub).

[kralyk z abclinuxu]

ale ma vliv, protoze se do ni cpe vyhradne x264

Do mkv se dá nacpat cokoli...

[kotyz]

da, ale cpe se tam zasadne to co mi komp nedokaze plynule prehrat. zatim s kazdym 720p videem v mkv byl problem, zatimco 720p videa ktery v mkv nebyly, byly vetsinou bez problemu. jinak uz sem videl i mkv ve kterym byl nacpanej nakej divx v "obycejnym" rozliseni, ale to je spis rarita (taky to uz nejakej ten patek bude, dneska uz by nejspis nikdo neco takovyho nestvoril).

[mirec]

Čo je to za stroj? Môj intel core 2 duo 1.5GHz to zvláda bez HW akcelerácie (mám starú intel grafiku x3100).

[kotyz]

starej Athlon XP 2800+ (2.0 GHz) s GeForce 7600 GT v AGP, takze akcelerace se pouzit neda (vdpau funguje az od GF 8xxx vejs, ale ty se uz do AGP nedelali).

[Semo]

Nieco robis blbo. Ma to iste, iba 2.2GHz s nvidia 7600GS a s 720p som este problem asi nemal. S 1080p uz hej, ale to je aj tak viac ako zmestim na monitor (1280x1024), takze sa za nimi netaham. Mplayer. Ak si potrebujem pozriet 1080p a uz to seka, tak pouzivam (bez mnou nejak viditelnej straty kvality) "-lavdopts=fast=1:skiploopfilter=all". V KDE4 okolo10-15% vykonu CPU zaberaju tie beziace cisielka v konsole (blbci si to ani nie su ochotni uznat, ze v KDE3 to zralo asi 2-3%) a tak este pomoze "-quiet".

[J. M.]

No, s tím vytěžováním procesoru běžícímí čísilky v konzoli – zaprvé, jediné přípustné číslo je nula procent. I 2-3 procenta je na 2,2 GHz procesoru obscénně příliš. Ale podle mé zkušenosti nejde ani tak o KDE 3 (respektive Qt 3) versus KDE 4 (respektive Qt 4), ale o to, že celá grafická infrastruktura X.org, i to pod ním (jádro, kernel mode setting...) i nad ním, v posledních letech velmi výrazně zpomalila, s tím, jak se překopávala a inovovala. Takže na podobném procesoru mi už i v obyčejném spartánském xtermu, kde vždycky odjakživa jakákoli běžící písmenka nebo cokoli jiného měla režii 0 procent, už vytěžují procesor na 10-20 procent. Qt 4 je v těchto věcech často nevinně, jenom je bržděno zpomaleným podvozkem. (To mi připomíná, jak v té nové recenzi Mandrivy tady si autor posteskl, že samotný grafický měřič vytížení systému výrazně vytěžuje systém. To je opravdu specifikum Linuxu a X11, to v normálních grafických systémech neexistuje. Ve Windows i na staré šunce má obdobný program sledování systému režii nula.)

[Semo]

Ked si pustam mp3 v mplayeri (s cisielkami) x xterme, tak xterm zerie 0.3% (2.2GHz CPU). Ked v konsole, tak konsole zerie cca 12%. X-ami to asi nebude.

[J. M.]

Nejde jen o to, kolik žere ta aplikace, ale jaké je celkové vytížení systému. Často v takových případech, kdy aplikace něco vykresluje, minimálně polovinu výkonu sežere X.org. Potom samozřejmě záleží i na spoustě dalších věcí. Grafický ovladač, jestli správce oken používá kompozitní režim, u Qt taky veký rozdíl dělá grafický backend: X11 nebo raster (hardwarově akcelerovaný XRender, který je pod X11 jako výchozí, je 2x-3x pomalejší než čistě softwarové vykreslování), případně OpenGL. No ale tou Konsolí to asi může být taky. Já zase používám GTK+ konzole založené na libvte a ty mají samořejmě taky mnohonásobně vyšší režii procesoru oproti „holým“ X11 konzolím typu xterm nebo rxvt. Asi bych u té Konsole zkusil vypnout compositing, zapnout raster, a zkusil, co to s těmi čísly dělá...

[Jendа]

DivX je taky kodek, (od verze 4) používá formát MPEG-4 Part 2 ASP .

[Robotics]

Nemusím být expert na to abych nepoznal rozdíl mezi 700MB avi a 4GB MKV. Je mi celkem ukradený jakou to bude mít koncovku, hlavně, že to přehraju a obraz bude kvalitnější než 700MB avi. Což u filmů s koncovkou MKV je. Akorát ty 1080i mi PC nějak nestíhá, tak stahuju jen 720i.

[Grunt]

Nemusím být expert na to abych nepoznal rozdíl mezi 700MB avi a 4GB MKV.

LOL, ty si fakt expert. A co rozdíl mezi 4GB avi a 700MB MKV? To by si poznal? Do AVI se dá nacpat AVC stejně dobře (teda moc dobře ne, protože AVI, ale to teď nechme stranou) jako do Marošky. Naopak Matroška může pobrat klidně i YUV420p (minimálně YUV4MPEG určitě), ale také ASP, Theoru a já nevím co ještě. A není vůbec omezená na videoformáty, ale klidně se do ní dá nacpat MPEG-1 Layer III(MP3), Layer II(MP2) jako Vorbis(OGG) nebo obyčejné PCM(WAV).

hlavně, že to přehraju a obraz bude kvalitnější než 700MB avi

Velikost výsledku s kvalitou zas souvisí jak?

Což u filmů s koncovkou MKV je

Ach jo. Ne, končím. To nemá cenu, tohleto.

[Robotics]

Děkuji, že si mě označil za experta . Samozřejmě,že jím nejsu . Mě jde o to, že malé avi 700MB nebude mít nikdy stejnou obrazovou kvalitu jako 4GB video s jakoukoliv koncovkou a použitým kodekem. Proto prostě stahuju HD filmy. O to mi jde. . Je mi jedno jestli to bude mkv koncovka nebo avi koncovka. Protože mám na disku HD film i s avi koncovkou.

[Robotics]

A nejlepší kodek je teda jaký? Protože informace u těch mkv filmů o tom jaký byl použitej kodek napsaná je. Takže mi aspon porad jakej je nejlepší, co se týče obrazové kvality .

[Grunt]

Nejlepší kodek, co se obrazové kvality týče, se jmenuje uvázat si mašli.

[Robotics]

No tos mi teda poradil. A nevím co se furt rozčiluješ kvůli tomu, že tomu nerozumím .

[kralyk z abclinuxu]

Ono se na tu otázku nedá dost dobře odpovědět. Jak definuješ nejlepší kodek - nejlepší kompresní poměr? Nejlepší věrnost obrazu? Nejlepší poměr výpočetní náročnosti a kompresního poěru? Těch kritérií je zkrátka hafo a různé kodeky (BÚNO formáty) se hodí na různé účely...

[Grunt]

Děkuji, že si mě označil za experta

Ty jo, modporbe ironie.

Mě jde o to, že malé avi 700MB nebude mít nikdy stejnou obrazovou kvalitu jako 4GB video s jakoukoliv koncovkou a použitým kodekem.

A mně jde o tom, že malé avi 700MB klidně může mít větší obrazovou kvalitu jako 4GB video s jakoukoliv jinou koncovkou a použitým video formátem. Pomineme-li teda blábol jako obrazová kvalita.

Proto prostě stahuju HD filmy

Protože proč? Mi to nějak uniklo.

Je mi jedno jestli to bude mkv koncovka nebo avi koncovka. Protože mám na disku HD film i s avi koncovkou.

Nejde o koncovky. V souboru s .mp2 koncovkou klidně může být MPEG-1 Layer III stream. Jde o kontejnery.

[kralyk z abclinuxu]

Mě jde o to, že malé avi 700MB nebude mít nikdy stejnou obrazovou kvalitu jako 4GB video s jakoukoliv koncovkou a použitým kodekem.

Nóó, tak čistě teoreticky, 700MB h.264 bude imho mít lepší kvalitu než 4GB MPEG-1 ...případně by se jistě dal najít jiný archaický kodek, či rovnou RAW

No ale je jasné, že běžný uživatel se s takovým případem nejspíš nesetká...

[Grunt]

Nóó, tak čistě teoreticky, 700MB h.264 bude imho mít lepší kvalitu než 4GB MPEG-1

Ne čistě teoreticky, ale i prakticky. Teda pokud se nepoužije nějaký Baseline profile.

kvalitu

Ach jo. Si snad chtěl říct kompresní poměr. Protože jsem si ještě nevšiml, že by třeba vůbec někdo zohledňoval rozlišení.

[Jendа]

Mě jde o to, že malé avi 700MB nebude mít nikdy stejnou obrazovou kvalitu jako 4GB video s jakoukoliv koncovkou a použitým kodekem.

Nechce se mi přes cizí linku tlačit 4,7 GB, takže si za domácí úkol zakóduješ nějaké video x264 a zabalíš ho do AVI a pak nějaké do MJPEG a zabalíš ho do MKV.

[Robotics]

ok, je jasný, že starý kodeky jsou horší.

[Robotics]

Já už ani vlastně nevím co tu vlastně řeším.. kontejnery, popelnice.. jdu si hodit mašlu. Ale až poté, co kouknu na nějaký filmek ve vysokým rozlišení .

[Grunt]

Nejsou horší. Jsou prostě starší a tím méně efektivní. Teda formáty. Kodeky totiž zrají jako víno a čím starší, tím lepší.

[kralyk z abclinuxu]

urcite nebudou sosat BR rip v mkv o velikosti 8 ci vice GB nehlede na skutecnost ze takovychto filmu je minimum ne-li vubec zadne.

Tak s tím bych lehce nesouhlasil (atd. atp.)

[otasomil]

To je sice pekny, ale tohle neni zajimavy vubec. Navic stranka, kde na uzivatele vyskoci formular pro prihlaseni je nezajimava zcela.

Jako chapu ze par (doslova 2) se najdou, ale to je vse.

[kralyk z abclinuxu]

Stránka, kde vyskočí přihlašovácí formulář (i.e. soukromý tracker) nabízí často mnohem zajímavější obsah než ty veřejné.
Krom toho, ty dva odkazy co jsem napsal rozhodně nejsou "vše".

[kotyz]

pro me teda naky 700 MB (ani 1.4 GB) avicko dostatecny neni, stahuju iso image dvd pokud je to mozny. mkv me tolik nepritahuje, protoze muj pocitac je moc slabej na to aby ho prehral se vsi paradou ...

[Michal Čihař]

Hmm, jeden má vyblité barvy a je ostrý, druhý má dobré barvy, ale je rozmazaný. Ale nevím co že má být tak výrazně lepší.

[Grunt]

Situace začíná být čím dál zajímavější. Thusnelda už je minulostí. V současném vydání se konečně podařilo stabilizovat adaptivní kvantizaci (obdoba maskovacího efektu z psychoakustiky) a též kostičkování u přeskočených bloků a do dalšího vydání jménem Eyjafjallajökull se chystají také zajímavé změny, hlavně co se rychlosti týče. No na druhé straně VP8 docela krám (hlavně co do rychlosti) a neplánuje se s ním (krom manažerských rošád) zatím nic, takže jestli to takto půjde dál, je možné že se jednoho dne dočkáme toho, že Theora se dostane na úroveň VP8.

BTW: Poskytni zdroj, ať si můžu test ověřit, popř. ho provést pořádně.

[Mandarinka]

To by byla ostuda :) Kdo ví, třeba si nakonec někdo flusne do dlaní a udělá pro vp8 ten částečný přepis x264 :)

[Amarok]

Problem je hlavne v tom, ze vetsina lidi testuje starsi verze Theory, o tom jsem videl i porovnavaci testy a stvalo me to. Neverim tomu, ze je aktualni verze Theory na tom tak strasne mizerne v porovnani s x/h264 nebo treba vp8. Hlavne Theora neni delana na nizky bitrate, to je jako srovnavat pri 1000 kbps mpeg2 video a xvid.

[Grunt]

Problem je hlavne v tom, ze vetsina lidi testuje starsi verze Theory

No tak schválně.

Neverim tomu, ze je aktualni verze Theory na tom tak strasne mizerne v porovnani s x/h264

Je. Ale je to hlavně kvůli algoritmům. Je to podobné jako chtít vytáhnout něco víc z MPEG-1.

Hlavne Theora neni delana na nizky bitrate

To není nikde řečeno. Theora je určená na do celkem širokého nasazení stejně jako většina ostatních.

[Grunt]

No tak schválně.

Ach jo:

Zpracovávám soubor "qos_480.ogv"...

Nový logický proud (#1, sériové: ff74ec56): type theora
Nový logický proud (#2, sériové: ff77ff82): type vorbis
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Dodavatel: Xiph.Org libtheora 1.1 20090822 (Thusnelda)
Width: 854
Height: 469
Total image: 864 by 480, crop offset (0, 11)
Framerate 24000/1001 (23,98 fps)
Pixel aspect ratio 1:1 (1,000000:1)
Frame aspect 1,820896:1
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 1200 kbps
Nominal quality setting (0-63): 0
Hlavičky vorbis zpracovány pro proud 2, následují informace...
Verze: 0
Dodavatel: Xiph.Org libVorbis I 20100325 (Everywhere)
Kanálů: 2
Frekvence: 44100

Nominální bitrate: 109,000000 kb/s
Vyšší bitrate nenastavena
Nižší bitrate nenastavena
Následuje oblast poznámek uživatele...
	encoder=Lavc52.78.1
Theora stream 1:
	Total data length: 1684177 bytes
	Playback length: 0m:10.468s
	Average bitrate: 1287,007749 kb/s
Logický proud 1 skončil
Vorbis stream 2:
	Total data length: 126147 bytes
	Playback length: 0m:10.495s
	Average bitrate: 96,153946 kb/s
Logický proud 2 skončil

[Acci]

Verze 1.1.1, kterou jsem použil, je nejnovější stabilní verze, která existuje.

[Grunt]

A máš představu jak je stará a kolik změn se Theoře od té doby událo?

[Acci]

A to je snad moje chyba nebo chyba tvůrců libtheory, že ji nevydají?

[Acci]

Tak jsem schválně zkusil použít i vývojovou verzi 1.2, výsledek můžeš vidět na posledním obrázku. Je ještě horší než verze současná.

[Amarok]

A cim to bude? Samozrejme nastavenim. Je to proste blby, kdyz je kodek v defaultnim nastaveni takhle blbe pouzitelny, to je jasne chyba vyvojaru, ze to nedaji nejak lip dohromady. U xvidu mi taky procitani moznosti nastaveni pripada jak nejake sci-fi a jde z toho hruza, ruzne kombinace matic a 100 ruznych parametru pro 100 ruznych situaci... Kdo se v tom ma vyznat. Dobre je na tom ale pry x264 uz v defaultu, takze u toho asi zustanu (pro nahravky z kamery), hlavne umi i vyuzivat 2 CPU pri kodovani.

[Amarok]

A proc nikoho nezajimaji naroky ne dekodovani? Pro web podle me taky dulezita vlastnost. V dobe, kdy se v mobilu sleduje youtube, neni asi uplne jedno, jestli se dekoduje h264 nebo theora, tam musi byt diametralni rozdil v zatizeni CPU a spotrebe pameti. Nic o tom nevim, proto se ptam. Jen vim, ze h264 je pekny zrout oproti xvidu.

[Acci]

To je právě zatím obrovská nevýhoda VP8. Novější mobily totiž podporují hardwarovou akceleraci H.264 videa, pro VP8 zatím nic takového neexistuje, ovšem už se na tom pracuje.

[psonek]

Hlavne aby se dopracovali. Ja jsem zkousel na mobilu prehravat VP8 s ffmpegem a je to v 320x240 nepouzitelne - CPU 100% + framedrop. Theora se da sehnat optimalizovana pro ARM a ta zvlada theora video ve stejnem rozliseni uplne v pohode pod 50% CPU. Takze se neda rict ze by VP8 bylo zatim plnohodnotou nahradou. Aji kdyz ve ffmpegu je uz snad nativni implementace ktera by VP8 mohla casem zvladat dobre.

[VSi]

Jenže jak dlouho to vydrží hrát s trvalou 50% zátěží CPU? Předpokládám, že spotřeba bude v takovém případě o dost větší, než při přehrávání h264 v HW dekodéru. Takže podle mě pro mobilní zařízení, kde chceme minimální spotřebu, nemá skoro smysl řešit náročnost dekódování na CPU, ale možnost HW implementace toho dekodéru a jeho složitost.

A nakonec i kdyby byl u Tehory HW dekodér jednodušší než u h264, tak je otázka jestli by ho výrobci implementovali - to by musela být Theora minimálně stejně kvalitní nebo by musely nastat zásadnější problémy s licencování h264 (MPEG-4). Třeba v grafických kartách by šlo uvažovat o tom, že ty dekodéry budou "programovatelné", ale u mobilních zařízení je asi účelnější pevná implementace jednoho formátu.

Jinak VP8 bude mít zásadní naději na úspěch, až ho budou umět dekódovat nejčasteji používané grafické čipy v mobilních zařízeních (ale i jiných - televize s USB a ethernetem, stolní HD přehrávače - tyto zařízení dnes často umí h264 v MKV). Protože video na webu. A protože když ho tam dnes dám v h264/MP4, tak ho přehraje jak flash, tak iPhone, tak uživatel PC po stažení. A nemusím to kódovat do několika formátů. Ale prostý odkaz ke stažení není pro většinu uživatelů nejlepší, i když pro některé místní třeba ano. Normální člověk, co chce zkouknout 10 minut videa, nebude chtít 5 minut čekat, než se mu stáhne (a co teprve, když to video má hodinu).

[psonek]

No presne nevim, ale na 120 minut filmu to bude urcite stacit. Dekodovani na GPU je urcite dobre, ale neprecenoval bych to. CPU musi byt stejne zapnuty a bude urcite nejak vytizeny minimalne ctenim z SD karty/flash pameti + je zapnute podsviceni a display. Podle me GPU a CPU dekodovani se ve zrani baterky zas tak moc nebude lisit. Nemluve o to tom, ze spousta GPU jsou delane jenom na jeden kodek a nic jineho nikdy nebudou prehravat - proto je dobrej SW kodek jeste porad potreba.

[VSi]

Nemyslel jsem primárně GPU jako grafické karty v PC, resp. obecně v PC. V grafické kartě je hromada dalších obvodů, a dekódování komprimovaného videa je jen minimální část funkčnosti. Ale při použití takového Atom CPU, který má v IDLE spotřebu v jednotkách wattů, a HD video by nepřehrál, má HW dekodér smysl.

Nevím, co se používá v mobilních zařízeních jako třeba iPhone, ale takovýhle nějaký čip: http://www.sigmadesigns.com/products.php?id=94, který přehraje H.264 High Profile L4.0 v rozlišení 1920×1080 si vystačí s pasivním chlazením. No a s takovýmhle videem bude mít co dělat i obyčejné Intel Core 2 Duo na nějaké nižší frekvenci a bude mít přitom spotřebu nejmíň tak 20 W (odhad). V notebooku mám T2400 1.83 GHz a velká část 1080p filmů v h264 je na tom nepřehratelná, samozřejmě záleží na dekodéru.

[Jendа]

Ale prostý odkaz ke stažení není pro většinu uživatelů nejlepší, i když pro některé místní třeba ano. Normální člověk, co chce zkouknout 10 minut videa, nebude chtít 5 minut čekat, než se mu stáhne (a co teprve, když to video má hodinu).

Nemá i normální člověk v prohlížeči plugin, který umí přehrávat video tak, jak mu data postupně přichází?

[VSi]

Až na 90 % počítačů takový plugin bude, nebo bude snadno nainstalovatený (rozuměj, že prohlížeč ho nainstaluje sám po potvrzení jedním kliknutím), tak se takový způsob přehrávání videa rozšíří. Bohužel.

Resp. takový plugin tam má, a je to Flash. Možná do budoucna HTML5, pokud se ujasní situace s formáty.

Exituje takový plugin (kromě flashe), co umí seekovat v HTTP "pseudostreamu" ?

[Jendа]

Exituje takový plugin (kromě flashe), co umí seekovat v HTTP "pseudostreamu" ?

MPlayer plugin. Ale nemají okenní počítače by default WMP plugin, který by to uměl taky? Případně nenabídnou otevření přímo té URL ve WMP (bez stahování)? Nevím, okna nemám, ale myslel jsem, že jo (jak jinak by jim fungoval streaming ČT?)?

[VSi]

Streaming ČT se zobrazuje uvnitř prohlížeče pomocí Windows Media Player pluginu, který ale funguje obvykle jen v IE. Pro firefox se zase musí cosi doinstalovat. Jinak v tom FF to většinou ukáže v místě videa informaci, že chybí plugin. Mě to třeba ve Win XP/FF 3.6 ukazuje jen černou plochu s bílým nápisem "Waiting for video". Někdy se nabídne otevření v tom WMP, ale není na to spoleh. To už mi ve více přípdech funguje to Real Video (v klidu se otevře ve VLC nebo WMP / Media Player Classic).

Navíc tohle jde použít jen s WMV kontejnerem videa, a právě ten "pseudostream" to neumí. To, co má ČT, je jakýsi "pravý" streaming, kde se do toho motají nějaké protokoly jako MMS a kdo ví, co ještě. Ale hlavně na to je potřeba Microsoft server. Je to vhodné řešení pro živé vysílání. Ten "pseudostream" (třeba http://h264.code-shop.com:8080/testlist.html) funguje tak, že flash přehrávač pošle serveru GET parametr, kterým řekne, od kterého místa se začne. Server má základní "parser" na H.264 a umí zjistit, jaké místo souboru odpovídá danému času.

V současnosti je situace taková, že spolehlivé a na nestandardní konfiguraci serverů/licence nenáročné řešení videa v prohlížeči pro masy je výhradně Flash. Už umí přehrávat H.264 v MP4 kontejneru, a to samé umí nativně přehrát třeba i iPhone.

[Grunt]

Příloha:

• totem.png (136614 bytů)

Exituje takový plugin (kromě flashe), co umí seekovat v HTTP "pseudostreamu" ?

Nevím jestli plugin, ale nedávno podobnou funkci alias YouTube seekování implementovali do GStreameru a funguje s obyč. HTTP/1.1 a většinou klasických plexů.

[VSi]

To je dobré. Můžeš, prosím, zkusit jestli to funguje třeba tady na tom: http://h264.code-shop.com:8080/trailer2.mp4, resp. http://h264.code-shop.com:8080/testlist.html ?

[Grunt]

Příloha:

• stejne.png (232303 bytů)

Nevím, jak by to mělo fungovat? Stejně jako všude jinde.

[VSi]

Jestli jde seek na místo, které ještě není načtené. To právě zdaleka všude nefunguje. Tj. na tvém obrázku je načteno cca 10 %, tak jestli to jde posunout třeba do půlky bez toho, aby se čekalo na načtení až do toho místa.

Ten flash přehrávač v okamžiku změny polohy posuvníku do zatím nenačtené části udělá nový HTTP request s parametrem, který říká, z jaké místa se má "začít". Není to nějak standardní věc, takže se právě divím, že by GStreamer takovou věc uměl.

[Grunt]

Dřív to uměl. Teď zas pro změnu ne. Asi by to chtělo založit bug report, pokud je potřeba fakt taková dokonalost.

[VSi]

S tím požadavkem se v poslední době setkáváme (od platících klientů). U krátkých videí to tak markantní není. Ale pokud má video třeba 15 minut, tak je požadavek, aby to šlo "proběhnout" na několik posunutí. Prostě aby to fungovalo jako na youtube.

Navíc při větší zátěži konektivity tím přehrávám je vhodné to ke klientovi pouštět jen o něco větší rychlostí, než je bitrate videa. Hodně lidí totiž zkoukne první minutu a jde od toho. Když mají rychlou linku, tak za tu dobu může být 10minutové video zbytečně stažené celé. Když zavedete tohle omezení, tak se potřeba toho seeku projeví nejvíc.

Ohledně bugreportu nevím, jestli je tohle aspoň "de-facto standard". Ten request od flash přehrávače vypadá takhle:

1.2.3.4 vhost.domain.tld - [14/Jul/2010:00:59:47 +0200] "GET /video123.mp4?start=32.802 HTTP/1.1" 200 1074122 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3"

Tj. to není žádná věda, parametr start s hodnotou v sekundách, odkud chci začít. Na straně serveru to řeší modul, který obsahuje základní dekodér h264, aby věděl na jakém offsetu v souboru požadovaný čas začíná.

[Grunt]

Nevím jestli plugin

No jo vlastně. Ach jo, já jsem mamlas. totem-mozilla-plugin.

[Grunt]

V tom má Theora docela navrch, protože je dokonce rychlejší než (ff)MPEG-1 při dekódování (nebo dřív aspoň byla – nové vydání jsem ještě nezkoušel) a tak není problém přehrát 1080p na mojí Celerové plečcce o 2.8Ghz (kde se i Level 3.1 zadýchává). Bohužel, bloky 8x8 nejsou zrovna nejlíp vhodné pro HD video, takže to vyžaduje i docela vysoký bitrate. Ale obecně se dá říct, že pro vyské rozlišení a vysoký bitrate je Theora vhodnější než co jiného.

[Mandarinka]

1. No to tedy nevím nevím, vždyť theora má dokonce nějaký loopfilter! Starý formát ještě nemusí být navržen z ohledem na rychlé (a optimalizovatelné pomocí SIMD) dekódování. A proč by theora měly být lepší než například mpeg4 ASP, pro který jsou dobře optimalizované dekodéry. XVID zatím nebyl theorou poražen v kvalitě enkódování, a navíc je jeho enkodér i pekelně rychlý, což theora moc není, když se uváží, co dělá. Jo a taky xvid nějak rudimentálně podporuje vícejádra, libtheora nikoliv, zatím (a v krátkodobém horizontu to nečekejme).

A propos pro ilustraci, pro potřeby streamování fullscreen videa ("cloud gaming", lol) na ipad jeden z vývojářů potřeboval zhackovat nějaký video formát. H.264 ani theora nebyly použitelné, a tak úspěšně nasadil h263, přesněji řečeno flv1, když vyčistil nepotřebné věci z dekodéru (který je v ffmpegu společný pro několik formátů).

2. Transformace 8x8 naopak vadí u HD míň než u SD, protože objekty a detaily jsou ve frame většinou větší než u SD ;)

[Grunt]

No to tedy nevím nevím, vždyť theora má dokonce nějaký loopfilter!

Měla. Ale 64-pass. Tak demo2 nebo demo3 co ho vyhodili. Se mi to s ním zdálo trochu lepší.

A proč by theora měly být lepší než například mpeg4 ASP

Nevím, já jsem to nevyslovil. V rychlosti jsem je sice netestoval, ale IMHO budou stejně rychlé oba.

xvid nějak rudimentálně podporuje vícejádra, libtheora nikoliv, zatím (a v krátkodobém horizontu to nečekejme).

At the moment, the main feature mentioned as landing post 1.2 is encoder multithreading.

Transformace 8x8 naopak vadí u HD míň než u SD, protože objekty a detaily jsou ve frame většinou větší než u SD ;)

Též jsem si to myslel, ale subjektivně je to ještě větší hnus než u menšího rozlišení než SD a MPEG-1 vítězilo.

[Grunt]

Příloha:

• srovnani.png (721096 bytů)

A co takto mistře (u obrázku vlevo tvoje Theora 1.2 a vpravo moje Theora 1.2)? Neříkám, že je nějaký zázrak, ale rozhodně lepší než oba tvoje výsledky (a to tam ještě není Temporal RDO). Proto se také u seriózních testů zveřejňuje metodika testování, aby se daly ty tvoje nesmysly vyvrátit i bez zbytečného sraní. Ještě přihodím MPEG-1. Netvrdím, že je Theora nějaký zázrak (abych pravdu řekl, nejhorší z moderních formátů které znám), ale takové testování a vyhodnocování by si měli dovolit jen lidé, kteří jim rozumí do posledního šroubku (Monty) a ví kde to ještě zatlačit aby z toho vytlačili maximum, ne takové lamy jako ty. Je to velice komplexní věc. Což je mimo jiné také důvod, proč jsem se doposavaď do něčeho podobného nepustil a ještě dlouhou dobu nepustím. Prostě mám natolik svědomí, že v klidu můžu říct, že ještě ani zdaleka nemám potřebné množství znalostí, abych si mohl dovolit něco podobného srovnávat (a pokud nebudu dnes v noci při spánku osvícen, tak ty znalosti ještě ani dlouho mít nebudu).

[Mrkva]

No tak jestli on do toho rve nějakých 500kbps a ty 2Mbps, tak se ten rozdíl někde zákonitě projeví. Já jsem teď zkoušel libtheora a libx264, 720p, různé bitrate 512kBps-4Mbps a Theora ve všech testech dopadla o _dost_ hůř (upozorňuji, že ta theora byla z dnešního SVN).

[Grunt]

No tak jestli on do toho rve nějakých 500kbps a ty 2Mbps

Nope. On má nominální 1200kbps a průměrnou 1287,007749 kb/s, já mám nominální 1187kbps (holt jsem lama a neumím počítat) a průměrnou 1366,287394 kb/s (se to holt na celé délce projeví trochu víc než na nějakém ústřižku). Teda aspoň to tak odhaduju (kdyby zveřejnil metodiku, tak nemusím hádat):

$ /opt/vorbis-tools/bin/ogginfo ~/Videa/qos.ogv 
Zpracovávám soubor "/home/petrvlasic/Videa/qos.ogv"...

Nový logický proud (#1, sériové: 1f67658f): type theora
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Dodavatel: Xiph.Org libtheora 1.1+ 20100314 (Ptalarbvorm)
Width: 816
Height: 448
Total image: 816 by 448, crop offset (0, 0)
Framerate 24000/1001 (23,98 fps)
Aspect ratio undefined
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 1187 kbps
Nominal quality setting (0-63): 50
Theora stream 1:
	Total data length: 20180015 bytes
	Playback length: 1m:58.159s
	Average bitrate: 1366,287394 kb/s
Logický proud 1 skončil


$ /opt/vorbis-tools/bin/ogginfo ~/Videa/qos_480.ogv 
Zpracovávám soubor "/home/petrvlasic/Videa/qos_480.ogv"...

Nový logický proud (#1, sériové: ff74ec56): type theora
Nový logický proud (#2, sériové: ff77ff82): type vorbis
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Dodavatel: Xiph.Org libtheora 1.1 20090822 (Thusnelda)
Width: 854
Height: 469
Total image: 864 by 480, crop offset (0, 11)
Framerate 24000/1001 (23,98 fps)
Pixel aspect ratio 1:1 (1,000000:1)
Frame aspect 1,820896:1
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 1200 kbps
Nominal quality setting (0-63): 0
Hlavičky vorbis zpracovány pro proud 2, následují informace...
Verze: 0
Dodavatel: Xiph.Org libVorbis I 20100325 (Everywhere)
Kanálů: 2
Frekvence: 44100

Nominální bitrate: 109,000000 kb/s
Vyšší bitrate nenastavena
Nižší bitrate nenastavena
Následuje oblast poznámek uživatele...
	encoder=Lavc52.78.1
Theora stream 1:
	Total data length: 1684177 bytes
	Playback length: 0m:10.468s
	Average bitrate: 1287,007749 kb/s
Logický proud 1 skončil
Vorbis stream 2:
	Total data length: 126147 bytes
	Playback length: 0m:10.495s
	Average bitrate: 96,153946 kb/s
Logický proud 2 skončil

Já jsem teď zkoušel libtheora a libx264, 720p, různé bitrate 512kBps-4Mbps a Theora ve všech testech dopadla o _dost_ hůř (upozorňuji, že ta theora byla z dnešního SVN).

Třeba to bude tím, že Theora oproti AVC také o dost horší je.

[Acci]

To už vypadá celkem dobře, jaké bylo nastavení?

[Grunt]

Nechce se mi to linkovat, takže jsem použil referenční kódovátko:

ffmpeg -i ~/Videa/quantum_of_solace-tlr1_h1080p.mov -s 816x448 -f yuv4mpegpipe - | ./encoder_example -V 1200 --soft-target --two-pass --second-pass ~/Videa/qos.log -v 8 -k 500 -z 0 -  > ~/Videa/qos.ogv

[Grunt]

Jinak kodek je Ptalarbvorm.

[Acci]

A taky to samozřejmě neměl být nějaký objektivní test, to bych si taktéž netroufl, ale jen porovnání jednoho videa s výchozím nastavením enkodérů a s bitratem 1000 kb/s.

[Grunt]

Tak proč děláš závěry? Spousta lampasů co to neumí zreprodukovat se jimi bude řídit a ještě zadarmo zbraň do rukou těm mamlasům s nagelovanou kedlubnou a kravatou kolem krku. To doufám nebyl záměr.

[Grunt]

Příloha:

• mpeg1.png (585846 bytů)

Ještě slibovaný MPEG-1 (v tuto dobu stejně svobodný jako Ogg Theora). Obojí mi subjektivně přijde tak na přibližně stejné úrovni. Možná bych doporučil s malou špetkou deringingu.

[zulu]

Zase jeden úžasný zápisek, ve kterém nás autor poučí o něčem, čemu nerozumí.