Linux, Blu-ray a HD video vůbec

18. 9. 2008 | David Ježek | Multimédia | 19360×

Malé povídání o hardwarové akceleraci HD videa v Linuxu. Co je potřeba překonat, aby bylo možné přehrávat Blu-Ray (DRM a spol.). Jak je to s x264. Gallium3D.

Z hlediska plnohodnotného hardwarově akcelerovaného přehrávání HD videa v Linuxu je třeba úspěšně vyřešit dvě věci - tři, pokud do toho započítáme filmy na Blu-ray discích.

Zaprvé je třeba zprovoznit samotnou akceleraci videa. Zde se bavíme převážně o speciálních technologiích GPU, u NVIDIE jde o PureVideo, u ATI o UVD. Otázkou je, komu tu práci naložit, popřípadě koho postavit na pranýř za to, že to stále ještě nefunguje.

NVIDIA

V případě NVIDIE si dovolím říci, že to padá převážně na hlavu této kalifornské společnosti. NVIDIA se vyznačuje tím, že má pod Linuxem poměrně kvalitní a vyzrálé ovladače (KDE 4 a uspávání z toho prosím nyní vynechme). Sama je poskytuje jak pro všechny možné linuxové distribuce, tak i pro Solaris a x86 FreeBSD, potud je tedy vše takřka zcela v pořádku. Naproti tomu ale zcela ignoruje uvolňování dokumentace o architekturách svých GPU, důvody ponechme stranou. Zajímavě zní maximálně tak projekt Nouveau, ale z hlediska podpory funkcí GPU (2D, 3D, video, …) je výrazně pozadu za uzavřenými ovladači od NVIDIE.

ATI

U AMD je situace jiná. Po odkoupení ATI se stav stále zlepšuje a firma průběžně uvolňuje stále více a více dokumentace ke svým GPU, byť ani ona nemůže uvolnit vše. Bohužel oblasti zvané „hic sunt leones“ zahrnují i UVD, zejména proto, že součástí architektury zajišťující hardwarovou akceleraci HD videa jsou uzavřené části licencované firmě AMD (dříve ATI) jinými subjekty a AMD je tak nemůže pustit do světa pod některou svobodnou licencí.

Oficiální Catalysty, tedy přesněji grafický ovladač, který je v nich obsažen, něco takového skutečně v dohledné době přinesou. Během pár dnů nabídnou velcí partneři AMD ve svých počítačích s Linuxem přehrávání chráněného HD videa. Slajd z prezentace nezmiňuje přímo hardwarovou akceleraci, ale prozatím tiše předpokládejme, že to je samozřejmost (jaká to opovážlivost).

Jedinou vadou na kráse je fakt, že to bude (zpočátku) k dispozici pouze OEM partnerům, nikoli veřejnosti. Dovolil bych si drze předpokládat, že to má jednoduchý důvod: podpora bude zpočátku omezena na jednu dvě grafiky, případně na integrovanou grafiku v čipsetech 780G/790GX, plně funkční řešení pro všechny grafiky nabízející UVD možná ještě není zcela vychytáno. Ale logo Blu-ray dává příslib, že jsou tímto řešením automaticky vyřešeny i zbývající dva body (za chvíli).

Poslední Catalysty 8.8 také přinesly dvě zajímavě znějící knihovny libAMDXvBA.so.1.o a libXvBAW.so.1.o, které nás přivádějí k Xv alias X-Video. Podpora pro Xv je v proprietárních Catalystech již jistou dobu, stejně tak v otevřeném ovladači xf86-video-ati nacházíme Textured Video. Co chybí, je podpora XvMC alias X-Video Motion Compensation - rozšíření, které umožňuje přesunout dekódování MPEG-2 ze systémového procesoru na grafický (jen pro připomenutí: hardwarovou akceleraci MPEG-2 umí ATI už od dob Rage 128).

UVD

