Archiv Novy - řešení v Pythonu přes rtmpdump

20.5.2009 15:47 | Přečteno: 8846× | poslední úprava: 30.5.2009 18:01

Inspirován blogpostem iVysílání ČT -- řešení přes wget a mplayer/mencoder jsem se rozhodl zveřejnit svůj skripty na archiv Novy.

Použití:

1. Najdi si na archiv.nova.cz pořad, kterej chceš stáhnout
2. Rozbal přiloženej tarball a spusť skript nova-dl.py v něm:

   ./nova-dl.py http://archiv.nova.cz/multimedia/televizni-noviny-19-5-2009.html

3. Skript standardně uloží video ve "vysoké" kvalitě do souboru název-pořádu.flv, v našem případě tedy 009-05-19_TN_tn.flv

Volby:

  -q QUALITY, --quality=QUALITY
                        Vybere kvalitu (low/high)
  -o OUTPUT, --output=OUTPUT
                        Nastaví cílový soubor

UPDATE 30.5.: vývoj pokračuje na GitHubu

       

Komentáře

[Limoto]

Příloha:

• nova-dl.tar.gz (510122 bytů)

V příloze skript s přiloženým rtmpdump 1.6 (statická x86 32b binárka).

[Grunt]

s přiloženým rtmpdump 1.6 (statická x86 32b binárka).

A to jako proč?

[Limoto]

A to jako proč ne? Nikomu to nenutím...

[Darth Phantom]

Jako pěkný skriptík ale... nějak bych nevěděl na co ho použít. Archiv TV H@vna mě ničím neláká. Televizní noviny, nejhorší to bulvární zpravodajství, nesleduji. Esmeraldu taky nechci vidět. Kriminálka Las Vegas, kriminálka Miami, New York, Washington, Los Angeles a Námořní vyšetřovací služba mě taky nějak neoslovuje

[Limoto]

 

Kriminálka Las Vegas, kriminálka Miami, New York, Washington, Los Angeles a Námořní vyšetřovací služba

Ani jedno z nich tam nenajdeš, je tam jenom jejich tvorba. Takže maximálně Kriminálka Anděl

[kotyz]

Je tam Comeback?

[Limoto]

Zkus na tu stránku jít a kliknout na "seznam pořadů"...

[kotyz]

Ja se ptam abych si usetril praci ...

[alblaho]

Comeback tam je. Je to snad jediná věc, která na Nově stojí za to. Zvláště muzikál Hácha od Michala Davida v posledním díle mě dostal.

[kotyz]

Jo to byl masakr

[Darth Phantom]

Comeback tam je. Je to snad jediná věc, která na Nově stojí za to

Jednou jsem to viděl a jsou tam pasáže, kterým jde i zasmát. Poněkud trapná je ale inspirace americkými sitkomy a to pouštění smíchu. Příběhu, kdy tam nějaká ta hlavní umělkyně točila údajně v mládí pornofilmy s názvem "Třicet přírazů majora Zemana" atd. jsem se docela i zasmál :))

[^([0-9a-fA-F]{2}([:-]?|$)){6}$]

Vždycky mě dostává, když nějaký strojený intelektuál se takhle hrdě distancuje od Novy.

[neaktivni]

+100))

[Grunt]

Jako pěkný skriptík ale... nějak bych nevěděl na co ho použít.

Co to je za otázku? To je přece jasné. Na Ulici a Růžovku.

[Grunt]

Jasně, ale připomíná mi to také to Windowsácké řešení typu hlavně ať to funguje.

[J. M.]

Na takovém řešení není nic špatného, obzvlášť když funguje jako záložní varianta. Tohle prostě bude fungovat skoro všem (snad i uživatelům BSD, kterým by ta statická linuxová binárka měla bez problémů běžet), a kdo chce, může si to přece klidně nahradit vlatním, dynamicky linkovaným rtmdump. Nevím, v čem je problém.

[Grunt]

Jo, ale to jen do chvíle než člověk instaluje a konfiguruje už podesáté aplikaci, která si nese svoji verzi knihovny GTK(za GTK si samozřejmě dosaďte dle libovůle cokoliv jiného). Prostě se mi to nelíbí. Když už, tak aspoň distribuovat se zdrojáky, ale úplně nejlépe samozřejmě vypsat závislost.

[M. Lox]

Když už, tak aspoň distribuovat se zdrojáky

To podle licence stejně musí. rtmpdump je GPL.

[joe]

Tak přesně toto nemusí ;)

[Grunt]

 Na vyžádání ano.

[Ilfirin]

Ne

[Grunt]

Toto neplatí?:

6. Conveying Non-Source Forms.

  You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:

    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.

    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.

    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.

    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.

    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.

