Gibt es eine Alternative zu DVB-C welche mit VDR funktioniert?

Okay, jetzt habe ich zum ersten Mal ein gutes Bild und Ton!  

Wichtig ist, dass man diese Werte:

sudo sysctl -w net.core.rmem_max=2097152
sudo sysctl -w net.core.rmem_default=2097152
sudo sysctl -w net.core.wmem_max=2097152
sudo sysctl -w net.core.wmem_default=2097152

immer neu eingeben muss. Ich dachte, dass diese permanent gespeichert werden.

Deshalb hat es beim ersten Mal nicht geklappt, weil ich danach einen REBOOT gemacht hatte.

Also, wenn ich diese Werte nach einem Neustart eingebe, dann gibt es ein einwandfreies Bild+Ton mit ffmpeg!

Das ist schon erstmal sehr gut. Auf die Schnelle habe ich ein kleines "systemd-service" gemacht, was nach jedem Start ausgeführt wird.

Das "/etc/rclocal" gibt es glaub ich bei Ubuntu gar nicht mehr, deshalb der Weg über ein "systemd-service"..

Selten gibt es noch einen kurzes Stoppen des Streams für 1...2 Sekunden, aber im allgemeinen läuft es flüssig.

Das Umschalten zwischen den Streams dauert ca. 4...8 Sekunden. ist noch etwas lang, aber noch machbar.

Was noch nicht geht ist das Umschalten der beiden Audio-Spuren.

Ich werde heute Abend noch etwas testen und mal schauen, was so noch geht.

Die Änderung im Script ffmpeg2iptv:

trap 'kill -SIGKILL ${PID} 2>/dev/null; exit' INT TERM KILL HUP

habe ich mal eingebaut, aber es hatte auch ohne diese Änderung funktioniert.

Zitat

Das Umschalten zwischen den Streams dauert ca. 4...8 Sekunden

Great!

you can decrease analyseduration and probesize values just until you lose picture and/or sound.

It may help a bit to increase zapping speed.

Add following lines in /etc/sysctl.conf

# VDR UDP streaming:
net.core.rmem_max=2097152
net.core.rmem_default=2097152
net.core.wmem_max=2097152
net.core.wmem_default=2097152

if you want them to load permanent on boot

Yes, a fifo would maybe alsa work. But I never tried it.

Eventually this whole exercise with ffmpeg and the unique SID, TID and other pids, was done to make vdr record the stream!

Zitat von Paulaner

Ich habe das ffmpeg2iptv-Script von hier #151 übernommen, aber es war prinzipiell genauso wie der letzte Stand den ich schon hatte.

Bei mir spielt es keine Rolle, ob ich in dem Script speziellen Part einmal so:

"udp://$HOST:$PORT?pkt_size=1316\&buffer_size=65536\&overrun_nonfatal=1"

oder auch ohne Hochkomma (oder wie die Dinger genannt werden):

udp://$HOST:$PORT?pkt_size=1316\&buffer_size=65536\&overrun_nonfatal=1

oder auch ohne Backslash:

udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1

schreibe.

Alles anzeigen

Ups, da hatte ich die \ übersehen.

Doppelt quoten mit \ und " mach natürlich keinen Sinn.

Einmal ist aber bei mir zwingend notwendig, damit die Optionen auch bei ffmpeg ankommen.

"udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1"

