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

  • Okay, jetzt habe ich zum ersten Mal ein gutes Bild und Ton! :)  :thumbup:


    Wichtig ist, dass man diese Werte:

    Code
    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:

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

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

  • Quote

    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.

  • 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?


    Code
    TV5;IPTV:50:S=0|P=1|F=FILE|U=/video/stream.ts|A=5:I:0:514:670:2321:0:5:0:0:0

    Wohnzimmer: NUC10I3 - Logitech z-5500 - Panasonic 55" TV - Hauppauge Dual DVB-C Stick - Ubuntu 22.04 LTS - yavdr ansible
    Schlafzimmer: NUC10I3 - LG 42" TV - Hauppauge Dual DVB-C Stick - Ubuntu 22.04 LTS - yavdr ansible

    Streamingserver: -im Aufbau-
    diverse Test Clients: -Raspberry Pi + openelec, i3 mit Geforce1030

  • 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

    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


    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.


    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.


    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.



    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:

    Bash
    #!/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.

    Gruss
    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:

    Code
     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 &

    Gruss
    SHF


  • 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.


  • 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.


    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.

    Code
     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:

    Code
     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.

    Gruss
    SHF


  • 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. :)  :thumbup:


    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.

    Edited once, last by 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:

    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:

    Code
     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.)


    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.

    Gruss
    SHF


    Edited 2 times, last by 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:

    Code
    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.



    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.

    Edited 3 times, last by 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.



    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.

    Gruss
    SHF


Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!