AMDXvBA a XvBAW jsou dle Phoronixu součástí kódu, který by měl zprovoznit právě akceleraci přes UVD(2). „Grepnutím“ z těchto knihoven lze získat jednoznačně znějící pasáže jako CreateUVDCommand, CreateUVDBufferPool, CreateUVDConfig, RegisterUVDClient, UVDSession, „unknown UVD IDCT buffer type ovverride“ a další. „Grepnutí“ dalšího řetězce nás ale přivádí k druhému bodu, který je pro hardwarové přehrávání filmů z Blu-ray disků třeba vyřešit.

DRM

Ta zkratka není nic jiného než DRM, tedy „oblíbený“ Digital Rights Management. V knihovnách lze vystopovat části jako SetupDrmKeys, SetupDrm, _ZN8UVDCodec10SetDrmKeysEv atd. Ty budou obstarávat potřebnou výměnu šifrovacích klíčů a další specialitky tohoto DRM systému. Připomeňme, že modelově je vše v cestě od laseru Blu-ray mechaniky až po HD monitor šifrováno, po PCI Express sběrnici běhá video stream šifrovaně, na výstupech se pak aplikuje buď HDCP (DVI, HDMI, …), nebo Macrovision (D-Sub, TV-out) ochrana. Ale protože je to již výrazně nad rámec hardwarového článku, pro podrobnosti si vás dovolím odkázat na stránky Microsoftu, kde je k dispozici velice obsáhlý materiál (DOC) demonstrující, co vše bylo potřeba ve Windows Vista implementovat, aby systém „dostal od Hollywoodu osvědčení jako Blu-ray přehrávač“.

V knihovně XvBAW pak lze ještě vystopovat XvMCSetAttribute, XvMCGetAttribute, XvMCWrapper, XvMCQueryExtension a mnohé další. AMD tak podle všeho přinese podporu pro XvMC i UVD2, ale ani to není vše, chybí nám třetí část skládačky.

Přehrávač

Mám tedy hardwarovou akceleraci a zajištěno potřebné šifrování a ochrany výstupů. Chybí již jen přehrávač. S ohledem na prolomení CSS ochrany DVD pomocí nezabezpečeného Xing přehrávače mají i softwarové nástroje pro přehrávání modrolaserových filmů jistá omezení. I ony jsou součástí řetězce, mají vlastní unikátní klíče, které lze při prolomení revokovat (to, že už byl dávno objeven „master key“ celého AACS systému je teď irelevantní), i ony musí splňovat zabezpečení komunikace, zejména co se týče dat a jejich způsobu uchovávání v paměti počítače.

Vzhledem k open-source povaze přehrávačů jako Mplayer si tyto ze seznamu rovnou můžeme škrtnout (jen pošetilec by si mohl myslet, že AMD se připojí k vývoji Mplayeru atd.). AMD nemůže využít nástroje, jaké jsou k dispozici ve Windows (DirectShow atd.), nebo se spoléhat na to, že například CyberLink přijde s linuxovou verzí PowerDVD 8. Na to je linuxový trh příliš malý, firma musí uvést vlastní řešení. Jestli to bude kompletní přehrávač, nebo vytvoří jakousi mezivrstvu, ke které právě nástroje jako Mplayer či MythTV budou moci přistupovat přes zdokumentované API, to ukáže až realita (ale spíše věřím v to druhé).

Blu-Ray

Každopádně součástí přehrávače bude muset být i kompletní podpora pro propracovaná menu Blu-ray disků. Filmy často využívají možností standardu BD-J (BD-Java) a implementují komplikovaná interaktivní menu, jednoduché hry a spousty dalších vychytávek (současně běžící PiP, kde není jen režisérský komentář ale přímo patřičná video stopa atd.) a pokud bude chtít certifikaci pro vyšší verze BD Profile (již dnes je 1.1 povinná), bude muset zapracovat i schopnosti stahování dodatečných materiálů z internetu a také nadstavbovou BD+ ochranu.

x264

