Přihlásit se na XBMC-Kodi.cz

(14.8.2018, 21:00)rasti Napsal(a):

(14.8.2018, 20:25)JiRo Napsal(a): @rasti Tady je můj řádek playlistu, je to v podstatě stejné, jako u tebe. Rozdíly jsou v:

-loglevel fatal - omezí výpis, což může o pár stovek ms zkrátit přepínání kanálu
-probesize 32 - zkrátí dobu analýzy vstupního streamu o pár desítek/stovek ms
-c copy - zjednodušený zápis pro kopírování audio i video streamu
-mpegts_service_type digital_tv - definuje typ streamu,  digital_tv je snad default, takže to asi není nutné, ale já to používám spíše ze zvyku

Kód:

#EXTM3U
#EXTINF:-1,ČT 1
pipe://ffmpeg -re -fflags +genpts -loglevel fatal -headers "Cookie: device_id=deviceid; device_auth=deviceauth; streamQuality=40"$'\r\n' -i http://sledovanitv.cz/playback/channel/ct1?format=m3u8 -probesize 32 -c copy -f mpegts -mpegts_service_type digital_tv pipe:1

@JiRo chapem, urcite vitana uprava...

Mám od sledovánítv dalíček úplného základu plus si přikupuji sport. Podle zdejšího skvělého návodu sem krok po kroku nejdříve podle @JiRo (pročetl sem i poznámky od mobilmaniac, rasti, tímto jim samozřejmě také díky) vyzkoušel internetová rádia, potom streamy v m3u8 a nakonec sem si troufnul i na sledovánítv.
Programy mám v tvheadend funkční, některé programy jedou FHD, některé HD, zbytek SD, ale všechny s codekem H264.
Předtím sem používal upravený PRV od Palinka na sledovánítv a něm jde povolit codek H265. Sem směřuje můj dotaz.
Jdou tyto zde uvedené cody upravit, aby se používal H265?
Děkuji, za rady.

@Tklf O Kódování h265 by mělo jít nastavit. Podívej se sem https://www.xbmc-kodi.cz/prispevek-ott-i...7#pid56677.

Ano, o tomto vím, jen si nejsem jistý, že je to opravdu H256, protože mi to codek přestalo ukazovat, ale rozšíření se z HD zvedlo do FHD. Jsem naprostý amatér, takže je možné, že jsem to blbě zabalil do roury.
Ovšem v tomto řešení se pravděpodobně budou měnit tokeny? kkežto v prvním řešení se údaje vyplní jen jednou a dokud zařízení nesmažu z webu sledování, poběží beze změn.

@Tklf Je to h265, resp. HEVC, což je jiné označení téhož.
[attachment=5050]
To, že se ti zvedne HD na FHD je právě důsledek použití kódování h265. Protože je úspornější, můžou zvednout rozlišení při zachování stejného (+/-) bitrate.

Sledovani má více různých api. U toho, které ti umožní vše nacpat do jednoho volání ale nevím, jak tam dostat request na posílání stremu s kódování h265. Proto jsme tě odkázal na tu další metodu, která používá jiné api, respektive jiný způsob autorizace. A to, že se ti změní obsah adresy streamu, ti nevadí. Pokud používáš playlist s pipe voláním skriptu, tak to ničemu nevadí. V playlistu se ti nic měnit nebude. Jen si zkrátka musíš čas od času (méně než měsíce) obnovit nové sessionid.

Takže vlastně dobře. Musím tedy porovnat ještě jednou s pluginem od Palinka, myslel sem si, že tam mají programy 50 snímků za minutu, já teda na tom testovaném mám jen pouze 25.
Prosím Tě, mohl bys mi jen tak pro jistotu a porovnání poskytnout jak to máš zabalené do roury ty? Pochopitelně bez údajů, ty si doplním své. Jestli to tedy není problém. Jistota je jistota.

Díky moc

