01.9.2018, 21:39
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 :-)
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)
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.
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
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
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