Nicméně nejen lisovanými Blu-ray filmy je člověk živ. Jistě nejsem jediný, kdo má doma sbírku stovek filmů a tisíců episod seriálů komprimovaných pomocí x264 a uložených v Matrošce (pro TV graby ji používám již nějakých 6 let). Ve Windows akcelerace x264 videa v .mkv kontejneru již delší dobu funguje, takže doufejme, že bude toto v dohledné době zprovozněno i v Linuxu.

Samozřejmě vše, co zde zaznělo, se týká obecně nejen AMD, ale i NVIDIE, Intelu, S3 Graphics či kohokoli dalšího. Momentálně to ale vypadá, že AMD je nejdál ze všech. Ještě vám ale dlužím pár slov o open-source vývoji.

Zatímco mnoho grafických karet minulosti nemá s videem o běžném rozlišení problémy a akcelerují jej skrze XvMC, NVIDIA to od generace GeForce 8 neumí (zde je na vině vyřazení hardwarového akcelerátoru videa z GPU), stejně tak ATI je na tom mizerně (viz předchozí odstavce). V rámci projektu Nouveau sice probíhá vývoj XvMC pomocí reversního inženýrství, nicméně proč neudělat něco univerzálního?

Akcelerace pomocí Gallium3D

Jako součást projektu na Google Summer of Code 2008 se pokoušel (v pracech stále pokračuje) Younes Manton o vývoj univerzálního řešení pro hardwarovou akceleraci videa na GPU. Využívá přitom Gallium3D - 3D akcelerační systém vyvinutý v Tungsten Graphics. Gallium3D poskytuje univerzální API pro hardwarové funkce GPU jako shaderové jednotky (nyní zvané stream procesory), přičemž z 3D API umí OpenGL 1.x, 2.x 3.x, OpenVG a dokonce i Direct3D (zde pomocí Wine). Younes vyvíjí XvMC frontend pro Gallium3D, který by měl dekódování videa právě touto cestou přesunout na GPU.

Poslední informace o projektu říkají, že je již plně implementováno XvMC API s výjimkou prokládaného videa a subpictures. I přes provedené další optimalizace na lowlevel úrovni je však výsledek prozatím stále příliš pomalý, míra využití GPU je sice pod úrovní dostupných výpočetních jednotek v dnešních grafických procesorech, ale je třeba ještě doladit softwarovou stránku, tedy ovladač a zejména správu paměti.

Younes dále zkoumá možnost hardwarově prováděné IDCT (inverzní diskrétní kosinová transformace), na čemž v minulosti pracoval Stephane Marchesin a je tu šance portovat část jeho kódu pro NV40 (GeForce 6800) do Gallium3D ovladače.

Každopádně bez ohledu na to, jak vývoj Gallium3D verze dopadne, bude tomuto kódu chybět k dokonalosti vyřešení zbývajících zmiňovaných bodů, tedy zejména podpory pro menu, AACS, BD+, BD-J a další proprietární vymoženosti, které buď budou vyřešeny reverzním inženýrstvím, nebo vůbec. Pro přehrávání běžných souborů s HD videem ale tento projekt slibuje poměrně dost.

       

Komentáře

[onion]

Díky za pěkný článek.

Ještěže se mě jeho podstatná část netýká a troufám si tvrdit, že přehrávání chráněných BR disků je pravděpodobně to poslední, po čem dnešní uživatel Linuxu touží. Nebo snad někdo, kdo je schopen si nainstalovat Linux, bude zároveň podporovat zmetky typu MPAA nákupem chráněných BR disků?

Za nejzajímavější bych považoval poslední část o Gallium 3D, akcelerované x264 by se skutečně hodilo, protože s 1080p má problém i moje relativně zánovní E6300 (2 roky není žádná doba ;)), pokud není přetaktované. Řeší to CoreAVC kodeky, ale ty jsou jen pro Windows, takže nic (a jejich naroubování do mplayeru se mi nepovedlo).

[Selmi]

> Nebo snad někdo, kdo je schopen si nainstalovat Linux, bude zároveň podporovat zmetky typu MPAA nákupem chráněných BR disků?

