Dotaz: Jak zmenšit datový tok u DVB-T streamu?

[Hrabosh]

Zdravím.

Používám GETSTREAM na streamování DVB-T do lokální sítě. Getstream posílá do sítě data tak, jak je chytí z DVB-T karty, takže to vyžaduje docela velký datový tok (ale zase velmi málo zatěžuje processor).

Třeba VPNka, natažená přes WiFi, už nemá dostatečnou průchodnost na to, aby se na ten stream dalo dívat. Když se na ten server připojím venkem (VPN), tak už to taky nejde.

V podstatě se můžu dívat jen z vnitřní. metalické sítě.

Poradíte někdo, jak omezit datový tok? (za cenu snížení kvality) Jinak ten streamovací server je PII@350MHz, takže žádná sláva.

Díky, Zb.

Odpovědi

[Jendа]

Na PII asi žádnou realtime rekompresi neuděláš... Možná do MPEG-1, ale pochybuji.

[Hrabosh]

A nestacilo by treba zahazovat frejmy? Nebo zmensit velikost obrazu?

[VSi]

A nestacilo by treba zahazovat frejmy?

Podle mě úplná blbost. Nedalo by se na to koukat.

Nebo zmensit velikost obrazu?

To by šlo, ale po zmenšení to ten stroj musí zase do nějakého formátu zakódovat. Zkusil bych zmenšení tak na 400×300 px a kompresi do MPEG-2, mohlo by stačit tak 1.5 Mbit/s. PII 350 je ale stejně dost málo, moc šancí bych tomu nedával.

[Hrabosh]

Fajn, zkusil bych to. Ale jak? Umí třeba mencoder chytit stream, zmenšit obraz a zaste to stremaovat?

[VSi]

Nevím, určitě to umí VLC, ale přesně neporadím. Ve VLC jde všechno naklikat v GUI a pak si zkopírovat commandline příkaz, který bude dělat to samé.

[Hrabosh]

Zkusím dát tomu VLCčku eště šanci. Já jsem ho chtěl původně použít na streamování místo toho getstreamu, ale nepovedlo se mi to rozchodit a taky sem četl, že dost zaměstnává processor a pár lidí se stěžovalo i na memory leaky.

Kdyby tak existovalo něco menšího .... nenáročného .. ?

[Jendа]

Zkusil bych chytit stream a překódovávat ho ze souboru do souboru a podíval se, kolik dává při kódování FPS.

[Hrabosh]

No uvidím, jak to dopadne s tím VLCčkem. Každopádně se ta PII asi zapotí

[Miklik]

Zkoušel jsem doma na Duronu 1,2GHz grabovat video z DVD a codovat do mpeg4 a bylo to na hodiny.

[Grunt]

Na Pentiu II o 350Mhz bych nic takového nedělal. A překódování také ne. Už tak to většinou nevypadá nic moc a ještě víc snižovat bitrate + to zpracovávat. Prostě ne.

[jehovista]

Taky jsem to takhle doma delal a mam pocit, ze se vzdy posilal cely multiplex najednou.

[Ant]

Třeba VPNka, natažená přes WiFi, už nemá dostatečnou průchodnost na to, aby se na ten stream dalo dívat

Tohle se mi nejak nechce zdat. Kazdy z tech muxu ma 19Mbps a to by snad 802.11g melo prenest v pohode vcetne tech RTCP zprav, VLAN bajtu a SAP paketu. To zase nemuze byt takovy overhead (10%?). Zkontroluj si, ze ti to jede RTP nad UDP, zrus vorechy, co ti ucpavaji linku s HTTP pres TCP (nebo je zarizni pres QoS, kde je das uplne na konec "kdy jeste zbyva nejake pasmo") apod.

Jako jine reseni se mi jevi:

• Jestli se lidi divaji prevazne jen na nektere programy, jak ten DVB stream rozbij na jednotlive programy a ty multistreamuj
• real-time rekomprese do MPEG4/VP8, ale to chce novy pocitac nebo jeste lepe vykonnou grafickou kartu na prekodovani

[Ant]

Oprava: Ted jsem si vsiml, ze mluvis o VPN a ne o VLAN.

Ujistil bych se, ze ten stream posilas pres tu WiFi jen jednou a ne 2x (jednou nekodovane, podruhe zapouzdrene ve VPN)

Taky mi neni jasne, jake mas spojeni "zvenku" k serveru, ze ti to pres VPN nefunguje. Protoze jestli to chapu dobre, tak v tomhle pripade uz neni ve hre ta WiF a presto mas porad problem s nedostatecnym pasmem. Nepouzivas tam na te VPN nejake sifrovani, ktere to CPU nedokaze zvladnout? Jake mas zatizeni procesoru s a bez toho VPN?

[Hrabosh]

Ta Wi-Fi je 802.11b.

Jinak na té síti kromě mě nikdo není, takže nějaká nepředvídaná zátěž HTTP přenosama se nekoná. Pakety určitě chodí jen do tunelu ... co nejde tunelem se zahazuje.

Připojení zvenku opravdu není přes WiFi. Zkoušel jsem se dívat na serveru na to, jak vytěžuje processor process openvpn a bylo to max 11%. Přehrával jsem u toho přes to VPNko ze serverovýho NFS disku film, takže datovej tok tam byl.

[Ant]

Tomu nejak nerozumim.

Jak chces proboha protlacit 19Mbps (nebo kolik ma ten cisty transport stream) pres WiFi, ktera v idealne pripade umi jen 11Mbps?

Navic jake mas pripojeni zvenku k tomu svemu pocitaci? Ono zase neni moc domacich (nebo LAN<->LAN) pripojeni, ktera by mela upload kolem tebou pozadovanych 20Mbps.