(Ohne die " wenden die Teile nach den & als eigene Befehle ausgeführt und da die nicht ausführbar sind bewirken sie natürlich nichts.)

Die Variante mit \ könnte evtl. auch gehen, habe ich aber nicht probiert

Zitat von Paulaner

Ich habe jetzt keine Ahnung von den vielen Funktionen in ffmpeg, aber wie ich das deute, geht es doch hier um die Sortierung der Audio-Video-Streams und anschließender Umwandling in TS-Streams.

Die -map wählen die Streams aus.

Selecting streams with the -map option

Zitat von Paulaner

Wäre das mit dieser "pipe" nicht etwas das man auch für unsere Umwandlung nutzen kann?

Prinzipiell kann das iptv-plugin auch aus Pipes lesen.

Anscheinend wird aber in Verbindung mit einem externen Skript immer eine UDP-Verbindung erwartet.

Das müsste man sich als nächstes mal näher ansehen.

Die ffmpeg Kommandos sehen eigentlich recht brauchbar aus und könnten so auch mit dem iptv-plugin zusammen funktionieren.

Zitat von Paulaner

Das Umschalten zwischen den Streams dauert ca. 4...8 Sekunden. ist noch etwas lang, aber noch machbar.

Das ist ja schon besser.

3-4 Sekunden hätte ich auch erwartet, es ist halt ein Puffer zu viel drin.

Zitat von Paulaner

Was noch nicht geht ist das Umschalten der beiden Audio-Spuren.

Kein Wunder, ffmpeg wählt standardmäßig nur eine Audio-Spur, das begrenzt die Auswahl fürs Umschalten deutlich .

Default Behavior: Only 1 stream per type will be selected.

Zitat von don-baba

Wäre es nicht einfacher die Umwandlung und streamerstellung über tvheadend und tele-dings direkt in eine Fifo Datei leiten zu lassen und die Datei dann mit dem iptv plugin abzuspielen?

Je mehr unterschiedliche Komonenten der Stream durchläuft, desto schwieriger wird es eine anständige Unschaltzeit hin zu bekommen. Die Streams will man ja auch nicht die ganze Zeit laufen lassen und in /dev/null entsorgen.

Am iptv-plugin fehlt nicht viel, damit die von der "tele-dings" gelieferten ffmpg-Befehle funktionieren.

Streammässig müsste alles schon da sein, was fehlt ist "nur" die Unterstützung für die m3u8-Playlists.

Irgendwie muss man das automatisieren können, die Angaben sollten reichen einen für den VDR gültigen Kanal zu erzeugen.

Dazu gibt es bei diesen Playlists nur 2 Container-Formate mp4 und mpeg2ts. Letzteres ist vom VDR sowieso unterstützt.

Bei mp4 könnte man sich an KODI ran hängen, die bekommen von ffmpeg via pipe auch mpeg2ts serviert. Und da waren die Umschaltzeiten bislang ja mit Abstand die besten, wenn ich mich nicht täusche.

Problem ist momentan aber erstmal das Mapping der Streams mit ffmpeg.

Was bei telerising gut funktioniert, scheitert zB. beim ZDF grandios, weil die Streams anders liegen.

Mit -map 0 einfach alle Streams zu wählen funktioniert nicht, da man mehrere Video-Streams erhält, was für Chaos sorgt.

Für je eine Audio und Video-Stream scheint das Default Verhalten von ffmpeg ganz gut zu gehen.

Wenn man aber mehr als einen Audio-Stream möchte, muss man vorher wissen, welchen Video und welche Audio-Streams man haben will.

Einen Vorteil hat das statische Mapping aber, man kann die Zeit fürs proben sparen (wenn ffmpeg da mit macht).

Bei telerising scheinen alle Kanäle zum Glück die gleichen Einstellungen zu haben.

Ich habe jetzt mal einen neuen ffmpeg-Aufruf aus unserem und dem aus der Playlist zusammen gebastelt:

#!/bin/bash


LC_NUMERIC=C ffmpeg \
-loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Die zweite Audio-PID habe ich mal fest auf "345" gesetzt.
Da muss man sich wirklich mal was besseres überlegen, aber für einen Test bezüglich der Umschaltzeiten sollte es gehen.

Falls es Probleme gibt das -streamid 2:345 einfach mal entfernen. Ich bin nicht sicher, was passiert, wenn der Stream gar nicht existiert.

Zitat von SHF

Einmal ist aber bei mir zwingend notwendig, damit die Optionen auch bei ffmpeg ankommen.

"udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1"

Habe ich jetzt auch so, also inklusive der " bei mir drin.

Ohne die " wurde der nachfolgende Befehl &>/tmp/ffmpeg.log nicht ausgeführt und alle Meldungen landeten in der syslog.

Also "mit" ist hier besser!

Ich habe mal Deinen Vorschlag für den ffmpeg-Aufruf auf die Schnelle getestet, aber das läuft so nicht.

Da kommt sofort eine Fehlermeldung, dass der Befehl -loglevel nicht kennt,

wenn ich den auskommentiere kommt dann die nächste Fehlermeldung -ignore_unknown ist unbekannt.

Ich habe jetzt leider erstmal keine Zeit mehr und kann wahrscheinlich erst heute Abend weiter testen!

Für mich sieht es so aus, als ob da was mit dem ersten Zeilenumbruch nicht stimmt.

Evtl. mal so probieren:

 LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Ich habe den aktualisierten ffmpeg-Aufruf von SHF getestet und heute ein ganz anderes Ergebnis wie gestern erhalten.

Es gibt kein Bild, aber dafür ist jetzt zumindest eine Audio-Spur (die AAC-Stereo-Spur) zu hören.

Auf die 2. Audiospur kann ich zwar umschalten, aber es gibt keinen Ton. Ich habe hier auch den richtigen PID-Wert für die 2. Audiospur (eAC3) = 257 eingegeben, aber auch da kein Ton.

Es gibt aber auch keine Fehlermeldungen bzw. überhaupt keinerlei Meldungen im ffmpeg.log

Vielleicht hatte ich beim ersten Mal auch beim kopieren des ffmpeg-Aufruf einen Fehler gemacht und deshalb die komischen Fehlermeldungen erhalten.

Zitat von Paulaner

Es gibt aber auch keine Fehlermeldungen bzw. überhaupt keinerlei Meldungen im ffmpeg.log

Das -loglevel fatal unterdrückt alle Meldungen, die nicht zum Abbruch führen.

Da in unserem Fall unüblich viel unnötige Meldungen kommen, macht das schon Sinn. Bei der Menge könnte die Größe der Logfile nach ein paar Stunden schon zum Problem werden.

Zitat von Paulaner

Es gibt kein Bild, aber dafür ist jetzt zumindest eine Audio-Spur (die AAC-Stereo-Spur) zu hören.

Auf die 2. Audiospur kann ich zwar umschalten, aber es gibt keinen Ton. Ich habe hier auch den richtigen PID-Wert für die 2. Audiospur (eAC3) = 257 eingegeben, aber auch da kein Ton.

Da ist wohl was mit dem Mapping nicht in Ordnung und das habe ich übernommen.

Eigentlich ist das Mapping simpel, es werden nur die ersten 5 Streams selektiert (3-5 nur wenn vorhanden ?).

Jedes -map wählt einen, die erste 0 steht für die erste Quelle (wir haben nur die eine), die zweite Ziffer für den Stream (dabei ist 0 der Erste, 1 der Zweite usw.).

Die PIDs werden mit -streamid zugewiesen, wobei die erste Zahl dem stream des jeweiligen -map entspricht (0 erstes -map, 1 zweites, ...).

Aktuell wird also dem ersten Stream die VideoPID, dem Zweiten die AudioPID und dem Dritten die PID 345 zugewiesen. Bei den weiteren Streams greift dann irgend ein default Mechanismus.

Ich mappe jetzt mal den ersten Videostream an die erste Stelle und dann folgend alle Audiostreams, vielleicht geht das besser.

 LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:2 -map 0:a -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Unter Umständen ist das mapping nur mit de Nummer schneller, da der Stream zumindest theoretisch vorher nicht analysiert werden muss.

Wenn das Mapping aus Beitrag #158 stimmt, müsste es auch so gehen:

 LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:2 -map 0:0 -map 0:1 -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Interessant wäre, ob sich das auf die Umschaltzeit auswirkt.

AC3 sollte jeweils auf PID 345 liegen.

Heute habe ich mal wieder etwas Zeit zum Testen gehabt.

Beide Versionen funktionieren nun auch mit der 2. Audiospur!

Super das es nun prinzipiell funktioniert.  

Allerdings muss man dazu den richtigen Wert für die 2. Audio-PID = 257 verwenden, wie dieser auch bereits in der VDR-channels.conf eingetragen ist.

Mit dem vorgeschlagenen AC3 sollte jeweils auf PID 345 liegen. klappt es nicht. Da kommt kein Ton.

Hier muss man also noch eine Möglichkeit finden, um die PID der 2. Audiospur automatisch zu ermitteln.

Die Umschaltgeschwindigkeiten unterscheiden sich zwischen beiden Versionen praktisch nicht, sie betragen: 6 ... 12 Sekunden.

Wobei das Bild meist schon nach 5 Sek. dann nochmals kurz weg ist, weil vermutlich das Audio noch nicht da ist, denn der Ton braucht dann meist noch wesentlich länger.

Im Vergleich dazu ist bei Verwendung des Scripts  vlc2iptv die Umschaltgeschwindigkeit gefühlt etwas kürzer: 5...10 Sekunden.

Bei KODI sind allerdings die Umschaltgeschwindigkeiten ähnlich hoch: 4 ... 8 Sekunden.

Allerdings gibt es bei dem KODI-PVR-HTS-Addon die Möglichkeiten ein "Voraussagendes Tuning" einzustellen. Da wird vorausschauend schon der nächste Stream aktiviert, so dass dan das Umschalten in weniger als 1/2 Sekunde erfolgt. Das macht sich vor allem beim Zappen durch die Streams deutlich bemerkbar.

Zitat von Paulaner

Hier muss man also noch eine Möglichkeit finden, um die PID der 2. Audiospur automatisch zu ermitteln.

Ich setze die eigentlich auf den Wert, zumindest was das der Plan. -streamid 2:345 (zweite Zeile ganz rechts)

Anscheinend klappt das aber irgendwie nicht.

Ich muss mal schauen, ob ich den Fehler irgendwie reproduziert bekommen. Der Livestream vom ZDF hat leider kein AC3.

Dass die Umschaltzeiten ähnlich liegen, wird daran liegen, dass man einen gewissen Puffer brauch.

Bei ffmpeg kann man da aber noch was optimieren, wie carel schon vorgeschlagen hat:

Zitat von carel

you can decrease analyseduration and probesize values just until you lose picture and/or sound.

It may help a bit to increase zapping speed.

Der entsprechende ffmpeg Befehl lautet dann in etwa:

 LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-probesize 1000000 -analyzeduration 1000000 \
-ignore_unknown -map 0:2 -map 0:0 -map 0:1 -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:345 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Die Werte entsprechen momentan 1MB (1000000Bytes) und 1 Sekunde (1000000µS).

Das sollte eigentlich reichen um den Stream zu erkennen.

Meine Tests mit ffprobe (das bricht nach der Streamerkennung automatisch ab) zeigen leider nicht so viel Resonanz auf diese Optionen, wie ich gerne hätte und ich habe schon einiges versucht:

time ffprobe -avioflags direct -fflags discardcorrupt -fflags fastseek -fflags nobuffer -flags low_delay -probesize 32 -analyzeduration 0 -fpsprobesize 0 -max_probe_packets 100 https://zdf-hls-15.akamaized.net/hls/live/2016498/de/high/master.m3u8

(Die ganzen Optionen kann man auch mit ffmpeg versuchen, wenn man will.)

Immerhin kommt man mit den obrigen Werten von -probesize und -analyzeduration von 8-9s auf 5,5-6s runter. Noch kleinere Werte bringen bei mir keine wirkliche weitere Verbesserung.

time ffprobe https://zdf-hls-15.akamaized.net/hls/live/2016498/de/high/master.m3u8

time ffprobe -probesize 1000000 -analyzeduration 1000000 https://zdf-hls-15.akamaized.net/hls/live/2016498/de/high/master.m3u8

Wenn das so auch mit dem iptv-Plugin klappt, sollte aber zumindest die Geschwindigkeit von VLC erreicht sein, hoffe ich.

(Wer mutig ist, kann es natürlich auch mal mit den Minimalwerten -probesize 32 -analyzeduration 0 und dem Plugin versuchen.)

Zitat von Paulaner

Allerdings gibt es bei dem KODI-PVR-HTS-Addon die Möglichkeiten ein "Voraussagendes Tuning" einzustellen. Da wird vorausschauend schon der nächste Stream aktiviert, so dass dan das Umschalten in weniger als 1/2 Sekunde erfolgt. Das macht sich vor allem beim Zappen durch die Streams deutlich bemerkbar.

Das wäre aber wohl besser im VDR aufgehoben, der weiss welche Devices belegt oder frei sind.

Ausserdem würden dann auch User mit anderen Empfangswegen profitieren. Bei SAT->IP könnte es zB. auch was bringen.

Zitat von SHF

Ich setze die eigentlich auf den Wert, zumindest was das der Plan. -streamid 2:345 (zweite Zeile ganz rechts)

Anscheinend klappt das aber irgendwie nicht.

Ich habe gedacht, die 345 wäre einfach so ein Platzhalter von dir gewesen, denn wo soll den dieser Wert herkommen?

TVheadend zeigt ja in seinem Status eine PID list an:  0, 1, 16, 17, 256, 257, 258, 4096  und diese ist bei allen Streams gleich.

Durch probieren habe ich einige der PIDs ermitteln können und in die Einträge meiner channels.conf eingefügt:

VPID = 258

APID = 256

DPID = 257

Für die anderen PID-Werte habe ich keine Zugehörigkeit gefunden.

Ein Eintrag aus meiner channels.conf sieht dann so aus:

 Das Erste HD;IPTV:1010:S=0|P=1|F=EXT|U=ffmpeg2iptv_raw|A=1:I:0:258=27:256=@15;257=@106:0:0:101:65281:301:0 

Der ffmpeg-Aufruf sieht z.Z. bei mir so aus:

LC_NUMERIC=C ffmpeg -loglevel fatal -re -i "${URL}${BUFFER}" \
-ignore_unknown -map 0:2 -map 0:0 -map 0:1 -map 0:3? -map 0:4? -c copy \
-streamid 0:$VPID -streamid 1:$APID -streamid 2:257 \
-f mpegts -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
-mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Mit den Werten für PROBESIZE und ANALYZEDURATION werde ich bei Gelegenheit noch etwas probieren und berichten, ob es was gebracht hat.

Zitat von Paulaner

Allerdings gibt es bei dem KODI-PVR-HTS-Addon die Möglichkeiten ein "Voraussagendes Tuning" einzustellen.

Die Möglichkeit mit dem "Voraussagenden Tuning" bei dem KODI-PVR-HTS-Addon habe ich nur erwähnt, um zu erklären warum teilweise in KODI die Umschaltzeiten <1Sek. sind.

Zitat von Paulaner

Ich habe gedacht, die 345 wäre einfach so ein Platzhalter von dir gewesen, denn wo soll den dieser Wert herkommen?

Na genau von hier , so war es zumindest gedacht.

ffmpeg baut den MPEG-TS-Stream neu zusammen, da kann man sich die PIDs aussuchen. Die müssen lediglich mit denen in der channels.conf zusammen passen, sonst gibt es keinen Empfang.

Die 4096 steht so in dem ffmpeg-Befehl selber.

Die anderen werden irgendwie aus der channels.conf extrahiert (Zeile 35-45). Du müsstest also bei der channels.conf eintragen könne, was Du willst und es passt hinterher immer.

Mit den Thema hatte ich mich bislang aber erst am Rande beschäftigt, weil das mit der ffmpeg-Problematik nichts zu tun hat.

Bislang ist mir nur aufgefallen, dass das so nicht ideal ist, da Änderungen u.U. nicht sofort in die Datei geschrieben werden.

Ich habe übrigens eine nette Liste der Offizielle ÖR-Livestreams gefunden.

Damit kann man IPTV auch ohne Abo an testen, bzw. taugt das auch als Alternative, falls was ausfällt.

Die alle per Hand zu importieren habe ich aber keine Lust, zumal ich befürchte, dass die Audiostreams überall unterschiedlich sind. Mal schauen, ob ich es am WE schaffe da ein Skript zu basteln.

Zitat von Paulaner

Die Möglichkeit mit dem "Voraussagenden Tuning" bei dem KODI-PVR-HTS-Addon habe ich nur erwähnt, um zu erklären warum teilweise in KODI die Umschaltzeiten <1Sek. sind.

Das hatte ich schon so interpretiert.

Die Idee finde ich aber generell nicht schlecht.

Das könnte eventuell auch im VDR was bringen, zumindest bei einigen Empfangsarten. Solange man freie Input-Devices hat, könnte man sie für sowas ja sinnvoll nutzen.

Ich habe noch etwas rumprobiert mit den Werten von PROBESIZE und ANALYZEDURATION aber eine wesentliche Verkürzung der Umschaltzeiten konnte ich nicht erreichen. Auch nach dem ich beide Werte ganz aus dem ffmpeg-Befehl gelöscht habe, war keine große Veränderung erkennbar.

Ich habe die ffmpeg-commandline noch etwas angepasst und das Stream-Mapping aus der ///pipe ... von Telerising übernommen, wie es an TvHeadend übergeben wird. Hier mal am Beispiel für den Stream von "Das Erste HD", wie es von der telerising.api ausgegeben wird:

pipe:///usr/bin/ffmpeg -loglevel fatal -re -i "http://192.168.1.3:5000/api/zde/live/ard" -ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c:a:0 copy -c:a:1 copy -c:v copy -c:s copy -f mpegts -metadata service_name="Das Erste HD" pipe:1

Und so sieht die ffmpeg-commandline momentan bei mir aus:

LC_NUMERIC=C ffmpeg -loglevel warning -re -i "${URL}" \
  -ignore_unknown -map 0:0 -map 0:1 -map 0:2? -map 0:3? -map 0:4? -c:a:0 copy -c:a:1 copy -c:v copy -c:s copy \
  -f mpegts -map_metadata -1 -mpegts_transport_stream_id $TID -mpegts_pmt_start_pid 4096 -mpegts_service_id $SID \
  -mpegts_original_network_id $NID "udp://$HOST:$PORT?pkt_size=1316&buffer_size=65536&overrun_nonfatal=1" &>/tmp/ffmpeg.log &

Die Umschaltzeiten zwischen den Streams sind bei mir ca. 3 ... 6 Sekunden bis Bild+Ton da sind, meistens sind es ca. 4 Sekunden. damit kann ich leben, denn ich bin nicht der Powerzapper, sondern schaue mir schon bewusst eine Sendung an.

Aber dann gibt es ab und zu beim Zappen einen Stream, wo es dann auch mal wesentlich länger dauert, bzw. der Stream ganz stoppt und man muss dann 1x hin- und herschalten, damit wieder ein Bild kommt.

Aufgefallen ist mir noch, dass meist zuerst das Bild nach ca. 2 Sek. da ist und dann dauert es noch 1 ... 3 Sek. ehe dann auch der Ton richtig da ist.

Mit dem Audio-Ton gibt es bei mir noch die meisten Probleme. Im syslog hatte ich sehr oft beim Umschalten diese Meldung bzgl. Audio:

yavdr vdr: [1256] switching to channel 113 I-65281-313-113 (3sat HD ffmpeg)
yavdr api[1405]: 192.168.1.3 - - [21/Apr/2024 15:13:23] "GET /api/zde/live/3sat HTTP/1.1" 200 -
yavdr vdr: audio: audio started and underrun, increase AudioBufferTime?!
yavdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'

Manchmal kam es dann sogar zu sehr vielen Bild- und Tonfehlern bis zum Bildausfall und dann waren es diese Meldung im syslog:

yavdr vdr: message repeated 592 times: [ audio: audio started and underrun, increase AudioBufferTime?!]

Ich habe daraufhin dann die "AudioBufferTime" im softhddevice-Plugin auf dem maximalen Wert von 1000ms erhöht.

Nun kommen diese obigen Meldungen nur noch selten und der Stream läuft fast immer sauber durch.

Ob es nun allgemeine Fehler im Stream sind, oder vermutlich doch eher ist das das Umkodieren der Audiostreams im ffmpeg nicht optimal konfiguriert. Denn bei der Android-App von Zattoo kommt das nicht vor. Da wird immer nach 2...3 Sekunden zum nächsten Stream geschaltet.

Aber seit dem ich die softhddevice.AudioBufferTime = 1000 gesetzt habe sind die Meldungen wesentlich weniger geworden.

Nur beim Umschalten auf einen anderen IPTV-Stream kommt fast immer noch diese Meldung, also ist das mit dem Audio noch nicht ganz okay.

yavdr vdr: audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'

Wenn ich hingegen zwischen den DVB-C Kanälen umschalte, dann habe ich diese Meldung nicht.

Was mir jetzt noch fehlt ist das zugehörige EPG für die IPTV-Streams.

Für TVheadend habe ich dazu bereits eine passende xmltv-Datei. Die müsste man doch eigentlich auch für die IPTV-Streams im VDR verwenden können.

Nur weiß ich momentan noch nicht, wie ich diese mit den IPTV-Streams im VDR verknüpfen kann/muss. Das ist für mich noch absolutes Neuland!

Das werde ich dann aber erst in 2 Wochen in Angriff nehmen können, denn in der kommenden Woche bin ich aber im Urlaub und werde in den Bergen wandern gehen. Zum Glück nicht hier in Deutschland, sondern es geht auf die Kanaren, da ist das Wetter doch wesentlich angenehmer!

Vielleicht müsste mal jemand die Ärmel hochkrempeln und das direkt als Plugin umsetzen, damit das Starten/Stoppen von Scripts usw. wegfällt. Ich kann mir vorstellen, dass da auch noch die ein oder andere Sekunde auf der Strecke bleiben könnte. Wenn man mal eben eine Webcam o.ä. einbinden will, ist so ein Script ganz wunderbar, aber wenn es quasi um die Hauptquelle für TV geht, lohnt es sich ja vielleicht.

Zitat von mini73

Vielleicht müsste mal jemand die Ärmel hochkrempeln und das direkt als Plugin umsetzen,

Ja das wäre sicherlich das Optimale!

In KODI wird dies ja so gemacht, dass für verschiedene IPTV-Lösungen es entsprechende PVR-Addons gibt.

Denn da könnten gleich noch solche Dinge wie EPG einbauen, oder auch dieses "Vorausschauende Tuning", wenn mehrere parallele Streams zur Verfügung stehen.

Zitat von Paulaner

audio: audio started and underrun, increase AudioBufferTime?!

Das bedeutet, dass der Ton schon angelaufen ist, aber dann das Audio nicht schnell genug rein kommt.

Vergrößern der Puffers hilft, wenn das Audio ungleichmäßig rein kommt.

Es gibt aber auch Fehler, wo das nicht hilft.

Zitat von Paulaner

audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)'