IMHO min. jeden z těch bodů musí dodržet a jelikož neposkytl do teď nic, tak předpokládám, že asi bude dodávat zdrojový kód či místo ze kterého ho můžu získat až na vyžádání.

[Andrej Herceg]

... či místo ze kterého ho můžu získat až na vyžádání

To môže byť dosť problematické (ak teda nebude stačiť odkaz na nejaký torrent tracker) pretože rtmpdump môže byť použitý na sťahovanie chráneného obsahu a preto také miesto asi momentálne neexistuje.

[Grunt]

LOL, tak to jsem vůbec netušil. To abych smazal z počítače wget, všechny webové prohlížeče, libcurl, libsoap, pidgina, libpurple, telnet, celý síťový stack…a neměl bych čirou náhodou vyhodit z okna celý počítač když už jsme u toho? Co to zas je za hnus zelený?

[Jendа]

Co to zas je za hnus zelený?

Takže ještě jednou a pomalu. D M C A. dý em sí ej. DMCA.

Myslíte, že bych mohl vývojářům nabídnou pár set mega prostoru na serveru v ČR? Vtrhne do serverovny policie a zabaví celý rack?

rtmpdump has been replaced with a forked version called flvstreamer. flvstreamer is basically rtmpdump without rtmpe support. rtmpdump will still work as before for for backwards compatibility reasons. Please ensure you upgrade to get_iplayer v1.87 or above.

(zdroj) To jako kvůli tomu?

[Grunt]

Takže ještě jednou a pomalu. D M C A. dý em sí ej. DMCA.

Proč tu ještě nikde nevidím správně otagovanou zprávičku? [1],[2]

Myslíte, že bych mohl vývojářům nabídnou pár set mega prostoru na serveru v ČR? Vtrhne do serverovny policie a zabaví celý rack?

Těžko říct. Je to projekt na SourceForge. To by se ho SourceForge a mám pocit, že i autor(pokud není z U.S., tak se omlouvám) museli zříct. Jinak je to docela jedno. Samotná utilita rtmpdump je jen vypreparovaná z knihoven v XBMC a to je zase inspirované téměř stejnojmennou utilitou z gnashe(utilities/rtmpget.cpp). A v Gnashi už je to delší dobu a zatím to nikomu nevadilo. Akorát jsem si teda do teď myslel, že Adobe už dávno uvolnilo specifikace, když to tak honosně ohlašovali a oni místo toho zatím jen prudí.

[Jendа]

Proč tu ještě nikde nevidím správně otagovanou zprávičku? [1],[2]

A jo, ono to proběhlo teprve tento týden? Mě nenapadlo podívat se na datum a myslel jsem si, jak je to dávno...

Těžko říct. Je to projekt na SourceForge. To by se ho SourceForge a mám pocit, že i autor(pokud není z U.S., tak se omlouvám) museli zříct.

Google na 1. místo na dotaz rtmpdump vrací stránku sourceforge.net/projects/rtmpdump/, na které je napsáno "Invalid Project". Tak že by se ho už na SF zřekli?

[Grunt]

A jo, ono to proběhlo teprve tento týden? Mě nenapadlo podívat se na datum a myslel jsem si, jak je to dávno...

Samotný rtmpdumper vznikl začátkem tohoto měsíce. A v době psaní tohoto blogu byl ještě zdroják tam kde má být. Je to tři dny staré.

Google na 1. místo na dotaz rtmpdump vrací stránku sourceforge.net/projects/rtmpdump/, na které je napsáno "Invalid Project". Tak že by se ho už na SF zřekli?

Jen ho přesunuli/forknuli na neutrální půdu. Zdrojáky mám pro jistotu ještě v počítači.

[Jendа]

and 2) identify the person or persons responsible for posting the infringing material. If you are unwilling or unable to provide this information for privacy or other reasons, we will issue a subpoena seeking the same.

Ještě že tam nežiju. A autor blogpostu taky ne, mohl by být stíhán. Pokud je autor dumperu z USA, tak se má na co těšit, pokud ne, tak by tam neměl už nikdy jezdit - dopadl by jako Skljarov...

[Grunt]

Snad nějaký (nebo snad i tento) Rus. Těžko říct. Jako by se po něm slehla zem.

BTW: Podobné je to s patenty. Nemusíš být zrovna Rus aby na tebe měly odezvu.

[Jendа]

Těžko říct. Jako by se po něm slehla zem.

Po mě by se asi v této situaci taky slehla zem

BTW: Podobné je to s patenty. Nemusíš být zrovna Rus aby na tebe měly odezvu.

? Tady snad SW patenty neplatí, takže co mi můžou z USA udělat? Už jsi něco naznačoval, nechceš to rozvést?