Jestli to streamovani mas jen pro sebe, tak se mi zda jako blbost prehazovat si cely multiplex sem a tam, kdyz pak 75-80% (tedy 3-4 programy z tech 4-5, co jsou v muxu) zahodis. Rozdel ten muxu na programy a streamuj je zvlast.

[Hrabosh]

No já myslím, že to jede zvlášť. Ten getstream má v konfiguráku nastavení pro každej kanál toho streamu a já pak např. mplayeru předhodím http://server:8000/CT1 a on začne přehrávat ČT1.

Navíc ... na tom veřejnoprávním multiplexu jsou i radia a ty přes tu VPNku jedou. Kdyby se ten stream posílal celej, jak vypadne z karty, tak by nešlo ani rádio, ne?

[Oskar]

To vypadá zejména na problém s HTTP, přesněji tedy TCP streamingem. Pokud je šířka pásma jen o málo větší, než kolik dat bys do něj chtěl nacpat, stane se lehce, že když se obsah do pásma nevejde a TCP segment se zahodí, mechanizmus flow control přiškrtí rychlost odesílání na polovinu. Ta polovina je už mnohem méně, než datový tok DVB-T kanálu, takže začne přetékat odesílací buffer. Tím se video zcela znehodnotí.

Pokud máš pocit, že tohle je tvůj problém, můžeš zkusit posílat si video RTP/UDP, nebo udp streamem. Tam aspoň při ztrátě paketu zůstane zachována rychlost odesílání a 188-Bytová MPEG-TS synchronizace, takže to dekodér lépe přežije.

Můžeš to zkusit třeba takto:

Na straně příjemce: $ vlc udp://:1234

A na straně serveru: $ wget -qO - http://server:8000/CT1 | nc -u <adresa klienta s vlc> 1234

Pak mě ještě napadá, že by se dal snížit objem dat vypuštěním VBI streamu, který obsahuje (zejména) teletext. Tenhle stream má kolem 224 kbps a většina uživatelů ho nepotřebuje. Bohužel, getstream ho neumí jednoduše vyhodit, ale mohlo by fungovat dát do definice vstupů místo pnr 0x101; sadu PIDů – pro ČT 1 např: 0x0, 0x100, 0x101, 0x111.

[Grunt]

v idealne pripade umi jen 11Mbps?

6Mbps. Zbytek je režie. Možná by přes to jeden kanál dostat mohl.

[Ant]

Kazdy z tech kanalu ma v prumeru asi 4Mbps (mux1, mux2), ale muze to litat nahoru a dolu podle sceny, protoze ty multiplexy jsou statisticke (tzn. programy si berou rychlost podle toho, jakou zrovna potrebuji). CT24 a Barrandov by mely mit nejmene ze vsech TV (CT skrti CT24 protoze je to "jen zpravodajsky kanal" a Barrandov nema penize)

Asi ti nezbyde nic jineho, nez monitorovat detailne rychlost na linkove vrstve toho wifi spojeni a pak se kouknout, jestli se zahlcuje a kolik ti zahazuje paketu.

Samozrejme tim nejjednodussim resenim by bylo neskrtit prachy a vyplaznout litr za Geckove AP a/nebo kartu Snad tu wifinu nehodis v nejakych brutalnich podminkach (velke vzdalenosti/velky utlum, ruseni atd.)

S tim pristupem z venku to bude to samy. Proste na to nemas pasmo (upload) a nemas ani vykon na to prekodovat to video zabehu.

Přehrával jsem u toho přes to VPNko ze serverovýho NFS disku film, takže datovej tok tam byl.

Nepises nic o tom,jaky to melo bitrate (DVD ve Xvid?)

[Oskar]

Na tak slabém HW rekomprese asi nehrozí, ale zkusil bych TVHeadEnd a jeho protokol HTSP (Home Tv Streaming Protocol). Osobně jsem to nezkoušel, ale podle FAQ:

Why does HTSP use TCP? I thought it was bad to use TCP for realtime sensitive traffic?

‘HTSP’ – (Home Tv Streaming Protocol), the protocol used for streaming TV, sending meta information updates and RPC between Tvheadend and a HTSP client uses a transmission scheduler with multiple queues on the Tvheadend side. This means that Tvheadend can measure the available bandwidth between itself and the media player and when congestion happens it’s even capable of dropping less important data (such as B-frames). HTSP has been tested over WAN links and DSL connections with no video or audio artefacts.

Pokud to vyzkoušíš, poděl se o zkušenosti.

[Jirka]

Problém je, že to žádný normální klient neumí zpracovat. Já vím jenom o Showtime (od autora HTSP/tvheadend) a XBMC. Obojí je značně nepraktické mimo použití s televizí.

[Ant]

Třeba VPNka, natažená přes WiFi, už nemá dostatečnou průchodnost na to, aby se na ten stream dalo dívat.

Pises, ze VPN ti nezatezuje procesor a jdou ti prehrat filmy z NFS, presto DVB-T uz nestiha. Jestli to neni pozadavkem na vyssi rychlost v DVB-T, tak pak snad uz jen samotna rezie VPN (priznavam, ze nemam vubec predstavu, kolik si VPN v realne situaci bere).

Pak uz by ti asi nezbyvalo nic jineho, nez to zkusit tunelovat pres SSH a doufat, ze jeho rezie bude mensi nez ta VPN.

[Zdeněk Štěpánek]

Pouzivam prevod SD streamu z originalniho MPEG-2 do h.264 a na C2Q 9550 (4x2.66Ghz) to vytizi vsechny 4 jadra na 30%. Vysledny bitrate nastavuju od 512kbps do 1.5Mbps a nema na vytizeni CPU az tak zasadni vliv.

Takze s tvym procakem IMHO nemas sanci.

Zdenek