Ist nicht unbedingt eine Fehlermeldung, eher ein Hinweis, deswegen das Fragezeichen. Wenn sonst alles gut ist, kannst du das ignorieren.

Du könntest als Experiment AudioBufferTime sogar noch viel größer wählen (notfalls von Hand in setup.conf softhddevice.AudioBufferTime hochsetzen), und gucken, ob deine Fehler dann ganz weg sind.

Der Preis dafür ist aber längere Umschaltzeit.

Zitat von Paulaner

Ich habe noch etwas rumprobiert mit den Werten von PROBESIZE und ANALYZEDURATION aber eine wesentliche Verkürzung der Umschaltzeiten konnte ich nicht erreichen. Auch nach dem ich beide Werte ganz aus dem ffmpeg-Befehl gelöscht habe, war keine große Veränderung erkennbar.

Bei meinen Tests mit ffprobe brachte es was.

Es kann aber sein, dass die Werte bei festem Stream-Mapping irrelevant sind.

Zitat von Paulaner

Ich habe die ffmpeg-commandline noch etwas angepasst und das Stream-Mapping aus der ///pipe ... von Telerising übernommen, wie es an TvHeadend übergeben wird.

Einen Unterschied sollte es eigentlich nicht machen.

Deren -copy Optionen pro Stream sollten mit einem globalen -copy für alles identisch sein (letzteres ist aber übersichtlicher ;-)).