[Limoto]

Tak teď už snad nikdo nepochybuje o tom, že je tam ta binárka... Ale nestačím hledět, co se to děje... zdrojáky naštěstí taky mám

[Jendа]

http://www.abclinuxu.cz/zpravicky/show/266216

[Grunt]

rtmpdump has been replaced with a forked version called flvstreamer. flvstreamer is basically rtmpdump without rtmpe support. rtmpdump will still work as before for for backwards compatibility reasons. Please ensure you upgrade to get_iplayer v1.87 or above.

Pár dnů zpět jsem se díval do bugzilly rtmpdumperu a zrovna tam kdosi ohlašoval, že použije rtmpdumper do svého projektu, který už uměl stahovat videa z YouTube a podobných video portálů. Něco s flv. Jestli to nebyl ten flvstreamer.

[joe]

Jako aplikace, která používá tu systémovou a pro případ, že ta nebude k dispozici, tak s sebou nese vlastní? (Ne, pitomost jsem nenapsal já, ale opravdu Ty)

[Grunt]

 Jasně, proti tomu nic nemám, ale binárka mi vadí.

[J. M.]

Díky moc! Už dlouho jsem se chtěl na některé věci z jejich archivu podívat nebo je stáhnout, ale můj počítač ten jejich Flash dává jenom jako slideshow a stáhnout se mi to nikdy žádným nástrojem nepodařilo... S tím tvým už to sviští, na první pokus.

[Grunt]

Ten rtmpdump je vykuchaný z projektu XBMC a ten je zase inspirovaný (zatím) nefunkčním rtmpdumpem z Gnashe. A právě projekt Gnash je iniciátorem implementace RTMP. Když jsem to zkoušel někdy na přelomu roku, tak se mi zobrazilo s SVN verzí Gnashe jen bílo místo filmu, ale je dost možné, že už se to hnulo a nebo to lze k funkčnímu stavu dokopat. On se totiž dá vybrat jako přehrávací backend ffmpeg nebo gstreamer a ten žere jen zlomek toho co originální Flash.

[J. M.]

Já Gnash používám na FreeBSD a i když to sice konečně částečně funguje (což je pokrok, dřív to nefungovalo vůbec), jednak třeba archiv Novy a Primy v tom nefunguje, jednak mě šokovalo, že to je ještě daleko pomalejší než Flash. Předpokládal jsem, že když to používá FFmpeg a když to, na rozdíl od Flashe, bude mít funkční hardwarovou akceleraci videa, že to nebude tak nehorázně žravé jako linuxový Adobe Flash. A přitom i nekvalitní pidivideo z YouTube v tom vytíží procesor na 100 procent.

[Grunt]

Samozřejmě jsem myslel verzi z nějako SVN(nebo bazaaru nebo co to tam mají) a ne sto let starý bazmek z repositáře.

jednak mě šokovalo, že to je ještě daleko pomalejší než Flash. Předpokládal jsem, že když to používá FFmpeg a když to, na rozdíl od Flashe, bude mít funkční hardwarovou akceleraci videa, že to nebude tak nehorázně žravé jako linuxový Adobe Flash. A přitom i nekvalitní pidivideo z YouTube v tom vytíží procesor na 100 procent.

Tam je problém s nějakou knihovnou co ten stream stahuje. Moc to nechápu, protože zapnu wget a ten nežere nic, ale prej se to prioritně řeší.

hardwarovou akceleraci videa

VP6 má HW akceleraci na nějaké kartě?

[J. M.]

Ne, myslel jsem obyčejné XVideo. To totiž ve Flashi nefunguje, i když by papírově mělo. Adobe to myslím vysvětlila tím, že ten jejich video přehrávač musí používat RGB, kdežto v overlayi se klasicky akcelerují formáty YUV.

No tak časem zkusím novější Gnash... Stejně ale mám takové podezření. že víc výkonu než veškeré dekódování a stahování v tom prostě sežere to vykreslování těch posuvníků a tlačítek v tom přehrávači. (MPlayer ta běžná videa z YouTube přehraje s asi 5procentním vytížením procesoru.)

[Grunt]

Ne, myslel jsem obyčejné XVideo.

Tak to ale není akcelerace v pravém slova smyslu.

To totiž ve Flashi nefunguje, i když by papírově mělo.

Tak to jsem ani netušil. Stejně bych byl radši kdyby streamy dekódovali k tomu určené(a hlavně rychlé) knihovny, než bůh ví jaký bazmek.

Adobe to myslím vysvětlila tím, že ten jejich video přehrávač musí používat RGB, kdežto v overlayi se klasicky akcelerují formáty YUV.

Téměř všechna jejich videa jsou v YUV420 a navíc moje X let stará GF5200:

screen #0
  Adaptor #0: "NV17 Video Texture"
    number of ports: 32
    port base: 325
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
…
number of planes: 3
        type: YUV (planar)
      id: 0x3
        guid: 03000000-0000-0010-8000-00aa00389b71
        bits per pixel: 32
        number of planes: 1
        type: RGB (packed)
        depth: 24
        red, green, blue masks: 0xff0000, 0xff00, 0xff

[J. M.]

„Tak to ale není akcelerace v pravém slova smyslu.“

Samozřejmě, že je. To, že si dnešní mládež myslí, že grafická akcelerace znamená, že grafická karta dekóduje H.264, neznamená, že graficky se nedají akcelerovat jiné věci. Grafické karty např. akcelerují vykreslování 2D grafiky na desktopu (na to jsou různá rozšíření v X serveru, i když „fungují“ paradoxně tak, že jsou pomalejší než softwarové vykreslování) a stejně tak umí akcelerovat konverzi barevných modelů a škálování videa, což jsou dvě hlavní věci, které XVideo zařizuje (taky synchronizaci, aby se video „netrhalo ve švech“). To je velmi významné odlehčení procesoru (video ve fullscreenu se přehrává s úplně stejnou zátěží procesoru jako video v malém okýnku) a je to grafická akcelerace v pravém slova smyslu. Zrovna u toho linuxového Flashe je to krásně vidět. V malém okýnku ještě video jakž takž přehraje, ale jak se přepne do fullscreenu, tak skoro ani nemůžu pohnout s myší, jak to zahltí procesor.

„Téměř všechna jejich videa jsou v YUV420 a navíc moje X let stará GF5200:“

I moje karty píšou totéž, ale jak říkám, prostě to nefunguje.

[J. M.]

(To „grafická akcelerace v pravém smyslu“ jednuduše znamená, že grafická karta ty grafické operace počítá/provádí místo procesoru. A zrovna přepočítávání obrazu do fullscreenu je dost náročná operace, když se provádí 25krát za sekundu.)

[J. M.]

Jinak ještě k tomu „Téměř všechna jejich videa jsou v YUV420“: to nebylo o tom, v čem jsou videa, ale o tom, co používá flashový přehrávač. V tom je ten problém. Ten flashový přehrávač např. potřebuje do toho videa vykreslovat všechny možné interaktivní prvky, což je normální RGB grafika...

[Grunt]

No já nevim. Stačí vyžádat plochu přesně o velikosti videa a ovládací prvky vykreslovat samostatně.

[J. M.]

Těmi interaktivními prvky jsem myslel všechno to, co flashový přehrávač vykresluje přímo do plochy videa. Např. ty bublinkové titulky na YouTube nebo ty animované seznamy/náhledy videí a podobné nesmysly. Flashový přehrávač prostě (bohužel) není jenom přehrávání videa v okýnku. Kdyby to nevykresloval přímo do videa, musel by to nějak vykreslovat nad to, v další vrstvě. A to tedy nevím, jestli to tak dělá. Spíš bych řekl, že prostě video (softwarově) převede na RGB a do té plochy to pak všechno společně vykresluje. Ale to nevím, to jenom tipuju.

[Grunt]

Těmi interaktivními prvky jsem myslel všechno to, co flashový přehrávač vykresluje přímo do plochy videa. Např. ty bublinkové titulky na YouTube nebo ty animované seznamy/náhledy videí a podobné nesmysly.

No tak ty by mi vůbec nechyběly.

Flashový přehrávač prostě (bohužel) není jenom přehrávání videa v okýnku.

Bohužel. Kéž by chtěli už na YouTube použít video tag.

Kdyby to nevykresloval přímo do videa, musel by to nějak vykreslovat nad to, v další vrstvě. A to tedy nevím, jestli to tak dělá.

Momentálně určitě ne. Ale není to špatný nápad. Alfa kanál je plně podporován.

[J. M.]

„No tak ty by mi vůbec nechyběly.„

Není pro tyto případy (kdy člověku stačí jenom to samotné video) nějaký plugin, založený na MPlayeru? Který jenom přehraje to FlashVideo? To musí být mnohonásobně efektivnější a rychlejší než Flash nebo Gnash.

Prostě flashový přehrávač není určený k přehrávání videa, je to po technické stránce zrůdnost, kterou bohužel mnozí nadšeně obhajují...

„Bohužel. Kéž by chtěli už na YouTube použít video tag“

Obávám se, že dokud to nezačne podporovat Microsoft (a ten začne leda až v největší nouzi, když už nebude jiného zbytí, protože nepodpora tagu video je jeho konkurenční zbraní k protlačení Silverlightu), tak nasazení na takovýchto masových serverech nepřichází v úvahu.