@Tklf Už mi to nějakou dobu jede, ani ti to přesně neřeknu (navíc nejsem doma), ale bude to asi podobné (případně jen s kosmetickými úpravami)  jako je to v tom odkazovaném postu od @JiRo. Tedy:
Tu hodnotu session si generuji dalším scriptem, který pouštím 1x za 14 dní přes cron a ukládám do souboru, ze kterého si to ten výše uvedený skript čte.

Jinak ty snímkové frekvence i rozlišení se mohou lišit kanál od kanálu. Neznamená to tedy, že všechny kanály nutně mají 60 FPS a FHD jako NASA TV UHD.

Ok díky za info, se skriptem sem zatím nelaboroval, plnil sem to ručně. Proto pro mně byla priorita dostat to do stavu, aby se to měnit nemuselo.
Do skriptu se musím prokousat až nějak v dalším čase.

@Tklf No jo, to si musíš vybrat. Taky se mi do skriptů zpočátku nechtělo, ale vyplatí se to. Pokud budeš vycházet z toho, co se tu prezentuje, tak to zase nic tak složitého není. Já jsem časem začal skripty i vytvářet a i když občas narazím (naposledy u LepšíTV, kde je ale spíše problém na straně služby), u většiny jsem nakonec byl úspěšný. Dnes mi jich v Tvheadend běží 5 a kromě toho posledního, na kterém právě pracuji (Digi TV), o nich v podstatě ani nevím. Ta námaha tomu přijít na kloub se rozhodně vyplatí.
[attachment=5052]

Fajn, tak ještě jeden dotaz, ale z jiného soudku. Když vidím Tvůj TVH, jak si dostal nahoru správné místo na disku? Já k tomu na rychlo připojil externí disk, ale místo mi to ukazuje stále jen z karty, na které mi system CoreElec běží. To samé se mi pak ukazuje v Kodi.

@Tklf Tam se ti ukazuje místo na tom disku, na který máš nasměrovaný nahrávání.

Ano, to předpokládám, ale já nahrávám na externí disk a zůstal mi tam údaj z karty.
Je pravdou, že jsem původní nahrávací profil ponechal a vytvořil klonem nový. V novém profilu mám odkaz na externí HDD. Nahrávky se na něj ukládají, takže tohle funguje, pouze údaj o mistě je stále z původního místa (SD karty) a ne z externího disku.

@Tklf No, tak to asi bude tak, že se tam zobrazuje pouze default profil. Ono taky, jak a podle čeho by se asi TVH rozhodoval, který profil tam zobrazit, když jich uživatel má nadefinováno víc. Zkus do toho default profilu zadat stejnou cestu jako do toho, který používáš. A asi budeš muset restartovat.

Tak máš pravdu. Děkuji za nápovědu. Tohle, i když se to přímo nabízí, mne nenapadlo.

Jsem uživatel používající Mi A2 Lite , který neumí číst pravidla o nepoužívání podpisu z Tapatalku.

• download - stažení playlistu s adresami streamů přímo ze serveru služby. Toto řešení se v podstatě téměř nepoužívá a jen málo OTT služeb ho nabízí. 
  
• playlist - periodická generace playlistu s adresami streamů, případně kombinace obecného (general) playlistu (s voláním streameru) a generického playlistu (co je to generický palylist popíšu dále)
  
• onthefly - jednorázová generace nebo ruční vytvoření playlistu a „ontheflay request“ (například ve volaném streameru) o aktuální stream přímo serveru služby
  

Cache

