[JiRo]

@Rene.hav Já se omlouvám za to, že když jsem si kdysi četl popis ffmpeg, tak jsem si funkci parametru -re vyložil špatně a všem ho svými návody doporučil. Je pravda, že jsem to také někde okopíroval i to, že to použití -re má v některých případech své opodstatnění. Ale tento případ to rozhodně není.

---

@otava5 Myslím v Kodi klientovi. Na DO Pause nebo Play/Pause nebo přes klávesnici mezera Ctrl-P. Chvíli počkáš a pak znova pustíš. Stačí pár sekund. Načte se to do timeshift bufferu v Tvheadend a po spuštění tam máš dostatečnou vatu na to, aby to spolykalo všechny krátké prodlevy v načítání streamu.
[attachment=4366]

[rene.hav]

@JiRo: Dovolím si ještě jeden dotaz: Při použití ffmpeg trvá spuštění kanálů "věčnost" - kolem 15s. To je normální stav?

[mobilemanic]

otava5: timeshift musis na tvh nejdriv aktivovat. Pak pujde pauza.

[JiRo]

@mobilemanic No, to by mě fakt nenapadlo, že starý mazák @otava5 neví, že se timeshift musí nejdřív aktivovat. Dík za poznámku. BTW není to default zapnuté?

---

@Rene.hav No, chvíli si to vezme, ale 15 s, to je samozřejmě moc. Já mám ffmpeg pouze u O2TV, čas přepnutí mám právě teď do 2 vteřin. V průběhu dne se to mění a řekl bych, že se to mění i kanál od kanálu. Je asi hodně parametrů, které to mohou ovlivnit a na většinu z nich člověk nemá vliv. Typ a parametry kódování na zdrojové straně, zatížení zdroje, propustnost trasy, možná dynamika scény do které přepínáš, parametry ffmpeg. Pokud to srovnáváš s něčím jiným, je vhodné to dělat vždy za stejných podmínek.

[otava5]

Děkuji chlapi....

[rene.hav]

@JiRo: momentálně to používám takhle: pipe://ffmpeg -fflags +genpts -i http://stream -vcodec copy -acodec copy -f mpegts -mpegts_service_type digital_tv pipe:1

Zatím se mi nedaří na internetech najít, co bych mohl udělat proto, abych těch 15s nějak srazil na řekněme alespoň 5s. Pokud to tedy jde? Když se podíváš na ten můj pipe:// - nenapadne tě, jak bych to mohl "učesat" případně přidat/ubrat nějaké parametry?

[mobilemanic]

rene.hav:
1) pročti debug log, co tam ffmpeg píše (nebo ten příkaz pusť v konzoli, líp se v tom pak čte).. může tam být nějaké vodítko...
2) mě se stává, že se sice kanál načte relativně rychle, ale pak čeká hooodně vteřin na sync s audiem, do té doby obraz jakoby stojí, teprve až zvuk dojde do toho správného bodu tak se k tomu přidají i pohyblivé obrázky... nemáš to taky tak?
3) analýza streamu může také trvat dlouho, pokud je divný a ffmpeg neví jistě.. (nejdřív musí zjistit co to je a pak teprve to může pustit), dá se to ovlivnit parametry >vstupu<: -analyzeduration 0 -probesize 1000000 což by mělo analyzovat jen první přijatý megabajt a řídit se jen podle něj...

[JiRo]

@Rene.hav V podstatě tam nic špatného nevidím. Já používám ve scriptu toto:

ffmpeg -fflags +genpts -loglevel fatal -i ${stream} -probesize 32 -c copy -f mpegts -mpegts_service_type digital_tv pipe:1

Použití -loglevel fatal ušetří pár desítek (až jednu dvě stovky) ms, každopádně je s ním výpis logu Tvheadend přehlednější, na druhou stranu, když tam není, tak zase vidíš v Tvheadend logu skladbu streamu. Použití -probesize 32 je diskutabilní, pokud nějaký vliv má, tak opravdu je pár ms.

Ještě se zkus podívat do na stav v Tvheadend Stav > Odběry. Tam je hezky vidět, kdy začne dostávat server data z ffmpeg a začně je přijímat. Dokud je nemá, ve sloupci stav se po spuštění kanálu objeví Testování, tzn. že čeká na data od ffmpeg. Vlastně ta doba, po kterou je tam stav Testování dělá největší prodlevu. To je čas od spuštění ffmpeg do doby, než server rozpozná data streamu. Pak se ten stav změní na Běží. Dobré je podívat se na to, v jaké relaci jsou hodnoty ve sloupci Vstup a Výstup. Po spuštění kanálu, pokud se používá ffmpeg bez -re se většinou ta vstupní hodnota nafoukne (mě například běžně vyletí až na 9-12 Mb/s) to jsou ty 2 vteřiny prodlevy, které se nabufferují v ffmpeg. Poté se to usadí a pokud je propustnost toku streamu stabilní, pak Vstup=Výstup. Docela by mě zajímalo, co se u tebe děje v té době 15 sekund, co trvá přepnutí kanálu.

[otava5]

JiRo: co dělají tyto -fflags +genpts příkazy?

při aktivaci timeshiftu funguje jen po dobu pořadu nebo po dobu sledování kanálu?

[JiRo]

@otava5 -fflags +genpts se týká způsobu získávání PTS (presentation timestamp) v případě, že chybí pomocí údajů z DTS (decode timestamp). Souvisí to s procesem dekódování streamu a časovými značkami, umožňující správné řazení I, B a P snímků. Jinými slovy řečeno, by nás to asi nemělo zajímat, pokud nejsme schopni posoudit jaké stavy ve zpracovávaných streamech se tím řeší.

Timeshift nemá žádnou relaci k pořadu, pouze k kanálu a klientovi. Pro každého klienta se tedy vytvoří (po spuštění nebo přepnutí kanálu nebo po prvním převinutí zpět nebo pause - záleží na parametrizaci v Tvheadend) buffer, po skončení přehrávání se buffer zruší. Po přepnutí kanálu se dosavadní obsah bufferu klienta timeshift smaže (nebo se zruší a znova vytvoří, to přesně nevím) a začíná se znova. Buffer může být částečně nebo pouze v RAM jinak je na disku. Parametrovat se to dá v Konfigurace > Nahrávání > Timeshift.

[rene.hav]

@mobilemanic @JiRo: Tak jsem vyzkoušel vaše doporučení, přidal jsem vámi zmíněné parametry a srazil jsem to nějakých řekněme 5s - pohybuji se teď někde mezi 5-10 sekundami. Co jsem tak pochopil, tak lepší už to nebude(s tím dokážu žít:)
Díky za to, že se tady s námi dělíte o vaše znalosti.

[rene.hav]

Řeším teď tento problém: mám streamy, které obsahují dvě zvukové stopy, jedna označená jako "CZE" a druhá jako "MUL" - ta je buď v jiném jazyce, než českém, nebo obsahuje audio description pro zrakově postižené. Nicméně po průchodu ffmpeg obsahuje stream už jen a právě tu "MUL" stopu a nevím, jak TVH donutit, aby použil tu "CZE" - poradíte někdo?

---

Dodám, že jsem zkoušel nastavit v Audio Stream Filters, aby 1) TVH použil "CZE" stopu - bez výsledku 2) Aby TVH ignoroval onu "MUL" stopu - což udělá, ale pak jsem úplně bez audia. Z toho usuzuji, že TVH přijme obě stopy, ale dál pošle jen jednu - jak mezi nimi volit?

---

Tak jsem na to přišel, do příkazu je potřeba přidat parametr -map.
Příklad použití v příkazu převzatého od @JiRo:

pipe://ffmpeg -fflags +genpts -i *STREAM* -vcodec copy -acodec copy -map 0 -f mpegts -mpegts_service_type digital_tv pipe:1

[JiRo]

@Rene.hav Pochopil jsme, že to do TVH pereš přes ffmpeg. Pokud tam máš jen prosté copy audio streamu a ffmpeg si vybere MUL, tak filtrace v TVH nepomůže, protože se prostě ten CZE audio stream do něj nedostane.

Těch možností jak to řešit je víc, záleží asi na verzi ffmpeg, vím, že ne vždy i všech verzích všechno funguje stejně. Já bych zkusil následující postupy:

1. poslat do TVH všechno, to by se mělo dosáhnout parametry -vcodec copy -c:a copy -map 0
   
2. poslat do TVH jen vybrané streamy, tedy místo -map 0 z předchozího bodu použít -map 0:0 -map 0:1 -map 0:2 atd. Myslím si, že jakmile jednou použiješ -map 0:<číslo streamu>, musíš pak namapovat všechny, tedy i ten video stream. Kdysi jsem si s tím hrál a napsal to v http://www.xbmc-kodi.cz/prispevek-tvheadend-a-iptv?pid=30474#pid30474, ale nikdo na to nereagoval, pro mne to pak přestalo být aktuální, a tak jsem se tomu už nevěnoval.
   