[Grunt]

Není pro tyto případy (kdy člověku stačí jenom to samotné video) nějaký plugin, založený na MPlayeru? Který jenom přehraje to FlashVideo? To musí být mnohonásobně efektivnější a rychlejší než Flash nebo Gnash.

Ano, ale ten bohužel nejede na Epiphany.

[David Jaša]

Ten flashový přehrávač např. potřebuje do toho videa vykreslovat všechny možné interaktivní prvky, což je normální RGB grafika...

Přesně tak. Hezky to shrnuje swfdecí FAQ:

What do I have to do to make video playback in Swfdec as fast as with mplayer?

The short answer: It's hard. Here's the problem: As you might know, hardware has a dedicated method to display video, called the video overlay. That is what xv and in turn mplayer and ffmpeg use. It has the following features: * reserve a rectangular region on the screen for video display * move a memory rectangular image of YUV video data to that region and scale it to fit. That's not a lot and works well enough for video, but not for Flash. Flash allows rendering stuff on top of the video (the end screen on Youtube for example has the last video image shine through) and it allows translucent videos and drawing non-rectangular parts of videos. All of this is not supported by xv, which is why we decided to not go through the pain to use it. The unfortunate side effect is that currently a lot more horsepower is required to display a video via Swfdec.

The end goal is to use OpenGL and its video extensions to speed up Flash video. That should make it as fast as xv for graphic cards that provide these features (almost all current graphic cards do). But then, there is currently no OpenGL cairo backend, even though there's constantly talk about doing one.

[J. M.]

Díky. Co se týče toho Caira na OpenGL, na tom se snad pracuje...

[J. M.]

Ještě mě tak napadlo: co takhle dodat do swfdec a/nebo Gnashe volbu „zobrazovat video přes XVideo, zahodit dodatečnou grafiku“? Každý, kdo by chtěl přehrávat video efektivně, s nižší zátěží procesoru a obešel by se bez těch serepetiček v tom videu (které jsou prakticky vždycky postradatelné a většinou úplně k ničemu), by měl tu možnost, tedy zobrazovat jenom tu video složku. Sice by už pak ten přehrávač nezobrazoval všechno, co má zobrazovat, ale u svobodného softwaru je myslím taková svobodná volba v pořádku.

[David Jaša]

Ještě mě tak napadlo: co takhle dodat do swfdec a/nebo Gnashe volbu „zobrazovat video přes XVideo, zahodit dodatečnou grafiku“?

Napíšeš feature requesty?

[Kvakor]

Zjednodušeně řečeno, za akceleraci videa se dá považovat cokoliv, co vůči přehrávači (resp. operačnímu systému) poskytuje cokoliv nad rámec hloupého framebufferu v nativním prixelovém formátu (dnes skoro vždy 24/32bit RGB).

A RGB/YUV konvertor a scaller měly už S3 Trio a ATI Mach64 v r. 1995

[Grunt]

A RGB/YUV konvertor a scaller měly už S3 Trio a ATI Mach64 v r. 1995

Scpecifikace X Video Extension ver. 2 je z roku 1991. Vsadím se dřívější verze jsou ještě starší než já. Největší krása je v tom, že i Xv protokol samotný už pěkně dlouho podporuje kopírování video streamů do HW a hodně dalších pěkných funkcí(nevěděl by někdo o nějak HW co podporuje třeba XvPutVideo?), ale to ne. Každá firma si musí vymyslet svůj polofunkční bazmek aby se mohla vykazovat činnost a pak se to ještě celé musí sjednocovat a odstiňovat další vrstvou. To se pak Windowsáci můžou divit.

BTW: Když jsem hledal specifikaci Xv verze 1.3(ta je snad ještě někde na papíře) tak jsem na něco narazil…no co to zas ku…?:

V reakci na stížnost, kterou jsme obdrželi v souladu s Digital Millennium Copyright Act, jsme z této stránky odstranili 1 výsledek. Pokud chcete, můžete si přečíst DMCA stížnost k těmto odstraněným výsledkům.

[Grunt]

A po dlouhém prohrabování historií se mi podařilo najít i tu stížnost.

[Grunt]

Může mi to prosím někdo přeložit do lidské řeči?

[Andrej Herceg]

Tá sťažnosť už nie je na tej stránke dostupná (vlastne tam pravdepodobne ani nikdy nebola), ale podľa toho, čo som niekde čítal, by malo ísť o nejaké torrenty.

[Andrej Herceg]

Inak takých odkazov na neexistujúcu sťažnosť od Twentieth Century Fox sa dá nájsť dosť veľa. (napr. "torrent x-men origins")

[Grunt]

Samozřejmě, že je. To, že si dnešní mládež myslí, že grafická akcelerace znamená, že grafická karta dekóduje H.264, neznamená, že graficky se nedají akcelerovat jiné věci.

Pokud čtete moje komentáře, tak určitě víte, že jsem zastáncem i prostého Xv. Jen nemám rád když se používá slovo akcelerace, protože většina lidí si pod tím představí něco jiného a popravdě řečeno jsem docela překvapen a potěšen, že konečně někdo aneb nemusí hned pršet, stačí když kape…

Grafické karty např. akcelerují vykreslování 2D grafiky na desktopu (na to jsou různá rozšíření v X serveru, i když „fungují“ paradoxně tak, že jsou pomalejší než softwarové vykreslování)

Nevím jak jinde, ale na nVidii XRender jede dobře a rozdíl je znát.

To je velmi významné odlehčení procesoru (video ve fullscreenu se přehrává s úplně stejnou zátěží procesoru jako video v malém okýnku) a je to grafická akcelerace v pravém slova smyslu.

Sám si rád přehrávám ve framebufferu, takže vím, že to není taková hrůza. U dnešních Super HD-Vision o 40Mbps a nebo naopak 320x240 YouTube…ale budiž.

I moje karty píšou totéž, ale jak říkám, prostě to nefunguje.

Aha. Opravdu to nefunguje. Má to nějaké divé ID a ještě je to pod Adaptor #1: "NV05 Video Blitter"

[J. M.]

„Jen nemám rád když se používá slovo akcelerace, protože většina lidí si pod tím představí něco jiného“

To, že většina lidí si něco mylně představuje, pro mě není důvod nepoužívat správný termín.

„Nevím jak jinde, ale na nVidii XRender jede dobře a rozdíl je znát.„

Já jsem se trápil s NVIDIÍ, teď se trápím s ATI, a můžu říct, že ta úžasná 2D akcelerace v Linuxu není znát oproti neakcelerovanému generickému VESA ovladači absolutně vůbec nijak. Tedy samozřejmě kromě podpory XVidea a nějakého 3D, které nepořebuju. Grafika v Linuxu je úděsně pomalá.

Jinak problém EXA, která je dnes běžně používána pro 2D akceleraci, včetně rozšíření RENDER, je to, že když není dost video paměti (což se při dnešních rozlišeních a graficky náročných desktopech stává často), musí se data neustále přesouvat z video paměti do virtuální paměti, což je velmi pomalé. Pak je skutečně akcelerovaná 2D grafika daleko pomalejší než neakcelerovaná. Což ukazují mnohé benchmarky. Problém se týkal třeba ovladačů Intel, proto taky vzniklo UXA, které by mělo problémy EXA řešit... Ale např. ty ovladače Intel s novým UXA jsou zatím ještě daleko pomalejší než byly staré s EXA.

[Josef Kufner]

Ale např. ty ovladače Intel s novým UXA jsou zatím ještě daleko pomalejší než byly staré s EXA.

V experiental větvi Debianu se před nedávnem objevil balíček xserver-xorg-video-intel verze 2:2.7.99.1-1 a s tím už to jede krásně rychle, 3D je rychlejší než předtím (jak EXA tak XAA) a 2D jsem nějak nepostřehnul, takže to funguje v pohodě. A ani to moc nepadá

[Deleted [8409]]

Přiznejme si, že flash není zase tak pomalý Ono autoři gnashe o tom moc dobře ví, a nevím, jestli jsou schopni s rychlostí něco udělat. Dá se přímo na stránkách gnashe najít benchmark všech backendů, a je to hrůza. Třeba animované věci jako Happy Tree Friends, kde se výkon opravdu pozná, gnash absolutně nezvládne pomocí SW akcelerace (slideshow) a pomocí HW akcelerace není kvalita moc dobrá (méně kvalitní antialiasing).

Aby se to zlepšilo, museli by udělat zcela nový grafický engine (s jiným přístupem), a to asi z časového hlediska není možné. On ten flash má totiž fakt vymakaný SW backend.

[Beetljuice]

Nevim jestli něco nedělám špatně,ale video se sice stáhne ikdyž (.... Download failed...) a přehrát mi taky nejde (vlc,mplayer) prý "Unsupported video,audio codec". Podotýkám, že jiné uložené flv soubory (YouTube) mi vlc přehraje normálně.

[Beetljuice]

Aha,tak v práci na Suse 11.1 (doma Kubuntu 8.04) to jde normálně ... patrně tedy chyba na mém přijímači

[Honza Balák]

Na mém Ubuntu 8.04 taky nic (mplayer, vlc), na Ubuntu 9.04 jede vlc (mplayer nikoliv). Přitom s flv ze Stream.cz problém nemám...

[Limoto]

Pokud ti nevadí horší kvalita, zkus parametr -q low, je tam jinej kodek...

"Vysoká kvalita":

General                                                                                 
Complete name                    : 2009-05-21_Ordinace-II-113-dil-Cerna-nocx_tn.flv     
Format                           : Flash Video                                          
File size                        : 418 MiB                                              
Duration                         : 57mn 20s                                             
Overall bit rate                 : 1 018 Kbps                                           
_code                            : NetStream.Data.Start / NetStream.Play.Complete       
_level                           : status                                               
_duration                        : 2207.000                                             
_bytes                           : 437957248.000                                        

Video
Format                           : AVC
Format/Info                      : Advanced Video Codec
Format profile                   : High@L3.0         
Format settings, CABAC           : Yes               
Format settings, ReFrames        : 3 frames          
Muxing mode                      : Container profile=Unknown@3.0
Duration                         : 57mn 20s                   
Width                            : 720 pixels                 
Height                           : 400 pixels                 
Display aspect ratio             : 16/9                       
Frame rate mode                  : Variable                   
Frame rate                       : 25.000 fps
Resolution                       : 24 bits
Colorimetry                      : 4:2:0
Scan type                        : Progressive

Audio
Format                           : AAC
Format/Info                      : Advanced Audio Codec
Format version                   : Version 4
Format profile                   : LC
Format settings, SBR             : No
Duration                         : 57mn 20s
Channel(s)                       : 2 channels
Channel positions                : L R
Sampling rate                    : 32.0 KHz
Resolution                       : 16 bits

Nízká kvalita:

General                                                    
Complete name                    : 2009-05-21_TN2.flv      
Format                           : Flash Video             
File size                        : 81.2 MiB                
Duration                         : 19mn 0s                 
Overall bit rate                 : 597 Kbps                
_code                            : NetStream.Data.Start / NetStream.Play.Complete
_level                           : status                                       
_duration                        : 111.000                                      
_bytes                           : 85108344.000                                 

Video
Format                           : VP6
Duration                         : 19mn 0s
Bit rate                         : 500 Kbps
Width                            : 720 pixels
Height                           : 400 pixels
Display aspect ratio             : 16/9
Frame rate                       : 25.000 fps
Bits/(Pixel*Frame)               : 0.069
Stream size                      : 68.0 MiB (84%)

Audio
Format                           : MPEG Audio
Format version                   : Version 2
Format profile                   : Layer 3
Duration                         : 19mn 0s
Bit rate mode                    : Constant
Bit rate                         : 64.0 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 22.05 KHz
Resolution                       : 16 bits
Stream size                      : 8.70 MiB (11%)

PS: nesnáším FCK!

[Beetljuice]

OK, low kvalita jde. On je totiž vůbec nějaký problém s AAC a s AVC kodekem v Ubuntu.

[Zbynek]

V Ubuntu 8.04 není problém s dekodéry, ale s podporou kontejneru FLV (při použití h.264 a AAC) v jedné z knihoven FFmpeg.

Mplayer při přehrání videa vypíše:

[flv @ 0x87516d4]Unsupported video codec (7) Cannot find codec for audio format 0xA.

VLC při přehrání videa vypíše:

VLC nepodporuje tento audio/video formát "undf". Bohužel není žádná šance, že byste to opravil.

Totem-gstreamer při přehrání videa vypíše:

Internal data stream error.

V Ubuntu 9.10, možná i starším, se tento problém nevyskytuje. Problém lze taktéž vyřešit zkompilováním nové verze FFmpeg.

[kotyz]

Stary epizody Comebacku mi to odmita stahnout:

[kotyz@behemot nova-dl]$ ./nova-dl.py http://archiv.nova.cz/multimedia/comeback-1-dil-kreslo-2.html
Traceback (most recent call last):
  File "./nova-dl.py", line 85, in module
    main()
  File "./nova-dl.py", line 18, in main
    url, type = get_server(serverlist, server_id)
TypeError: 'NoneType' object is not iterable

[Honza Balák]

Nevím, jestli je to náhoda, ale nejdou stáhnout epizody 1..9, 10.. stáhnout jdou.

[Vojtěch Horký]

Starší pořady jsou asi uloženy jinak, protože třeba Kriminálka Anděl nejde stáhnout žádná.

[Limoto]

V gitu už je to opravený. Funguje Comeback i Kriminálka Anděl...

[Honza Balák]

Tak to je bomba! Díky moc. Zkoušel jsem ty starší epizody stáhnout ve Win pomocí Replay Media Catcheru 3, ale bylo to o několik % zrychlené.

[Kestrel]