obavam sa ze ano, po tom co som si pozrel par filmov v hd rozliseni ma uz obycajne dvd vobec nelakaju...

[d.f.h]

Nebo snad někdo, kdo je schopen si nainstalovat Linux, bude zároveň podporovat zmetky typu MPAA nákupem chráněných BR disků?

Ano, třeba já . Nicméně výrazně pohodlnější je přehrávat Blu-ray filmy na stolním přehrávači. Linux + Blu-ray mechaniku používám jen po získání screenshotů do recenzí filmů.

[Dusan]

Pekné zhrnutie.

Škoda ja by som rád aspoň pre hardvérovú akceleráciu h.264. Mám ati r300 aj nvidiu nv73. Napríklad my seká Paprika fulHDryp v h.264.

A Galium a va-api je myslím budúcnosť. Dúfam že vznikne projekt na nejaký vo zmysle libdvdcss aj na blueray aby nebol ten opruz ako z DVD.

ps. Ten chránený obsah cez tie super duper technológie fakt nemusím. Jedine vtedy by ma to štvalo keby dáke obľúbené anime alebo fakt dobrý film vyšlo na blueray s tými ochranami.

ps2. škoda že niesom programátor a nemám možnosť ani čas podporiť hore uvedené projekty. Ale keby sa toho niekto chytil takých 5000SKK by som mohol potlačiť.

[Pravák Bob]

"Nvidia sice má fungující ovladače, ALE... Zatímco AMD... (růžová budoucnost)" aneb nikdo vám nemůže dát, to co my slíbit. Nebylo by lepší psát o tom co teď funguje a ne co někteří slibují už léta? Všichni ví že David je příznivce AMD/ATI, ale v linuxu to je prostě jinak.

[Schmaker]

Srovnejte vývoj nVidia driverů a ATi driverů - možná vám to uniklo, ale ATi drivery udělaly za poslední rok OBROVSKÝ skok, který stále pokračuje - ať už jde o zprovoznění AIGLX, přes vydávání specifikací až po plánovanou podporu pro DRM... ATi má stále co dohánět, to je pravda, ale taky je vidět, že se to dohnat snaží

[Peter H.]

NVidia ovládače sa za posledný čas strašne posr..., hlavne čo sa týka ovládačov pre staršie karty - náhodné pády, občas je problém to vobec skompilovať. Takže onedlho sa to asi vyrovná.

[xm]

Ještě by bylo vhodné článek doplnit o informaci, že v rámci letošního Google Summer of Code pracoval jeden student na hardwarové akceleraci H.264 videa pomocí standardních OpenGL GLSL shaderů pro projekt media centra XBMC (které je i pro Linux). Ten kód je už prakticky hotový, zbývá jen dořešit pár problémů.

[Mandarinka]

Přesně. Naopak ono druhé řešení má tu nevýhdou, že potřebuje ovladač zvládající Gallium3d (jen noveau?), a za druhé poskytuje jen xvmc, tudíž akceleraci jen formátu mpeg2. A akceleraci mpeg2 člověk moc nepotřebuje, protože to není zdaleka tak žravé jako H.264 a H.264 je mnohem důležitější.

[xm]

Ne, řešení přes Gallium3D _je_ lepší a postupně na Gallium3D budou přecházet všechny ovladače v X.Org. Ta architektura je nesrovnatelně lepší než to co je v současných X.Org, mnohem lépe odpovídá novodobému hardware a jeho potřebám, je mnohem lépe navržená a univerzálnější. Navíc má Gallium3D obrovskou výhodu, že je schopné efektivně akcelerovat zcela libovolné API (nejen OpenGL, ale třeba také OpenVG, nějaké API na akceleraci videa, GPGPU API pro obecné výpočty na grafické kartě, atp.).

