@otava5 No, včera večer jsem to taky zkoušel, a také mi to řešení, pokud tam není ffmpeg, nefunguje. Buď tam chybí ten agent, ale já nevím, jak ho tam dostat nebo je problém ještě někde jinde. Musím popřemýšlet a něco vymyslet. Tedy jestli se vůbec něco vymyslet dá.
Pokud jedeš přes ffmpeg, tak je začátek vždycky pomalejší. Někde se to tady už řešilo... Podívám se do historie.
EDIT: Pokoušel jsme se něco vymyslet, ale nevedlo to k cíli a ani nemohlo. Tak jsem včerejší doporučení v tomto postu zeditoval. Byly to blbosti a stejně na to nikdo zatím nereagoval tak nebude kontinuita diskuse porušena. V agentovi problém není.
Problém je v tom, že to volání přes parser, když se použije ffmpeg, funguje proto, protože parser spouští ffmpeg, který posílá stream přes rouru - proto je v parametrech ffmpeg pipe:1 a v Tvheadend pipe://. To v případě, když v playlistu ffmpeg nemáš, takhle fungovat nemůže.
Já to chápu tak, že pokud se v playlist pro Tvheadend objeví pipe://, očekává tvheadend na vstupu rovnou stream. A ten mu tam posílá ffmpeg díky parametru pipe:1. V případě použití mého jednoduchého parseru se tedy musí zajistit, aby "něco" z adresy ve staženém playlistu ten stream do Tvheadend posílalo. Napadá mě, vložit tam např. wget. U něj to zpoždění možná nebude tak velké jako u ffmpeg. Ale je to jen má laická úvaha, tady by asi mohl pomoci někdo zkušenější. Přesto to vyzkouším. Ale až zase večer, běžím do práce.
EDIT2nd: Tak jsem ještě rychle vyzkoušel wget. wget -qO - <adresa staženého streamu> by asi mohlo fungovat.
EDIT3rd: Ještě mě napadlo, že by bylo možné to volání wget zaintegrovat do parseru a neřešit vůbec playlist. Ten bych nechal beze změny tak, jak ho stáhneš od providera.
EDIT4th: Ještě jsem zapomněl na odkaz diskuse, kde se řešilo zpoždění při použití ffmpeg. Najdeš to zde Tvheadend a internetová rádia, hned na první stránce, příspěvky od @marhycz a @mobilemanic. Ale už tenkrát jsme myslím usoudili, že to zkrácení náběhu streamu, které se podaří optimalizací běhu ffmpeg, není nijak významné. Prostě jakmile použiješ ffmpeg, musíš počítat s nějakou tou sekundou navíc. A je jasné, že ten parser tomu taky něco přidá.
Pokud jedeš přes ffmpeg, tak je začátek vždycky pomalejší. Někde se to tady už řešilo... Podívám se do historie.
EDIT: Pokoušel jsme se něco vymyslet, ale nevedlo to k cíli a ani nemohlo. Tak jsem včerejší doporučení v tomto postu zeditoval. Byly to blbosti a stejně na to nikdo zatím nereagoval tak nebude kontinuita diskuse porušena. V agentovi problém není.
Problém je v tom, že to volání přes parser, když se použije ffmpeg, funguje proto, protože parser spouští ffmpeg, který posílá stream přes rouru - proto je v parametrech ffmpeg pipe:1 a v Tvheadend pipe://. To v případě, když v playlistu ffmpeg nemáš, takhle fungovat nemůže.
Já to chápu tak, že pokud se v playlist pro Tvheadend objeví pipe://, očekává tvheadend na vstupu rovnou stream. A ten mu tam posílá ffmpeg díky parametru pipe:1. V případě použití mého jednoduchého parseru se tedy musí zajistit, aby "něco" z adresy ve staženém playlistu ten stream do Tvheadend posílalo. Napadá mě, vložit tam např. wget. U něj to zpoždění možná nebude tak velké jako u ffmpeg. Ale je to jen má laická úvaha, tady by asi mohl pomoci někdo zkušenější. Přesto to vyzkouším. Ale až zase večer, běžím do práce.
EDIT2nd: Tak jsem ještě rychle vyzkoušel wget. wget -qO - <adresa staženého streamu> by asi mohlo fungovat.
EDIT3rd: Ještě mě napadlo, že by bylo možné to volání wget zaintegrovat do parseru a neřešit vůbec playlist. Ten bych nechal beze změny tak, jak ho stáhneš od providera.
EDIT4th: Ještě jsem zapomněl na odkaz diskuse, kde se řešilo zpoždění při použití ffmpeg. Najdeš to zde Tvheadend a internetová rádia, hned na první stránce, příspěvky od @marhycz a @mobilemanic. Ale už tenkrát jsme myslím usoudili, že to zkrácení náběhu streamu, které se podaří optimalizací běhu ffmpeg, není nijak významné. Prostě jakmile použiješ ffmpeg, musíš počítat s nějakou tou sekundou navíc. A je jasné, že ten parser tomu taky něco přidá.