FUNGUJE SUPER !!! Dik a z tech kecu si nic nedelej . Jednomu ryzimu Linuxovymu amaterovi jsi udelal radost

[dustin]

Využívá se na nově ten RTMPE, který je z forknutého rtmpdumpu odstraněn?

[Grunt]

Zatím funguje jak přes čisté RTMP, tak přes RTMPE. Ještě jednou dodávám:zatím.

[dustin]

Díky za info

[xm]

Pokud chcete zdrojové kódy původního programu rtmpdump (ne jen forku flvstreamer, který je zbaběle okleštěn o podporu RTMPE), pak jsou ke stažení zde:

http://lkcl.net/rtmp

Přikládám i přímý odkaz na tarball:

http://lkcl.net/rtmp/rtmpdump-v1.6.tar.gz

[LuděkS]

Zdravím, tak jsem si řekl, že to také vyzkouším, ale:

ERROR: Connect, handshake failed.
Failed to connect!
Download completed without errors

Tak nevím, kde je chyba

[Ondřej Kuda]

Nova zmenila web a skript uz nefunguje.

[dustin]

Příloha:

• launchy.xml (263 bytů)

Stačí na řádku 65 odstranit uvozovky v hledaném řetězci a překvapivě to funguje dál.

site_id = re.search(r'var site_id = (\d+);', videopage).group(1)

Dovoluji si připojit svůj skript nova-player.sh na přehrávání v mplayeru:

#! /bin/bash

URL="$@"

OUTPUT_FILE="/tmp/nova-archiv.flv"
PATH="$PATH:/home/pavel/bin"

rm $OUTPUT_FILE

/home/pavel/bin/nova-dl.py -o $OUTPUT_FILE "$URL" > /tmp/nova.log 2>&1  &
sleep 1s
PID=$(pidof rtmpdump)
echo $PID > /tmp/pid
while [ ! -f $OUTPUT_FILE ]; do sleep 1s; done
sleep 2s

mplayer -geometry +1024+0 -forceidx -fs -ao alsa $OUTPUT_FILE > /tmp/mplayer.log 2>&1
kill $PID

Skript se spouští přes launchy s konfigurací přiloženou k příspěvku.

[J.-T.S.]

S úplně stejným systémem (Mandriva Linux 2010) přesně tímtéž rtmpdump a nova-dl.py http://github.com/Limoto/nova-dl mi to bez problému stahuje - ovšem pouze na starším IBM notebooku manželky! Všude jinde to píše následující (viz dole) . Jak je to možné ?!!! Je to věc HW + SW nebo připojení - manželčin běží přes wifi, ostatní přes ethernet nebo kombinace všeho nebo jen zcela nevysvětlitelná záhada ???? !!! Nemáte někdo uspokojivou teorii? Doufám, že to nesleduje webmaster Novy a "neposvítí si teď na všechny notebooky IBM" ... :)

[deti@localhost NOVA]$ python nova-dl.py http://archiv.nova.cz/multimedia/televizni-noviny-27-5-2010.html RTMPDump v1.6 (c) 2009 Andrej Stepanchuk, license: GPL

DEBUG: Parsing... DEBUG: Parsed protocol: 0 DEBUG: Parsed host : flash2.nova.nacevi.cz DEBUG: Parsed port : 80 DEBUG: Parsed app : vod ERROR: No playpath found! WARNING: No playpath in URL! DEBUG: Setting buffer time to: 36000000ms Connecting ... DEBUG: Protocol : RTMP DEBUG: Hostname : flash2.nova.nacevi.cz DEBUG: Port : 80 DEBUG: Playpath : mp4:nova/2010/05/2010-05-27_Televizni-noviny_tn DEBUG: tcUrl : rtmp://flash2.nova.nacevi.cz:80/vod DEBUG: swfUrl : http://archiv.nova.cz/static/cz/shared/app/MediaCenter_Catchup.swf DEBUG: pageUrl : http://archiv.nova.cz/multimedia/televizni-noviny-27-5-2010.html DEBUG: app : vod DEBUG: flashVer : LNX 9,0,124,0 DEBUG: live : no DEBUG: timeout : 300 sec DEBUG: Connect, ... connected, handshaking DEBUG: HandShake: Client type: 03

DEBUG: HandShake: Client digest offset: 533 DEBUG: HandShake: Initial client digest: 50 8C 01 B9 1F 9D B6 65 23 73 17 AA 06 94 DF 19 35 5C 31 4E 3F E2 8D E5 EE 58 F9 D1 30 95 07 BC DEBUG: ReadN, RTMP socket closed by server ERROR: Connect, handshake failed. Failed to connect! Download failed [deti@localhost NOVA]$

[JTS]

Víte někdo odpověď ?