• Vítejte na XBMC-Kodi.cz
  • Česko-slovenská komunita fanoušků XBMC/Kodi
Vítejte návštevníku! Přihlášení Registrace


Hodnocení tématu:
  • 3 Hlas(ů) - 4.67 Průměr
  • 1
  • 2
  • 3
  • 4
  • 5
Playlist O2TV.CZ script - vývoj a podpora zde ukončena
#21
Taky to nechci úplně svádět na ffmpeg. Může být nějaké zpoždění u TVH a všechno, ale pokud použiju playlist 2, tak je to rychlé snad skoro pořád. Ale ano, některé kanály mají horší odezvu a ano, objevuje se kolikrát hned první snímek, ale pak plynule to začne po pár sekundách.
 
#22
Zdravím, v první řadě bych chtěl poděkovat JiRovi za vynikající skriptík. S tím pro mě konečně O2TV dostala pořádný smysl :-)
Nicméně jsem zjistil že se při použití playlistu typu 3 (tvheadend@) chová ffmpeg trochu podivně. Každý kanál má playlist, který vypadá přibližně takhle:

Kód:
#EXTM3U
#EXT-X-VERSION:2
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=800000
http://adresa/360u0.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1400000
http://adresa/366u0.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2450000
http://adresa/365u0.m3u8
Obsahuje odkazy 3-4 další playlisty, které odkazují na streamy v různém rozlišení. Ve výchozím nastavení při použití streamer.sh si ffmpeg vybere video stopu s nejvyšší kvalitou a to samý se pokusí udělat i s audio stopou. Jenže všechny audio stopy mají stejnou kvalitu. Takže si vybere video z 365u0.m3u8 a audio z 360u0.m3u8. Zbytečně se tedy stahujou oba streamy, což je nejen zbytečná zátež na připojení, ale způsobuje to i výpadky streamu.
Zkoumal jsem tedy co s tím, až z toho vylezl mírně upravený streamer.sh
Kód:
#! /bin/bash
source=$*
stream=$(grep -A 1 "${source}$" o2tv.generic.m3u8 | head -n 2 | tail -n 1)
streamcount=$(wget -qO- ${stream} | grep -Eo "(http|https)://[\da-z./?A-Z0-9\D=_-]*" | wc -l)
streamcount=$((streamcount-1))
ffmpeg -re -fflags +genpts -loglevel fatal -i ${stream} -probesize 32 -c copy -map p:${streamcount}? -f mpegts -mpegts_service_type digital_tv pipe:1
Zjistil jsem, že streamy jsou řazeny podle rozlišení od nejmenšího po největší, takže stačilo jen spočítat odkazy a podle toho pomocí parametru -map přinutit ffmpeg použít ten co je nejníž tak jak je. Vítaným vedlejším efektem je navíc, že fungují všechny audio stopy.
(a než se zeptáte: inteligentnější řešení mě fakt nenapadlo :) )
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#23
@pavvucek Díky, to je hodně užitečné zjištění a rychlé řešení. A s jeho "inteligencí"  se netrap. Pokud funguje a "nemá vliv na funkci", tak je správné. Rozhodně lepší, jak stahovat oba streamy. To jsem fakt netušil. Ale jak už jsem někde výše napsal, měl jsem O2TV zaplacené vždy jen na 24 hodin a už jsme neměl sílu to všechno prověřovat. Tak trochu jsem se spoléhal, že si s tím komunita už nějak poradí. A vida, stalo se.  6 

BTW Nemohl by tady být další zdroj prodlev při přepínání kanálů? Sice ten wget navíc taky něco času sežere, i když ony se ty soubory stáhnout tak jako tak musí. Co je ale důležité, že ffmpeg nemusí provádět tu úvodní analýzu streamů 2x. Zjistil jsi po té úpravě nějakou změnu rychlosti přepínání?
 
#24
Změna rychlosti přepínání asi nějaká možná bude, ale spíš asi zanedbatelná. Mě to trvá cca 3-4 sekundy, ale furt je to rychlejší než přepínání kanálů ze vzduchu (8-10s).
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#25
mám dotaz...Vám jedou streamy v 1080?Mě jen 720....
 
