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

    Ich denke meine HW ist auch potent genug:

    - Intel Core i5 11400

    - Grafik nvidia 1030


    Ich habe mir auch mal die CPU-last über das vdr-plugin-systeminfo anzeigen lassen und da war es <10%


    Über das Script: vlc2iptv_raw kann ich mir ja jetzt schon die Streams anschauen und da wird ja der VLC-Player zum Umwandeln des Streams in einen TS-Stream genutzt. Auch da ist die Systemlast bei ca. 10%.

    Bei der Nutzung dieses Scripts gibt es eben nur ein paar Probleme wie sehr lange Umschaltzeiten und manchmal geht es gar nicht und dann muss man einmal weiterschalten und man hat wieder Bild+Ton. Also für den täglichen Einsatz nicht geeignet.



    VLC ist bei mir in Version-3.0.16 aus den Ubuntu-22.04

    FFmpeg habe ich in der Version-4.4.2 , wie es ebenfalls bei Ubuntu-22.04 dabei ist.

    I think this is (also) related to your problem:

    I'm not seeing that on my side

    Code
    [hls @ 0x559eef0fda00] No longer receiving playlist 2 ('https://hse24.akamaized.net/hls/live/2006663/hse24/master_900p25.m3u8')
[hls @ 0x559eef0fda00] No longer receiving playlist 4 ('https://hse24.akamaized.net/hls/live/2006663/hse24/master_576p25.m3u8')
[hls @ 0x559eef0fda00] No longer receiving playlist 1 ('https://hse24.akamaized.net/hls/live/2006663-b/hse24/master_1080p25.m3u8')
[hls @ 0x559eef0fda00] No longer receiving playlist 3 ('https://hse24.akamaized.net/hls/live/2006663-b/hse24/master_900p25.m3u8')
[hls @ 0x559eef0fda00] No longer receiving playlist 5 ('https://hse24.akamaized.net/hls/live/2006663-b/hse24/master_576p25.m3u8')


    With regards to the vlc2iptv script, just kill -9 vlc when switching channel:

    Change trap line like below

    Code
    trap 'kill -KILL  ${PID} 2> /dev/null' INT EXIT QUIT TERM KILL

    Maybe not very gentle but effective

    Mir ist jetzt im ffmpeg.log noch etwas aufgefallen:

    In Zeile #42 ... #44 sieht man, dass die Streams von Audio und Video zwischen Input und Output getauscht werden:

    Zeile #43 Video-Stream Input 0:2 --> Output 0:0

    Zeile #44 Audio AAC-Stereo Input 0:0 --> Output 0:1

    Der Audio eAC3-Stream Input 0:1 fehlt hier ganz. :/


    Irgendwo hatte ich gelesen, dass dieses "stream mapping" erforderlich sei, aber dabei Probleme auftreten können.

    Leider finde ich nicht mehr wo das war.

    Könne evtl. daher die vielen Meldungen mit den [hls @ 0x557766909a00] Skip ...   kommen, die dann auch die Bildfehler verursachen?

    Code
    Stream #0:2: Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 50 fps, 50 tbr, 1k tbn, 100 tbc (default)
Stream #0:2 -> #0:0 (copy)


    Das der Video-Stream nach 0 kopiert wird, ist korrekt.


    Mit -map 0 -c copysollten alle Streams kopiert werden.


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Hi Paulaner

    I still don’t understand why your ffmpeg based script is not working well.

    I compiled ffmpeg 4.4.2 on my test system and it’s working well. (Not with all your options, don’t need all those)


    Important options during execution are:

    -re

    $HOST:$PORT?pkt_size=1316&buffer_size=65536


    And sufficiently high

    -probesize

    -analyzeduration


    Just to be sure, execute below

    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


    And if all ‘PIDs’ match it should work

    Im Forum zu der telerising.api gibt es auch einige mit derartigen Problemen, während es bei anderen einwandfrei geht.

    In dem Zusammenhang wird auch immer ffmpeg erwähnt. Ich vermute die Ausgabe geht dann über Kodi???

    Eventuell gibt es da wirklich Probleme mit einigen ffmpeg-Versionen oder Paketen?


    Paulaner könntest Du mal die beiden Befehle aus meinem letzten Beitrag probieren?

    So würde man mal die telerising.api und den VDR als Fehlerquelle ausschließen.

    Xine gibt es bei Debian im Paket "xine-ui", das müsste bei Ubuntu auch der Fall sein.

    Die beiden Befehle müssen in zwei Terminals parallel gestartet werden, erst ffmpeg, dann xine.


    Zitat von Paulaner

    Könne evtl. daher die vielen Meldungen mit den [hls @ 0x557766909a00] Skip ... kommen, die dann auch die Bildfehler verursachen?

    Die Meldungen gibt es bei mir auch massenhaft:

    Man müsste mal schauen, was das bedeutet, aber ein funktionelles Problem scheint es nicht zu sein.

    (Zumindest in meinem Setup nicht.)


    Mit -map 0 -c copy an Stelle -codec:v copy -codec:a copy geht es hier übrigens auch.

    Die PIDs scheinen da aber etwas durcheinander zu kommen.

    Code: vorher
    demux: starting stream 0x558892580460.