Zitat von Paulaner

Die Umschaltzeiten zwischen den Streams sind bei mir ca. 3 ... 6 Sekunden bis Bild+Ton da sind, meistens sind es ca. 4 Sekunden.

Das ist aber schon mal schneller als alles, was ich bei meinen ffprobe Tests hin bekommen habe.

Unter 5,5 Sekunden war da nie möglich.

Zitat von Paulaner

Aufgefallen ist mir noch, dass meist zuerst das Bild nach ca. 2 Sek. da ist und dann dauert es noch 1 ... 3 Sek. ehe dann auch der Ton richtig da ist.

Das kann auch irgendwie mit der Synchronisierung der Streams zusammen hängen.

Es ist ja nicht gesagt, dass die ersten Pakete schon zusammen passende Audio und Video Daten enthalten.

carel hatte noch diese Optionen in seinem Skript:

FLUSH_PACKETS="-flush_packets -1" # 1: flush immediately, reduce latency, 0: increases throughput, -1: automatic

DISCARD_CORRUPT_PACKAGES="-fflags +discardcorrupt"

Das könnte hier was bringen, indem es ungültige Pakete verwirft.

Und dann kann es natürlich auch irgendwie am Ausgabeplugin hängen.

Zitat von Paulaner

Ob es nun allgemeine Fehler im Stream sind, oder vermutlich doch eher ist das das Umkodieren der Audiostreams im ffmpeg nicht optimal konfiguriert. Denn bei der Android-App von Zattoo kommt das nicht vor. Da wird immer nach 2...3 Sekunden zum nächsten Stream geschaltet.