A btw. akcelerace videa přes Gallium3D nebude omezená jen na MPEG2, na to jste přišel jak? Kvůli tomu, že XvMC podporuje jen MPEG2? To je jen současná situace, pokud vím vývojáři Intelu ho chtějí rozšířit tak, aby podporovalo i akceleraci H.264 a dalších formátů. Zároveň s tím vyvíjí také zcela nové VA API, které lépe odpovídá moderním video kodekům a obecně současným potřebám. Díky tomu, jak dobře je navrženo Gallium3D, by nebyl vůbec žádný problém pak přidat podporu i pro VA API.

[Mandarinka]

1. Mluvil jsem o tom projektu, a ten implementuje dekódování pouze (ano!) mpeg2 (přesněji implementuje xvmc) tam, kde je podpora Gallium3d. Xvmc je dělán pro mpeg2 a na nic jiného se prakticky nehodí. Gallium3d má navíc zatím jen malé rozšíření. Možná si to pletete s VAAPI, to bude univerzálnější (nové) rozhraní pro akceleraci a bude umět i nové formáty. To je však ještě větší hudba budoucnosti. Důležitější však je, že mpeg2 akceleraci zdaleka tolik nepotřebuje, jako druhé dva, náročnější a rozšířenější kodeky: H.264 a VC-1.

2. Naopak druhý projekt (Roberta Rudda) se věnuje H.264, které je z kodeků v HD discích a vůbec nejnáročnější na CPU. Navíc funguje přes opengl, je diametrálně užitečnější. Snad to onen student MIT brzo dopíše. Tato akcelerace pomůže víc, tam kde je to třeba, půjde s větším množstvím gpu a nejspíš taky bude funkční mnohem dříve (kdy bude Gallium3d běžné?).

Tož toto jsem tím myslel a teď už je mi doufám rozumět.

[xm]

Nemáte pravdu, je to jak jsem psal já. Viz článek XvMC To Support More Video Standards? na Phoronixu. Intel sice pracuje na novém VA API, ale zároveň chce rozšířit XvMC tak, aby podporovalo i jiné formáty, než jen MPEG2 (hlavně H.264).

A to že Gallium3D může akcelerovat libovolné API (a že ta podpora pro akceleraci videa tedy bude na nižší úrovni než jen postavená nad OpenGL přímo v aplikaci) je jedině výhoda, je to mnohem univerzálnější a čistší design (aneb vašimi slovy "diametrálně užitečnější").

[Mandarinka]

Hudba budoucnosti. Mě zajímá praktické využití, ne jak je něco elegantního, hezkého nebo svobodného. Navíc moc nevěřím, že se jim povede napsat H.264 dekodér přes XVmc tak, aby to fungovalo se stávajícíma grafikama a ovladačema. Těžko. Možná za pár let, ale pak už to nebude moc třeba. Naopak - když Rudd dopíše svůj patch, máte fungující H.264 na opengl 2.0 grafikách teď, nezávsile na použitém ovladači (a asi i na použitém OS).

Pro ostatní přihodím linky na oba projetky, ať můžou přínos posoudit ostatní:

mpeg2 přes xvmc a gallium3d H.264 přes opengl; součást xbmc, de facto staví na ffmpeg

[Suchý čert]

A co CAVLC/CABAC dekódování? To se jim s OpenGL těžko podaří.

[Mandarinka]

Ano. Nicméně ulehčí procesoru od MC, IDTC, loop a jiných věcí, takže na bitsream zbude víc času (= nižší náročnsot na PCU). Při vysoké bitrate se nicméně může stát CABAC (CAVLC už ne) dominantní složkou spotřeby CPU, neboť alespoň v současném libavcodecu škáluje jeho cena lineárně s bitrate...

Na druhou stranu, ani druhý projekt (galium3d-xvmc) nemá ambice entropy coding dělat na gpu, přestože mpeg2 jej má o dost jednodušší. Troufám se vsadit, že to přes xvmc stejně nejde.

[JaRo]

Nejsem právnik, takže malý dotaz?

1. Nemá člověk v naší zemi náhodou zákonné právo pořídit si kopii díla pro vlastní potřebu? Pokud ano není DRM protizákonné? Zabraňuje mi v zákonném použití legálně zakoupeného díla.

2. A spousta sekundárních záležitostí. Např. EU chce nižší emise u aut, podniků atd. Podniky nakupují emisní povolenky, automobilky mají za auta nad určité emise platit, .... a tak se snaží snížit spotřebu a emise. Naproti tomu nějaký zvrácený filmový průmysl záměrně tlačí na firmy, aby dělaly opak. Vyhazují se peníze za technologie, které zbytečně žerou výkon procesoru a hlavně množství el. energie. Ve výsledku zvyšují emise. Kdo konečně na filmový průmysl potlačí?

Microsoft měl jedinečnou možnost. My linuxáci bohužel takovou pozici nemáme. Microsoft místo vyhazování peněz za implemenaci těchto "vymožeností" do Vist mohl vyvíjet pořádné technologie. Alespoň jednou by si u mě šplhl. Ať si filmový průmysl trhne a přehrává si své média s DRM na čem chce. Kdyby je nebylo na čem přehrán, nikdo by je nekupoval a tím by bylo po ochraně. Ale dokuď ovečky jen tiše reptají ale při tom dál otrocky slouží, je vše OK. Já média s ochranama nekupuji. Přece neplatím výpalné OSA, abych si nakonec nemohl udělat ani kopii pro vlastní potřebu.

Teda už to výpalné OSA mě štve, když vemu hromadu DVD jejichž obsah je mé autorské dílo ale "spravedlivou odměnu" za mou práci dostává úplněněkdo jiný.

[erchamion]

Ad 1 - kouknete sem: http://www.lupa.cz/clanky/je-kopirovani-pro-osobni-potrebu-stale-legalni/ Celkove zajimavy clanek, vasi otazky se tykaji predevsim posledni tri odstavce.

[JaRo]

Děkuji za odkaz.

Je to síla, ale úplně to nechápu.

Dle ustanovení § 43 odst. 3 autorského zákona se účinnými technickými prostředky rozumí "jakákoli technologie, zařízení nebo součástka, která je při své obvyklé funkci určena k tomu, aby zabraňovala nebo omezovala takové úkony ve vztahu k dílům, ke kterým autor neudělil oprávnění, jestliže užití díla může autor kontrolovat uplatněním kontroly přístupu nebo ochranného procesu, jako je šifrování, kódování nebo jiná úprava díla nebo uplatněním kontrolního mechanismu rozmnožování."

Proč mi tedy DRM zabraňuje přehrát legálně zakoupený disk. To znamená že přehrání díla je takový úkon ve vztahu k dílu, ke kterému nemám oprávnění. Proč mi tedy ten disk prodával? Vždyď mě podvedli. Nemělo by alespoň u těch médií být velkým napsáno upozornění, že lze použít v počítači jen s přehrávači XY a jinak je to podložka pod stůl?

Kde to žiju, že si člověk nemůže ani legálně vlastněný disk přehrát v legálně vlastněné mechanice.

[Robert Krátký]

To znamená že přehrání díla je takový úkon ve vztahu k dílu, ke kterému nemám oprávnění.

Přehrání díla způsobem, při kterém nejsou účinné ochrany proti kopírování, je takový úkon ve vztahu k dílu, ke kterému nemám oprávnění.

[JaRo]

A není to tak trochu jednostranný pohled? Pořád se tam mluví o ochraně autorských práv. A co ochrana spotřebitele?

1. Kupuji si dílo abych jej mohl přehrát. Ne jako podložku pod stůl. A autor to moc dobře ví, schrábne nemalé peníze a pak hází klacky pod nohy.

2. Jako kupující autorského díla si chci svou investici chránit. Třeba i tím, že si dílo zkopíruji a budu přehrávat kopii, zatím co originál bude uložen na bezpečném místě.

[Robert Krátký]

Já netvrdím, že je to tak správně - jen jsem poukázal na to, kde byla díra v tvé argumentaci, že je to nezákonné.