demux_ts: PAT transport stream id 2836.
demux_ts: found 1 programs, 1 pmt pids.
demux_ts: pmt video descriptor 1b e0 64 f0 00
demux_ts: new video pid 100
demux_ts: pmt audio descriptor 0f e0 c8 f0 00
demux_ts: new audio pid 200
demux_ts: found no ISO 639 lang
demux_ts: using 2 pids, 1 audio 0 subtitle channels
demux_ts: PCR pid 100.


    Jedenfalls gibt es laut Xine --verbose=2 deutlich mehr PIDs.

    Und es ruckelt gelegentlich auch!

    Gruss
    SHF


    Dann probiert mal -map 0 -c copy -sn


    oder -map 0 -c:v copy -c:a copy -sn


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    • Neu

    Ich habe irgendwie die Übersicht mit den vielen Änderungen, Tests usw. verloren.

    Momentan geht bei mir gar nichts mehr so richtig. ?(


    Könnte mal jemand das aktuelle Script "ffmpeg2iptv_raw" mit allen letzten Änderungen hier einstellen.

    Damit wir wieder einen gemeinsamen Stand haben. ;)


    SHF

    die "telerising.api" funktioniert zusammen mit TVheadend als auch im VDR.

    Denn die nutze ich ja auch testweise mit dem Script "vlc2iptv_raw" im IPTV-Plugin.

    Da habe ich ja ein einwandfreies Bild + Audio in Stereo + eAC3-5.1, bis auf die Umschaltzeiten > 10 Sekunden.


    Nur eben, wenn ich das ohne VLC machen will, also über "ffmpeg" dann funktioniert es nicht so richtig: Bildstörungen + Audio-Probleme

    Übrigens bei Kodi mit TVheadend wird ebenfalls "ffmpeg" benutzt kein "VLC-Player", um die Streams entsprechend aufzubereiten.

    Das klappt da einwandfrei mit super Bild + Audio.

    • Neu

    Evtl. könnte der Parameter -re helfen.



    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Einmal editiert, zuletzt von jsffm ()

    • Neu

    jsffm

    den Parameter haben wir schon im Script:

    STREAM_FORMAT="-f hls -http_persistent 0 -re"



    Aber ich habe seit ein paar Tagen ein anderes Problem! :(

    Irgendwie ist jetzt in meiner Installation etwas kaputt gegangen.

    Wenn ich den PC herunterfahre kommen endlose Fehlermeldungen, die leider nicht mehr im syslog gespeichert werden.

    Da die Meldungen soviele sind kann ich auch nicht erkennen, was da los ist. X/

    Vielleicht ist das auch ein Grund, warum es bei mir nicht so richtig mit der Wiedergabe der Streams über "ffmpeg" funktionieren will.


    Ich werde erstmal mein Backup einspielen und dann die ganzen Anpassungen für das iptv-Plugin vornehmen.

    Aber das dauert eine Weile und so werde ich wohl erst am langen Wochenende wieder dazu kommen um etwas neues zu testen.

    • Neu
    Zitat von Paulaner

    Könnte mal jemand das aktuelle Script "ffmpeg2iptv_raw" mit allen letzten Änderungen hier einstellen.

    Damit wir wieder einen gemeinsamen Stand haben. ;)

    Ich habe jetzt meine letzten Änderungen in diese Version #117 eingefügt. Das war doch die Letzte?

    Die Änderung sind lediglich die beiden " um die udp-url.

    Ohne die geht es bei mir auch nicht gescheit!

    Der Rest war nicht zielführend (siehe nächster Beitrag).


    Ich meinte letztes mal den Test aus Beitrag #139. Nur mit ffmpeg und xine.

    Ffmpeg ist da identisch konfiguriert, wie fürs iptv-plugin, aber halt ohne telerising und ohne VDR.

    Es geht da erstmal nur darum Fehlerquellen auszuschliessen.


    Wer Abwechselung zu hse sucht, hier ist die URL vom offizeillen ZDF-Livestream:

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


    Nach dem, was ich inzwischen hier probiert habe, tippe ich auf ein Problem zwischen ffmpeg und der Anwendung. Also irgendwo am udp videostream.

    Obwohl der nie den Computer verlässt, scheint es da zu Paketverlusten zu kommen.

    Die von carel schon erwähnten Einstellungen:

    Code
    pkt_size=1316&buffer_size=65536&overrun_nonfatal=1

    scheinen extrem wichtig zu sein. Bei mir muss aber zwingend die ganze URL mit " gequotet werden, sonst geht es nicht!

    Gruss
    SHF


    • Neu

    -map 0 ist hier keine gute Idee.

    Der Inputstream ist immer der folgende (HSE):

    ZDF ist aber vergleichbar.

    Man sieht das es da mehre Video mit den dazugehörigen Audio-Streams gibt.


    Output mit -map 0:

    Man hat am Ende einen Haufen Video und Audio-Streams im TS-Stream. Das mach eigentlich keinen Sinn.

    Am Ende will man ja einmal Video plus evtl. mehrerer Audio-Stream, falls angeboten.

    Ob die Datenrate dadurch ansteigt, habe ich noch gar nicht gemessen.


    Output ohne -map 0 und ohne Änderung der PIDs.

    nur -c copy ohne -codec:v $VCODEC $VCODEC_OPTIONS -codec:a $ACODEC $ACODEC_OPTIONS -streamid 0:$VPID -streamid 1:$APID

    Nur noch einmal Audio und Video.

    Hier sollte jetzt das Default-Verhalten von ffmpeg gegriffen haben.

    Bei mehreren Audio-Spuren muss man sich wohl noch was überlegen, aber erstmal sollte es so gehen.


    Probleme scheint es auch zu geben, wenn nicht Stream 0 und 1 gewählt werden (wie beim ZDF), dann klappt das mit dem Setzen der PIDs nicht.

    Gruss
    SHF


    Gefällt mir 3
    • Neu

    Hier ein Link zum Thema UDO und Puffer:

    Monitoring the UDP Socket Buffer


    Bei mir sieht es so aus:

    Code
    UNCONN                0                     0                                         127.0.0.1:4320                                       0.0.0.0:*
         skmem:(r0,rb425984,t0,tb212992,f4096,w0,o0,bl0,d0)

    Gruss
    SHF


    Gefällt mir 1
    • Neu

    Ich bin wieder aus dem kurzen Osterurlaub zurück und werde in den nächsten Tagen wieder testen können. ;)


    Irgendetwas hatte mir ja bei den vielen Tests das System zerschossen, so dass ich nur noch Fehlermeldungen hatte, die ich nicht deuten konnte.

    Deswegen muss ich Morgen auf meinen Test-PC das Backup vor den vielen Tests mit dem vdr-plugin-iptv einspielen und dann noch die notwendigen Updates und Programme (ffmpeg, telerising.api usw.) installieren.


    Eine Frage dazu im Vorfeld:

    Gibt es noch neue Erkenntnisse bzgl. des Scrpts ffmpeg2iptv die ich gleich mit verwenden sollte?

    Ansonsten werde ich mich in ein paar Tagen melden, sobald alles wieder am laufen ist! :)

    • Neu

    Mein letzter Stand ist der hier: #151

    Seit dem habe auch ich da nicht mehr viel gemacht.

    Gruss
    SHF


    • Neu

    Ich habe mein Backup eingespielt und alles soweit neu installiert, dass nun wieder alles läuft: telerising.api, tvheadend und das vdr-plugin-iptv.

    Es gibt eine gute und auch eine schlechte Nachricht:

    + Das System mit dem VDR und auch KODI mit TVheadend läuft wieder rund und vor allem ohne die vielen Meldungen beim Runterfahren! :)

    - Die Internetstreams laufen mit dem ffmpeg genauso bescheiden mit vielen Artefakten, ruckelnd und abgehacktem Ton. Genauso wie vorher! :(


    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.

    Das Resultat ist immer das gleiche: Im Bild sehr viele Artefakte, besonders bei schnellen Bewegungen, Bild ruckelt, Ton ist abgehackt, ruckelt auch.

    Also da ist irgendetwas noch nicht in Ordnung.


    Zum vergelich hier nochmal mein Script ffmpeg2iptv

    Es folgt noch TEIL 2 (wegen der Limitierung auf 10.000 Zeichen)

    Einmal editiert, zuletzt von Paulaner ()

    Gefällt mir 1
    • Neu

    TEIL 2:


    Dann noch einmal ein ffprobe http://192.168.1.3:5000/api/zde/live/ard.m3u8 wo man sehr gut am Ende erkennt, dass alle 3 Streams (2x Audio, 1x Video) richtig erkannt werden:


    Im Prinzip ist hier doch noch alles in Ordnung und trotzdem klappt es nicht! :(


    Weiter geht es mit TEIL 3:

    Einmal editiert, zuletzt von Paulaner ()

    Gefällt mir 1
    • Neu

    TEIL 3:


    Im tvheadend wird ja auch ffmpeg benutzt, um den Internetstream in einen TS-Stream umzuwandeln.

    Dazu ist mir in der Zwischenzeit noch etwas eingefallen, dass man dazu in der telerising.api unbedingt folgende Einstellungen machen muss:



    Wichtig ist hier der Punkt: "Retrieve streams via ffmpeg pipe"

    Wenn man das macht, dann bekommt man in der "favorites.m3u" die von der itelerising.api an das tvheadend übergeben wird folgende Kanalliste:



    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.

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

    Gefällt mir 1
    • Neu

    Hi Paulaner,


    ffmpeg reads the stream just fine, the issue is with the UDP streaming.


    When you tune to the test channel the first time, can you then please check if you see just one ffmpeg process? Or even vlc?

    If there are, for some reason, that will lead to conflicts in the UDP stream.


    Just to be sure we have all signals available to kill ffmpeg, add HUP to it:

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


    And please don't forget before you test:

    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

    Maybe an idea to add to /etc/rc.local (if that's available)


    If it fails, try this from SHF

    Zitat

    Hier ein Link zum Thema UDP und Puffer:

    Monitoring the UDP Socket Buffer

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden