[iptv] m3u, stream, radio Erweiterung

Quote from davie2000

Es gibt keine Parameter-Kombi, die für ca. 90% aller Sender/Einträge ein gutes/optimales Ergebnis liefert?

Sagen wir mal so. Ich bin mit den aktuellen Parametern zufrieden und sehe - für mich - keine Notwendigkeit etwas ändern zu müssen. Mit FFmpeg für Video und vlc für Radio habe ich bisher keine Probleme gehabt. Aber es gibt 2 Meldungen, bei denen eine Änderung notwendig sein könnte:

1. fps ist nicht 25/50, sondern 30 oder etwas anderes. Das Video hat dann Mikroruckler

2. Für vlc und Video gab es die Notwendigkeit (siehe #136) die Default Parameter zu ändern, damit es funktioniert.

Den Vorschlag von MarkusE würde ich gerne erweitern um sowohl eine einfache Einstellung, als auch komplizierte Scripte zu ermöglichen.

Idee (zur Diskussion):

1. Eine Ini-Datei mit der Channel Id als Section

2. Als Key/Value 2 Möglichkeiten:

a) Der komplette Aufruf für den Kanal, der selbst erstellt werden müsste. Als Platzhalter würden dann die Video- und Audio-URL angegeben werden.
b) Ein Script, das aufgerufen wird mit dem Eintrag aus der channels.conf + Video-/Audio-URL und Ausgabe wäre der komplette Aufruf. Dazu könnte man ein Script-Skelett erstellen, daß verschiedene Werte schon bestimmt. Vorteil wäre, das man auf Audio-Channels verzichten kann oder den Transcode genauso machen kann, wie man will.

Sollte die Channel Id nicht in der ini Datei zu finden sein, dann wird der aktuelle Aufruf verwendet und damit wäre das Ganze abwärtskompatibel und man könnte für bestimmte Kanäle (falls erforderlich) eben eine Sonderbehandlung vorsehen.

Beispiele:

[I-1-34-21-21]
script=/pfad/zum/script/mach_was_tolles.sh

[I-1-17-7-7]
transcode3=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} .. -i {A2} ... -i {A3} -codec copy -map 0:v -map 1:a ... usw.
transcode2=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} .. -i {A2} ... -codec copy -map 0:v -map 1:a ... usw.
transcode1=ffmpeg -hide_banner -re -y... -i {V} .. -i {A1} ... -codec copy -map 0:v -map 1:a ... usw.

Der erste Eintrag verweist auf ein Script und bekommt die Parameter:

<Eintrag aus der channels.conf> <video-url> <audio-url 1> <audio-url 2> <audio-url 3>

Der zweite Eintrag ist eine stark verkürzte Version aus #138 und enthält die Platzhalter für die Video-/Audio Urls. Wobei es 3 Versionen gibt (jeweils für die Anzahl der Audio-URL (1,2 oder 3)).

Das Ganze würde natürlich für vlc ähnlich aussehen.

Vorteile:

Es gibt sowohl eine Möglichkeit einer einfachen Konfiguration oder eben die Möglichkeit ein Script anzuwerfen, in dem so alles gemacht werden kann.

Sollte die ini-Datei nicht vorhanden sein, oder der Eintrag für die channel-id fehlen, würde der Bestandscode greifen. Niemand wird also dazu genötigt eine weitere Konfiguration zu erstellen. Es besteht aber die Möglichkeit auf bestimmte Kanäle flexibler reagieren zu können.

Nachteile:

Entwicklungsaufwand entsteht.

Dokumentationsaufwand entsteht.

Quote from r371769

Gibt es die Samples für die channels.conf noch?

Ja. Aber ich sie ausgelagert. Siehe hier.

Quote from jojo61

Ist es denkbar das stream-adaptiv plugin von Kodi für das Streamen von IPTV zu nutzen.

Die Idee hatte ich auch schon, aber mehr existiert dazu bisher nicht. Patches werden aber gerne angenommen

Es ist im Moment alles eine Frage des Zeitmanagements.

Aber wenn wir schon dabei sind (ähnliches Thema). Ist es möglich das Ausgabedevice zu erweitern (nicht VDR-konform, per service, per irgendwas, per ... egal) um die Möglichkeit bereits decodierte Daten abzuspielen?.

Also ich habe z.B. eine Bildfolge mit PTS, Audio Daten mit PTS und alles raw und nicht in irgendeiner Variante encodiert.

Quote from jojo61

Ich kann dir natürlich Funktionen bereitstellen die dir direkten Zugriff aus das Plugin geben. Nur verstehe ich im Moment nicht was du mit uncodierten Daten meinst.

Ich hole mal etwas aus. Das Problem dürfte mit inputstream-adaptiv und dem web Plugin nahezu identisch sein.

Das alte HbbTV hat folgendes gemacht:

- Die aktuelle Anzeige des Browser gelesen (ARGB oder BGRA unkompromiert), PTS wurde auf time(NULL) gesetzt.

- Parallel gab es Audio Daten (PCM) mit einer eigenen PTS

- Das ARGB Image + die Audiodaten wurde per libav in einen TS Stream gewandelt und an den VDR gesendet und abgespielt.

- Das OSD wurde dabei mit den TS stream encoded.

Hier ist das Problem, daß die Latenz des OSD unglaublich hoch war. Das wird auch klar durch den encode/transfer/decode + Buffer handling im Output device. Ich habe mal das Video im OSD darstellen lassen (ohne Audio) und es war flüssig, aber fühlte sich komplett falsch an, weil das OSD dafür nun gar nicht gedacht ist.

Das neue web Plugin macht folgendes:

- OSD wird wirklich im VDR OSD dargestellt, unabhängig vom Video

- Die Video URL geht an den Transcoder, wird nach TS transcodiert und an den VDR gesendet, der dieses dann im Player abspielt.

Die Latenz des OSD ist durch die Trennung OSD/Video sehr gut.

Meine Vermutung mit inputstream-adaptive sieht ähnlich aus. Der Videostream wird encoded und als ARGB oder BGRA und der Audiostream encoded als PCM in Kodi bereit- und dargestellt.

DRM (bzw. nur widevine) hatte ich im damaligen Browser eingebunden und es wurde unterstützt. Der heutige Browser würde eine andere Version von cef benötigen, da die offizielle Version, die heruntergeladen werden kann viele Codecs nicht unterstützt, z.B. auch nicht aac. Wie inputstream-adaptive widevine (und andere) unterstützt, müsste man auch untersuchen.

Die Gundidee: Browser erweitern, cef in einer anderen Version bereitstellen, inputstream-adaptiv untersuchen und möglicherweise in iptv unterbringen. Das sind aber alles nur grobe Ideen. Alleine das kompilieren von z.B. VDR*ELEC ist rasend schnell im Vergleich zur Kompilierung von cef. Eine Integration in den Browser würde dann z.B. auch den remotetranscoder überflüssig machen, weil alles im Browser abgespielt würde.

Damit läuft beides auf dasselbe Problem hinaus: Unencoded ARGB/Unendoced PCM im Ausgabedevice unterstützen.

Und da die offiziellen Schnittstellen im VDR das nicht hergeben, wäre eine spezielle Version für die Ausgabedevices notwendig. Und aktuell nutze ich produktiv fast nur softhdodroid

Quote from jojo61

Die konvertiere ich dann zu mpegts und sende sie an das iptv plugin (so wie ffmpeg und vlc das auch machen). Allerdings gehen auf der UDP Verbindung anscheinend immer mal wieder Daten verloren. Kann ich das irgendwie auf TCP umstellen im iptv plugin oder muss ich da erst etwas umprogrammieren ?

Ich habe es im anderen Thread von deinen Erfolgen gelesen und sie sind klasse.

Das iptv Plugin kennt dazu aktuell nur das Protocol UDP (cIptvProtocolUdp) und kein TCP. Allerdings ist die Klasse wohl in der Lage auch TCP zu verwenden

bool cIptvSocket::OpenSocket(const int portP, const bool isUdpP)

Ich habe es mir noch nicht genauer angeschaut. Muss dein Script geeignet gestartet werden und dann sollen die Daten per TCP an das Plugin gesendet werden? Hmm... Ich muss da genauer drauf schauen.

Das Plugin habe ich erweitert um eine sehr flexible Möglichkeit, den vlc oder FFmpeg Aufruf zu erzeugen.

Es kann neben H=F (für FFmpeg), H=V (für vlc) auch H=E (für expert) verwendet werden. Der Expertenmodus ruft ein python Script auf, dessen einzige Aufgabe es ist, anhand der Parameter (0/1 für Radio/Video und einem Json, daß die Daten enthält: wie urls, pids, Kanalname,...) eine vollständige Kommandozeile für FFmpeg oder vlc zu erzeugen.

Das beigelegte Script (https://github.com/Zabrimus/vdr-p…dline-expert.py) erzeugt (fast) nahezu den identischen Aufruf, der auch im C++ Code mit H=V oder H=F erzeugt wird.

Man kann das bestehende Script auch über den Haufen werfen und z.B. im Script den Kanalnamen abfragen und die Kommandozeile speziell für diesen Kanal anders erzeugen lassen: Z.B. fps setzen, Audio transcodieren oder was auch immer. Mit python sollte man allerdings schon einmal Kontakt gehabt haben.

Den Ideen sind keine Grenzen gesetzt.

Zur Sicherheit sei angemerkt: Das Script (und eigentlich auch die channels.conf und svdrp) sollten nur bzgl. der Schreibrechte eingeschränkt werden, weil ansonsten Schindluder betrieben werden kann, wie man sich denken kann.