Cache se může použít u těch řešení, kde je třeba (a je to možné) nějak urychlit časově kritické části (scripty), zpravidla ty řešené jako onthefly. Vyváží se tím nevýhoda tohoto řešení, jež plyne z toho, že se o finální adresu streamu (nebo manifestu) říká až streamer, což někdy může prodloužit dobu přepínání kanálu. Má-li dané řešení tuto možnost, zpravidla je možné ji použít jako alternativu. Použití cache je spojené s analýzou struktury adresy streamu (zjišťuje se platnost vygenerované adresy) a pokud provider tuto strukturu změní, přestane to fungovat. Proto je vhodné mít možnost používání cache obejít. Cache funguje tak, že streamer ověří, zda pro daný kanál existuje cache soubor, pokud ne, řekne si rovnou o adresu streamu, vytvoří cache soubor a adresu do něj uloží. Pokud zjistí, že cache existuje, načte si z ní adresu a zjistí, zda je platná a pokud ne, opět si řekne o novou. Z toho plyne, že cache má smysl pouze u těch služeb, které do adresy streamu ukládají časovou identifikaci její platnosti. Buď rovnou dobu platnosti nebo dobu, kdy byla adresa vytvořena. Doba platnosti je pak daná nějakou hodnotou platnou pro danou službu (například 24 hodin). Je zřejmé, že pokud dojde k přepnutí na daný kanál po době uplynutí platnosti cache, doba přepnutí kanálu se v tomto případě naopak o něco prodlouží.

Popis konkrétních řešení

V dalších postech tohoto tématu budu postupně zveřejňovat jednotlivá řešení podle výše uvedeného popisu.

Aktuální stav zveřejněných řešení:

• O2TV (Nangu-TV) - asi nejpropracovanější řešení. Je to hlavně proto, protože ho sám používám. I když jen v podobě tarifu Sport. Je to zároveň jakási výchozí aplikace pro řešení OTT od Nangu-TV, které používají i další provideři. 
  
• T-Mobile TV (Nangu-TV)  - de facto kopie řešení O2TV, upravené v těch částech, ve kterých se implementace Nangu-TV pro tohoto operátora liší.
  

Mám v plánu dále postupně uvést řešení pro:

• Sledovanitv.cz
  
• Sledovanietv.sk
  
• Kuki
  
• Digi (4NET platforma)
  
• Poda (4NET platforma)
  
• LepšíTV
  

Všechna tato řešení již existují, i když ne v podobě, jak je uvedeno výše, a jsou k dispozici v různých částech tohoto fóra. Původně jsem je chtěl postupně sjednotit, protože většina z nich vznikla v dřívějších dobách, ještě před výše uvedeným obecným popisem řešení. Ale ukazuje se, že vzhledem k času a mé kapacitě to není reálné. Proto k výše uvedenému seznamu přidám postupně pouze odkazy na místa, kde je řešení popsáno.

@Client: mě to nějak nejde... První pokus o login.sh druhý o login2.sh
Ano mám login ne-emailového tvaru

@otava5  He, he... Tak to jsem ještě neviděl!  Ale u login2 to zabralo, jak vidím. Tuhle variantu přihlášení (tedy ne přes e-mail) jsem ještě neviděl, a tak jsem s ní nepočítal. Zjevně je funkční pouze pro starý způsob autentizace. Tak to musím ještě doplnit do popisu. 

Ta druhá chyba, to je nějaká moje blbost. Na poslední chvíli jsem doplňoval nějaké kontroly, asi jsem zvoral nějaký "if" a už nezkontroloval všechny varianty možného zachycení chyb. Večer se na to podívám, dřív nemám čas ani možnost. Omlouvám se.

---

[EDIT] Tak jsem to naslepo opravil, chyby (bylo to tam 2x) byly skutečně tam kde jsme si myslel. Bylo to natolik zjevné, že by to snad už mohlo fungovat. 

@Client: zdá se že funguje login2.sh pro mě. Ten access.id stačí jen jednou vytvořit nebo se musí aktualizovat např. 1x za 24h?

@otava5 Ne, mělo by stačit vytvořit to jednou. Mně to běží už pár týdnů. Pokud se ukáže, že ta platnost bude nějak omezena, doplním tam script refresh.

@Client:
Tak se mi vytvořil playlist.general.m3u8 a v něm: 
není mi jasné odkud se berou streamy

linky sa zistuju priamo v streamer.sh