Dann sollten also nach 2-3 Sekunden die nötigen Informationen da sein.

(Umkodiert wird übriges nicht!)

Zitat von Paulaner

Was mir jetzt noch fehlt ist das zugehörige EPG für die IPTV-Streams.

Für TVheadend habe ich dazu bereits eine passende xmltv-Datei. Die müsste man doch eigentlich auch für die IPTV-Streams im VDR verwenden können.

Nur weiß ich momentan noch nicht, wie ich diese mit den IPTV-Streams im VDR verknüpfen kann/muss. Das ist für mich noch absolutes Neuland!

Dazu solltest Du mal ein extra Thema auf machen.

Es gibt mehrere Plugins für externes EPG und ich vermute mindestens eines wird das schon können.

Mit dem Thema kenne ich mich aber null aus.

Zitat von mini73

Vielleicht müsste mal jemand die Ärmel hochkrempeln und das direkt als Plugin umsetzen, damit das Starten/Stoppen von Scripts usw. wegfällt. Ich kann mir vorstellen, dass da auch noch die ein oder andere Sekunde auf der Strecke bleiben könnte.

Die Idee hatte ich schon von Anfang an, beim hbbTV-Plugin hat man diesbezüglich ja schon hervorragende Vorarbeit geleistet.

Zumindest sollte so der Umweg über den "internen" udp-Stream weg fallen und die Puffer da sparen.