#26
@otava5: mě jdou v plných 1080p jen programy ČT (1,2,24 ostatní jsem nezkoušel). Některý další (Prima, Nova) mám v 720p a zbytek je v 1024x576.
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#27
@pavuucek Je to OT, ale zarazila mě tvoje poznámka "ale furt je to rychlejší než přepínání kanálů ze vzduchu (8-10s)." O jaký příjem se jedná, kde je taková prodleva při přepínají kanálů?
 
#28
@pavuucek-dobrej script,palec nahoru s tema audiostopama.dotaz,kdyz dam kvalitu 720,tak se vse prehrava v pohode,ale jakmile dam 1080 tak to mam trhane s vypadkami(napr o2 sporty )mate to taky tak?
Rpi3-raspios-tvh+hyperion  ,  Kiii pro-Coreelec 9.2.8-tvh+sat (testy),  Ugoos X3 Pro dualboot ATV/CoreElec
 
#29
@JiRo: normální dvb-t. Možná je to tvheadendem, nebo tunerama - mám nějaký starý AverTV, a Evolveo Venus (oba se v systému hlásí jako Afatech AF9033). Ještě mám síťový Hdhomerun, který mám jen na dvb-t2 a přepíná přibližně stejně rychle jako o2tv. Moc to ale neřešim, tyhle 2 tunery asi beztak půjdou pryč.

@ericek74: o2 sporty jsem zkoušel jen chvíli, ale čt programy mi jdou dobře bez výpadků
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#30
@pavuucek Hmm, zvláštní, Evolveo Venus mám 2x a naprostá spokojenost, přepnutí do 1s.
 
#31
@ ericek74 Hele, tak nejsi sám. Já teda nekoukal, v čem je problém, ale seká se mi i HD i FHD. A nějakým způsobem mi přijde, že pokud kanál zapnu po nějaké době, tak dobrý, ale jak přepnu, tak se to začne sekat. Tak nevím, v čem je problém, zatím jsem nekoukal. V přípojce k netu určo ne, Gbit je Gbit, může být problém v Ubuntu ve WSL, na kterém to provozuju, třeba mi na to ten PC, na kterém to běží, nestačí, můžu mít zaprasené Kodi po těch xx testech kde čeho. A nebo prostě mizérie O2. Ale že bych se trefil pokaždé do špičky a tak, to je mi divný. :-)
Ještě zkusím na jiném pc.

Asi bude chyba v tom PC, na jiném PC v síti není problém dle krátkého testu. A protože je to jen obyč PC a zaprasené Kodi, které poslední dobou i dost padá, je možné, že to je tím.

Zakřikl jsem to. :-D
 
#32
Především chci poděkovat za super práci @JiRo! Funguje to skvěle. Mám dva dotazy:

1) Jak často je potřeba refreshovat ty playlisty, jak často bych měl ten skript cronem spouštět?
2) Existuje nějaké řešení pro EPG v Tvheadend (jak mít u kanálů aktuální program)?

Díky moc!
 
#33
@lasthunter
ad. 1 Někdo tady na fóru napsal, že se tokeny (které jsou součástí streamu v playlistu) mění po 2 hodinách, já si myslím, že po 6 hodinách. Ale každý token je  funkční až 24 hodin nebo do doby než vygeneruješ nový.
ad. 2 Script  EPG z O2TV tahat neumí, takže si ho musíš získat jinde. Buď použít nějaký zdroj xmltv (např. 22century.cz nebo data která poskytují někteří uživatelé), nebo si xmltv vygenerovat z nějakého zdroje (zdrojů) pomocí Webgrab++. Odkaz na xmltv pak zadáš do Tvheadend serveru jako interní zdroj EPG. Je tady na to ve fóru Live TV & PVR poměrně hodně infromací.
 
#34
@JiRo Ahoj ještě jednou, O2 TV funguje stále výborně, až na momenty, kdy nestíhá moje internetová přípojka (obvykle večer). Trochu jsem si hrál se skriptem, a přišel jsem na to, že do deviceType (to, co je v konfiguraci _stream_quality_) se dá poslat "STB"/"MOBILE"/"TABLET". Víš ještě o nějakém dalším nastavení pro nižší rozlišení? Teď večer je zajímavá, že "STB" teď na O2TV Tenis posílá nižší rozlišení než "TABLET".

Jinak, běžně když se mi sekají programy ze satelitu, tak Tvheadend hlásí continuity errors a já se o tom dozvím. To propojení přes FFMPEG a generatedstreamer.sh tuhle fíčuru nemá, continuty errors se mi nelogují. Nevíš proč? Neexistuje nějaká option pro ffmpeg, díky čemuž by Tvheadend poznalo, že se stream seká?
 
#35
@lasthunter O žádném dalším nastavení kvality bohužel nevím. Detailnější výpis ffmpeg zajistíš v parametru -loglevel. Ale doáhneš jenom toho, že se to zapíše do logu TVH.
 
#36
Poslední dobou mě trápili úplně stejný výpadky jako alibababu v sousedním tématu. To jest podivné výpadky a všeobecná nestabilita streamu.
Tak dlouho jsem nad tím laboroval až mi z toho vylezl Pavůčný streamer skript verze 2.0 :-)

Kód:
#! /bin/bash
source=$*
tempplaylist=$(mktemp -u)".m3u8"
stream=$(grep -A 1 "${source}$" /media/Archive/HTPC/o2dl/o2tv.generic.m3u8 | head -n 2 | tail -n 1)
wget -qO ${tempplaylist} ${stream}
streamcount=$(cat ${tempplaylist} | grep -Eo "(http|https)://[\da-z./?A-Z0-9\D=_-]*" | wc -l)
streamcount=$((streamcount-1))
if  [ "$streamcount" = "-1" ]; then streamcount=0; fi
/opt/ffmpeg/ffmpeg -protocol_whitelist file,http,https,tcp,tls -fflags +genpts -loglevel fatal -i ${tempplaylist} -probesize 32 -reconnect_at_eof 1 -reconnect_streamed 1 -c copy -map p:${streamcount}? -f mpegts -tune zerolatency -bsf:v h264_mp4toannexb,dump_extra -mpegts_service_type digital_tv pipe:1
Před použitím si samozřejmě upravte cesty k playlistu a ffmpegu.

První novinkou je, že se playlist stáhne a uloží do tempu a poté se předá do ffmpegu. Tudíž se nemusí stahovat dvakrát a přepínání kanálů by mělo být rychlejší. Bohužel pouze minimálně.
Za další by už nemělo docházet k výpadkům streamu, za což paradoxně může to co jsem ze skriptu odstranil, než to co jsem tam přidal.

Zatracený parametr -re. (A taky zatracená nepřehledná dokumentace ffmpegu)
Citace:-re (input)
Read input at native frame rate. Mainly used to simulate a grab device, or live input stream (e.g. when reading from a file). Should not be used with actual grab devices or live input streams (where it can cause packet loss). By default ffmpeg attempts to read the input(s) as fast as possible. This option will slow down the reading of the input(s) to the native frame rate of the input(s). It is useful for real-time output (e.g. live streaming).

Stručně řečeno -re funguje jako omezovač rychlosti a vysílaný stream se tedy stahuje maximálně tak rychle jak se přehrává. Což nechceme. Chceme stahovat aspoň něco trošku dopředu, jinak bude docházet k výpadkům.
Ostatní parametry ffmpegu jsou spíš pozůstatky pokusů. Neškodí a je poněkud sporné jak moc mají pozitivní účinky. Za zmínku stojí jen -tune zerolatency. Ten hodně pomohl snížit výpadky předtím než jsem přišel na to co znamená parametr -re...

Tož užívejte dle libosti :-)

@lasthunter: do _stream_quality_ se dá poslat ještě hodnota "PC". Nicméně jediný účinek který jsem zaznamenal byl, že v playlistu měly adresy tvar doménového jména, místo pouze ip adresy.
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#37
@pavuucek No, konečně někdo, kdo si dal práci s ffmpeg. Super. Přiznám se, že jsem -re chápal jinak, resp. jsem asi nečetl tak podrobný popis. Měl jsem za to, že to naopak omezuje rychlost na tu přehrávanou na výstupu. Když si čtu tu tvoji citaci, tak je jasné, že tam ten parametr nemá co dělat. Dobrá práce.

Asi bych to měl uvést v 1. postu tématu, a možná i opravit default script. Uvedu tě jako autora. Souhlasíš?
 
#38
Ahoj chlapi, tak jsem ten skript vyzkousel a pise mi to tohle... Co zase delam blbe?
Kam do tempu se ma ten playlist stahnout? Nikde ho tam totiz nemuzu najit.

Diky za Vasi pomoc

2018-09-01 23:16:14.956 mpegts: o2tv.playlist.m3u8 - ČT sport HD in O2TV - tuning on IPTV
2018-09-01 23:16:14.960 spawn: Executing "/storage/.kodi/userdata/addon_data/service.playlist.o2tv/test.sh"
2018-09-01 23:16:14.961 subscription: 000B: "scan" subscribing to mux "o2tv.playlist.m3u8 - ČT sport HD", weight: 6, adapter: "IPTV", network: "O2TV", service: "Raw PID Subscription"
2018-09-01 23:16:14.965 iptv: stdin pipe unexpectedly closed: No data
2018-09-01 23:16:29.956 mpegts: o2tv.playlist.m3u8 - ČT sport HD in O2TV - scan no data, failed
2018-09-01 23:16:29.956 subscription: 000B: "scan" unsubscribing

Skript vypada takto...
Kód:
#! /bin/bash
source=$*
tempplaylist=$(mktemp -u)".m3u8"
stream=$(grep -A 1 "${source}$" /storage/.kodi/userdata/addon_data/service.playlist.o2tv/o2tv.generic.m3u8 | head -n 2 | tail -n 1)
wget -qO ${tempplaylist} ${stream}
streamcount=$(cat ${tempplaylist} | grep -Eo "(http|https)://[\da-z./?A-Z0-9\D=_-]*" | wc -l)
streamcount=$((streamcount-1))
if  [ "$streamcount" = "-1" ]; then streamcount=0; fi
ffmpeg -protocol_whitelist file,http,https,tcp,tls -fflags +genpts -loglevel fatal -i ${tempplaylist} -probesize 32 -reconnect_at_eof 1 -reconnect_streamed 1 -c copy -map p:${streamcount}? -f mpegts -tune zerolatency -bsf:v h264_mp4toannexb,dump_extra -mpegts_service_type digital_tv pipe:1
 
#39
Děje se nám tu drobná podivnost. Teď jsem zkusil streamer skript spustit na libreelecu a zdá se, že tamní verze ffmpegu neumí parametr -tune zerolatency.
@alibababa zkus ho odmazat a teoreticky by ti to mělo normálně fungovat...

@JiRo samozřejmě že souhlasím a nějak zvlášť netrvám na tom být uveden jako autor. Beztak je to jen taková maličkost.
Server: i5-950, 16GB RAM, 1x120GB SSD, 1x 320GB + 4x 2TB HDD, Ubuntu 18.04, SW: TvHeadend, Plex Media Server (a jiné).
Klienti: Wetek Play 2 + Samsung 107cm TV, ASRock ION 330 + LG 82cm TV, záložní RPI3, SW: LibreELEC 8.2.5 / Kodi 17.6, PlexKodiConnect
 
#40
@pavuucek Jestli si dobře vzpomínám, tak @alibababa používal CoreELEC a podle něj tam ffmpeg není instalovaný. Používá tedy addon ffmpeg-tools, který ho tam doinstaloval. Upřímně řečeno se mi to zdálo divné, CE vychází z LE a moc mi nedává smysl, proč by ffmpeg odtamtud vyhazovali, ale budiž. Nemůžu posoudit. Každopádně bych s tím, že ffmpeg v LE nezná -tune parametr byl opatrný. V LE 8.2.5 buildu Generic AMD/Intel/nVidia GPU HTPC je v systému nainstalované ffmpeg version 8.2.4-7-g84fe69f, built with gcc 6.2.0 (GCC), které -tune má.
 
  


Přejít na fórum:


Prochází: 2 host(ů)