[JoHnY2]

Ja obvykle je neskutecnej problem vytvorit zakony o intelektualnim vlastnictvi a vlastnictvi neceho, co se da rozmnozovat za (temer) nulovy naklady. Pravo si dokaze velmi dobre poradit s hmotnym svetem, ale jak jde o virtualni svet a informace je problem na svete.

[VM]

Autentizace programu proti mechanice se autorské právo netýká, takže celá právní stránka je myslím jen o tom, nakolik je legální rozkódovat zakódovaný záznam něčím jiným, než co distributoři odsouhlasí. Tenhle problém tu ale byl už s DVD a CSS, a tam to snad dopadlo celkem dobře, tak uvidíme - hlavně aby ty hollywoodské obstrukce byly technicky pořádně překonány co nejdříve.

Na druhou stranu by bylo zajímavé zjistit, zda distributoři těmito prostředky nevytvářejí kartel (protože systém distribuce klíčů de facto vylučuje z trhu přehrávačů každého, kdo s nimi nemá dohodu), nebo zda neporušují nějaký jiný zákon o ochraně volného trhu a konkurence.

[corwin78]

Zákazník má právo pořídit si kopii, ale výrobce nemá povinnost to umožnit. Naopak překonání ochrany je trestné. Je to pakárna, ale je to tak.

[David Ježek]

v nějaké evropské zemi (už nevím kde), dospěl soud (nevím jaké instance) k tomu, že neúčinná ochrana není ochrana a tudíž její překonání není v rozporu se zákony (šlo o CSS na DVD-video)

[jioolk]

Podle tohoto http://www.cdr.cz/a/24932 je tou zemi Finsko, dospel k tomu soud prvni instance a aktualne neni rozhodnuti pravomocne neb jej Krajsky soud zrusil a soudi se dal.

[Semo]

Najprv sa musis dohodnut, co znamena slovo "pravo". Ja sa drzim vyroku (nie z mojej hlavy, ale paci sa mi): "Pravo nie je nieco, co mi niekto dava, ale nieco, co mi nikto nemoze upriet." V tomto pripade je velmi tazke sa bavit o prave na kopiu, ktoru mi distributor disku nie je povinny umoznit. Na co mi je take pravo vie urcite iba nejaky OSA podplateny bastard z parlamentu. Mam totiz zato, ze zakony su v CR (a SR) robene podla pravidla, ze co nie je zakazane je dovolene a teda explicitne zmienovat nieco, co niekto moze a nemusi spravit je uplne zbytocne. Inymi slovami zakony by nemali vymenuvavat moznosti, ktore je mozne spravit, ale iba povinosti, ktore je nutne splnit.

[VM]

Zákazník má právo pořídit si kopii, ale výrobce nemá povinnost to umožnit.

Zákon pouze stanoví, že kopie pro vlastní potřebu nezasahuje do autorského práva a jeho omezení, právo zde garantováno není (tedy krom principu, že co není zakázáno, je dovoleno).

Naopak překonání ochrany je trestné.

Trestné ne, pokud vím tak jen zakázané, a to autorským zákonem. Vzhledem k předchozímu bodu by mě ale zajímalo, zda z toho nejde odvodit, že na překonávání ochran pro vlastní potřebu se dané omezení nevstahuje...

[.]

no treba budete jediny, kdo "má doma sbírku stovek filmů a tisíců episod seriálů komprimovaných pomocí x264 a uložených v Matrošce", ja teda nemam zadny film ani tisice serialu, protoze je prubezne mazu. proc skladovat zbytecna data,ze???

[elenril]

U člověka, který píše o HD videu bych čekal, že bude umět rozlišit mezi H.264 (AKA MPEG-4 AVC/MPEG-4 Part 10/...), což je standard kódování videa, a x264, což je jeden z nejlepších a nejpopulárnějších enkoderů do H.264. Takhle tyhle bludy nikdy nevymizí.

[David Ježek]