Bevor man da aber mehr Zeit rein steckt, wollte ich erst mal sehen, ob das mit ffmpeg überhaupt sinnvoll funktioniert.

Zitat von Paulaner

In KODI wird dies ja so gemacht, dass für verschiedene IPTV-Lösungen es entsprechende PVR-Addons gibt.

Das dann doch eher nicht, da bei jeder Änderung (und diese Internet-Dienste neigen dazu) das Plugin aktualisiert werden müsste.

Ich denke eher in die Richtung das iptv-Plugin irgendwie für die m3u8-Quellen aufzubohren, soweit die enthaltenen Daten unterstützt werden. Die enthaltenen hls/dash Streams sind standardisiert, da besteht zumindest die Chance das aktuell zu halten.

Der Import der m3u8 Playlisten würde dann gelegentlich über ein Skript laufen, das man recht einfach aktualisieren kann.

Und letztlich ist es ja egal, ob das EPG aus einem anderen Plugin kommt, sofern das Skript beide Konfigurationen gleichzeitig aktualisiert.

Bei der Liste mit den freien Streams von weiter oben habe ich schon mit sowas angefangen.

Leider hatte ich da bislang nur kurz Zeit dafür, so weit dass brauchbare channels.conf Einträge raus kommen bin ich noch nicht.

Immerhin sucht es mir schon das beste Programm und die Streams dazu raus. (Allein das das hat länger gedauert, als gedacht.)

Zitat von SHF

Bevor man da aber mehr Zeit rein steckt, wollte ich erst mal sehen, ob das mit ffmpeg überhaupt sinnvoll funktioniert.

Na ja, mit ffmpeg funktioniert es auf jeden Fall, denn das wird ja bei TvHeadend und dem zugehörigen KODI-Addon PVR-HTS-TvHeadend verwendet.

Ich habe ja schon die Streams vom TvHeadend genommen und im VDR über das iptv-Plugin angeschaut. Funktioniert auch einwandfrei.

Dazu holt man sich die channels.m3u aus dem TvHeadend: http://<ip-adresse>:9981/playlist

und generoiert dann daraus Einträge für die vdr-channels.conf.

Die channels.m3u von TvHeadend sieht so aus:

#EXTM3U
#EXTINF:-1 logo="https://ondemo.tmsimg.com/assets/s90447_ll_h15_ab.png?w=360&h=270" tvg-id="44b9f53f46416f790d5c048a843d7a55" tvg-chno="1",Das Erste HD
http://192.168.1.3:9981/stream/channelid/1073068356?profile=pass
#EXTINF:-1 logo="https://ondemo.tmsimg.com/assets/s67217_ll_h15_ab.png?w=360&h=270" tvg-id="98edca5553f74d339d4c8d823b52ad5a" tvg-chno="2",ZDF HD
http://192.168.1.3:9981/stream/channelid/1439362456?profile=pass
.....