Pokud do TVH pošleš víc audio streamů, pak už můžeš použít Audio Stream Filters v TVH nebo to nechat na klientovi v Kodi (pokud ho používáš), aby si podle tvého nastavení v Nastavení > Přehrávač > Zvuk vybral.

---

Tak jsme se krásně minuli. Vidím, že sis poradil. Nebyl jsme si jistý, jestli v tomto případě není třeba místo -acodec copy použít -c:a copy (už si hodně věcí nepamatuji), ale jak je vidět, je to asi jedno, ty příkazy jsou ekvivalentní.

[rene.hav]

@JiRo: Díky za, jako vždy, fundovanou odpověď. Použiju to jako -map 0, protože v mém playlistu není požadovaná stopa vždy na stejném čísle. Je tedy jednodušší nechat projít všechny stopy a pak v klientovi, kterým je Kodi zvolit CZE stopu. Pokud to tedy nebude mít nějaká negativa, na které vždycky přicházím až časem v ostrém provozu :)

[JiRo]

@Rene.hav No jo, ono se vždy něco objeví Napadá mě zatím jen jedno. Jak se to bude chovat v případě HLS streamů...

---

Je asi rozumné to nechat na Kodi klientovi, nicméně ta filtrace streamů v TVH je dokonalá a umožňuje opravdu sofistikovanou filtraci. Jen je trochu na "bednu" se to naučit nastavovat.

[rene.hav]

@JiRo: O tom nepochybuji HLS streamy nemám, nemohu to tedy ověřit.

[JiRo]

@Rene.hav Tak jenom kdybys někdy narazil na HLS, tak -map 0 nemůžeš použít na celý HLS stream, protože pak by ffmpeg posílalo do TVH úplně všechny streamy. Musíš si z něj nejdříve vyparsovat potřebný stream. Každý asi bude chtít ten nejkvalitnější, což bývá bětšinou ten poslední, a teprve potom ho vložit do ffmpeg s parametrem -map 0.

[rene.hav]

Tak zase po delší době řeším problém. Jsem teď ve stavu, kdy všechny streamy posílám skrz ffmpeg, rychlost přepínání do 3s - spokojenost. ALE! Úplně každý den, třeba jen jednou, ale přece, mi během přehrávání streamu HTSP klient zahlásí "NO SIGNAL" a stream se zastaví - pokud nastavím restart on error, tak přehrávání po chvilce pokračuje, ale je to šílené otravné, log TVH nepíše žádné errory Jediné co v logu vidím, že se děje před zářezem: Previous line repeats *X* times

[JiRo]

@Rene.hav Tak s tím jsme se ještě nesetkal. No, asi primární by mělo být zjistit, kdo to zařízne. Jestli ffmpeg nebo tvh. To hlášení No signal HTSP klienta je až důsledek toho, že server nic nepošle.

Restart on error..., to nastavuješ asi u stremu v TVH (nebo někde jinde)? Zkusil jsi něco podobného u ffmpeg? Tam jsou na to parametry reconnect... Viz http://ffmpeg.org/ffmpeg-protocols.html#http.

Ještě jsem přemýšlel, jestli to není důsledek nerovnoměrného načítání streamu do TVH. Pokud v ffmpeg není parametr -re, tak to ffmpeg načítá maximální možnou rychlostí a pak vždycky následuje dlouhá pauza s 0 přenosem (je to vidět v TVH gui Stav > Odběry > Vstup a Výstup). Tady hodně záleží hodně na zdroji. Některé servery mají poměrně plynulou dodávku dat i bez parametru -re, u jiných to fakt hodně kolísá.

Jinak u TVH se dá nastavit úroveň logování v Konfigurace > Ladění. Možná tam získáš detailní info. A pokud v parametrech ffmpeg používáš -loglevel fatal, tak to zruš. DO TVH se ti dostane podrobnější log z ffmpeg.

Nic lepšího ti asi momentálně neporadím.

[rene.hav]

@JiRo: Ano, restart on error mám nastavený u streamu. Díky za rady, postupně vyzkouším. Poradíš mi ještě, do které části ffmpeg příkazu přidat parametry pro reconnect a -re? Nebo na tom nezáleží?

Jinak musím říct, že začínám podezírat TVH na Synology DSM, zkusím TVH případně nainstalovat na jiný stroj s jiným OS.