V čem máš problém? jediná zmínka, na kterou můžeš poukazovat, je:

Ve Windows akcelerace x264 videa v .mkv kontejneru již delší dobu funguje...

a tam hovořím o konkrétní situaci, protože u takových filmů se v 99,9999% případů používá x264. Nehovořím tam obecně o formátu H.264, ale o konkrétním kompresním nástroji a konkrétním kontejneru.

[elenril]

Problém mám v tom, že nic takového, jako "x264 video" neexistuje. Přitom pro člověka neznalého problematiky z článku vyplyne, že ano. A to přispívá k opakování celého toho guláše s MPEG-4/DivX/XviD.

btw mnohem zajímavější, než tyhle akcelerace, kterých se možná ani nedočkáme, mi přijde GSoC projekt na frame-based multithreading ve FFmpegu. Do pár týdnů/měsíců by měl být začleněn a tím se prakticky řeší otázka přehrávání fullHD h.264 na vícejádrových CPU.

[xm]

Tak ono už teď multithreadované přehrávání H.264 videa v ffmpegu funguje, viz CABAC patch, který používá třeba XBMC. Pomáhá to hodně, ale pořád to ještě není uplně dokonalé. Frame-based multithreading by pravděpodobně poskytnul ještě o hodně vyšší výkon

[David Ježek]

Příloha:

• phenomX3_1080p_x2642.png (12787 bytů)

já jen dodám drobný postřeh z wokenic: phenom X3 @2,47ghz, 1080p x264/mkv video. nahoře má ffdshow povolený 3 jádra, dole jen jedno (je to vytížení celého systému).

[Mandarinka]

No, tenhle patch je takový hack ()vše co dokáže je pustit CABAC na druhém jádru, což však pomůže. Nicméně v nějakém devel stromě je už alpha skutečně univerzálního framového threadingu. Tak snad do roka a do dne...

[J. M.]

V čem máš problém? jediná zmínka, na kterou můžeš poukazovat, je:

Ve Windows akcelerace x264 videa v .mkv kontejneru již delší dobu funguje...

a tam hovořím o konkrétní situaci, protože u takových filmů se v 99,9999% případů používá x264. Nehovořím tam obecně o formátu H.264, ale o konkrétním kompresním nástroji a konkrétním kontejneru.

Je to stejný problém jako kdybys v článku o prohlížeči obrázků napsal, že umí zobrazovat „GIMP obrázky“, přičemž bys tím myslel JPEG obrázky vytvořené programem GIMP, s argumentací, že si je stejně většina linuxáků bude vytvářet v GIMPu. Stejně jako nejsou GIMP obrázky (zanedbejme nativní formát GIMPu, o kterém není řeč), není ani x264 video. x264 je jenom program (knihovna/program), který vytváří H.264 video.

[Kvakor]

Pamatuju, jak v dobe zacatku DVD take pocitace nezvladaly softwarove dekodovat MPEG2 a hw akcelerace (dokonce v podobe samostanych speializovanych karet) byla temer nutnost. Dnes DVD prehraje i ta nepomalejsi soucasny procesor a vetsina nema problem s prehravani DVD i bez jakekoliv asistence graficke karty (napr. v Linuxu pres VESA ci jiny tupy framebuffer), vcetne zvetseni a postrocessingu (a pokud ne, vetsinou postaci jen YUV overlay, coz umi dnes uplne vsechny grafiky).

Takze se domnivam, ze az bude HD video tam, kde je DVD dnes (resp. spis bylo pred par roky), tak bude mozne ho prehravat na budocich pocitaci i bez hw podpory dekodovani, protoze to budouci procesory vykonove utahnou.

[Luboš Doležel (Doli)]

Jakmile bude mít ffmpeg frame-level threading, tak to hned bude jiná sranda. Teď může mít člověk jader milión a je mu to na nic.

[Mandarinka]

Tak, přesně, s dobrým dekodérem to umí už dnešní procesory (dvoujádra). Tady je link na z části hotový patch do ffmpegu.