und daraus dann entsprechende Einträge in der channels.conf für das vdr-iptv-Plugin erstellt:

:@41 IPTV Tvheadend
Das Erste HD tvh;IPTV:410:S=0|P=0|F=CURL|U=http%3A//192.168.1.3%3A9981/stream/channelid/1073068356?profile=pass|A=410:I:0:258=27:256=@15;257=@122:0:0:1:0:0:0
ZDF HD tvh;IPTV:420:S=0|P=0|F=CURL|U=http%3A//192.168.1.3%3A9981/stream/channelid/1439362456?profile=pass|A=420:I:0:258=27:256=@15;257=@122:0:0:1:0:0:0
.....

Damit kann man dann direkt die Streams anschauen, da diese bereits in das *.ts-Format gewandelt sind.

Leider werden die EPG-Daten, die bereits in TvHeadend eingemappt sind über diese playlist-Streams , nicht mit weitergegeben.

Das hatte ich ja am Anfang gehofft, denn da würde ich nur TvHeadend nehmen und hätte mir dem Rest erspart.

Da aber leider das EPG nicht mit weitergegeben wird, wollte ich den Umweg über TvHeadend vermeiden und direkt eben das ffmpeg verwenden.

In TvHeadend hat ja so viele Einstell-/Setup-Möglichkeiten, dass man sich da doch etwas einarbeiten muss, bevor man ein vernünftiges Ergebnis bekommt. Und das ffmpeg braucht man ja in jedem Fall, ob mit oder auch ohne TvHeadend.

Ein Versuch wäre vielleicht noch die Streams über das satip-Plugin zu bekommen, d.h. das TvHeadend als SatIP-Server laufen zu lassen.

Und dann mit dem vdr-satip-Plugin die Streams zu empfangen. das habe ich aber bisher noch nicht hinbekommen (habe auch nicht soviel getestet).

Ich weiß aber leider nicht, ob da die EPG-Daten mitgegeben werden.