Beiträge von mrjoe

  • [gelöst]HDMI Eingang als Kanal

    Zitat von don-baba

    Welcher User hat denn bei dir unter /var/lib/vdr Zugriff?

    Meinst du vermutlich /usr/local/lib/vdr/? Das wäre root:root.


    Zitat von don-baba

    Kannst du VLC als root starten? Bei mir gibt es bei debian/ubuntu immer die Meldung das root nicht auf vlc zugreifen kann/darf.

    Meinst du mpv? Das habe ich als Root gestartet. vlc nutzte ich (abgesehen von meinem letzten "Erfolgserlebnis") nicht auf dem tvheadend-Server bzw. dem VDR Client. Wie geschrieben läuft beim Odroid dank softhdodroid alles unter vdr.

  • [gelöst]HDMI Eingang als Kanal

    Zitat von wirbel

    Die PIDs in der xspf sind service ID, Audiio, Video und die normalen DVB SI tables.


    So wie es ausschaut, hat tvheadend Probleme beim Transcodieren (nicht genug CPU power dort?) oder Verpacken des Streams, deswegen bekommst du wohl die Daten häppchenweise.

    Gute Idee, hatte ich jetzt länger nicht mehr geprüft. Jedoch sind auf dem tvheadend Server (ein i3-8100 4-Kerner) 3 Kerne bei durchschnittlich 5% CPU Last und der 4. geht bis auf 25% hoch. Sollte aber bei weitem kein Problem darstellen. Der Client (ein Odroid) zeigt bei 2 von 6 Kernen ca. 5% Last und die restlichen 4 dümpeln bei nahezu 0%. Damit sollte doch das kein Problem sein. Könnte softhdodroid eine Rolle spielen und beim Darstellen stocken? Komischerweise geht ja der Ton und ich hätte gedacht, dass wenn der Server stockt, auch der Ton am Client stocken würde.


    Habe mittlerweile noch etwas mit tvheadend experimentiert und als ich dort für meinen mux "Use A/V library" (also libav) einschaltete, kamen zig AV-Fehler im tvheadend-log. Dann bin ich hergegangen und habe den Quellstream nochmals durch VLC geschickt und biete ihn dann verarbeitet als Stream für tvheadend wieder an. Bin kein VLC Experte und habe deshalb mal folgendes probiert


    Code
    vlc -vvv http://192.168.0.12/ts/1_0 --sout '#standard{access=http,mux=ts,dst=192.168.0.18:8888}'

    Erster Test mit einem VLC Client direkt auf die 192.168.0.18:8888 erbrachte ein Bild. Nun habe ich in tvheadend als Eingang für meinen mux (also für den satip-Kanal) die Streamadresse auf 192.168.0.18:8888 geändert und siehe da: es kommt nun im vdr per satip-plugin zum Ton auch ein Bild! 8) 8) 8)


    Fragen an die (vlc) Experten:

    • was wären optimierte Parameter für sout um den optimalen Stream zu haben? Wie wäre z.B. ein Parameter um einen Bild-Ton Versatz auszugleichen?
    • leider geht auch mit dieser aufbereiteten Streamquelle das iptv Plugin noch nicht. Was wäre denn ein optimaler vlc Aufruf, damit iptv den Stream verdaut und wie wäre idealerweise dann der channels.conf Eintrag? Wie schon vorher sehe ich im log keine Fehler beim Anwählen des iptv Kanals.

    Schonmal vielen Dank an wirbel und don-baba, die mich durch Wink mit ihren Zaunpfählen einen großen Schritt weitergebracht haben! Jetzt geht es ans Feintuning.


    Ergänzung: Auslastung auf dem Rechner, auf dem tvheadend und vlc läuft ist bei 4 Kernen <<15% im Schnitt pro Kern

  • [gelöst]HDMI Eingang als Kanal

    Vielen Dank auch für deinen Tipp. Dein channels-conf-Eintrag führt zu "Kanal nicht verfügbar". Ich habe stattdessen dann mit TV7;IPTV:70:S=0|P=0|F=FILE|U=/tmp/test.ts|A=5:I:0:514:670:2321:0:5:0:0:0 etwas mehr Erfolg. Der Kanal lässt sich anwählen, aber genau in dem Moment stoppt dann mpv ohne jegliche Fehlermeldung. Wenn ich mpv wieder starte sehe ich im log des vdr

    Code
    Feb 21 20:44:02 odroid vdr: [7038] IPTV streamer thread started (pid=6789, tid=7038, prio=high)
Feb 21 20:44:04 odroid vdr: [7036] IPTV: Skipped 1573 bytes to sync on TS packet

    Danach beendet sich mpv wieder. Das Spiel kann ich wiederholen. Eine Bildausgabe gibt es leider nicht. Ich verstehe nur nicht, warum mpv sich beendet wenn jemand auf test.ts zugreift?! Würde schon eher verstehen, dass sich vdr beendet oder eine Fehlermeldung ausgibt.


    Zur Info: vdr und mpv laufen beide als root (teste auf einem Odroid mit softhdodroid und da muss vdr mit root laufen), die Datei hat folgende Rechte gesetzt:

    Code
    prw-r--r--  1 root root    0 Feb 21 20:30 test.ts

    Auch ein chmod a+w und Schreibrechte für alle brachte nichts. Hast du eine Idee woran das liegen könnte?

  • [gelöst]HDMI Eingang als Kanal

    Zitat von wirbel

    Ich würde mal vlc plus tvheadend testen. Einfach die datei im Anhang in xspf umbenennen und dann mit vlc öffnen.

    Vielen Dank für den Tipp. Ich habe es ausprobiert und leider rödelt VLC beim Starten ewig ohne jegliche Fehlermeldung, aber auch leider ohne Bild. Ich bekomme beim Start von VLC in tvheadend eine Subscription-Meldung analog zur Meldung beim satip-plugin. Somit scheint beim Verbindungsaufbau schonmal kein Unterschied. Weiss jemand, wie man VLC gesprächiger machen kann?


    Was hat es mit der pids-Angabe in deiner xspf-Datei auf sich? Im Vergleich dazu sind die durch w_scan_cpp gefundenen pids übersichtlicher oder sehe ich das falsch: HDMI:114000:I0C0M256:C:6900:256=36:257=@15:0:0:1:0:1:0


    Ergänzung:

    warum auch immer habe ich den VDR auf dem HDMI satip Kanal stehen lassen und plötzlich kam ein Bild bzw. besser gesagt ein Trickfilm. Der Video lief viel zu schnell und stoppte dann wieder. Nach einer Weile das gleiche Spiel und er stoppte wieder. :o Hast du dafür eine Erklärung?

    Ergänzung2:

    der Ton läuft im vdr flüssig, nur das Bild steht die meiste Zeit (bisher beobachtet habe ich, dass nach dem Umschalten auf den Kanal der erste Trickfilm kommt, dann steht das Bild, dann kommt wieder ein Trickfil, dann steht wieder das Bild und bleibt stehen - Ton kommt sauber)


    Im Log sehe ich

    Code
    Feb 21 21:41:05 odroid vdr: video: not detected
Feb 21 21:41:12 odroid vdr: message repeated 728 times: [ video: not detected]
Feb 21 21:41:12 odroid vdr: video: h264 detected
Feb 21 21:41:18 odroid vdr: CodecVideoOpen h264
Feb 21 21:41:18 odroid vdr: AmlVideoSink - VIDEO/H264
Feb 21 21:41:18 odroid vdr: amlreset
Feb 21 21:41:18 odroid vdr: internal close pip 0
Feb 21 21:41:18 odroid vdr: AmlVideoSink - VIDEO/H264
Feb 21 21:41:18 odroid vdr: first vpts: 0x0020d3c816

    Und dann steht das Bild...

  • [gelöst]HDMI Eingang als Kanal

    Zitat von SurfaceCleanerZ

    Warum läßt du nicht direkt für VDR eine channels.conf erzeugen.

    Für welchen Übertragungsweg? Ich habe momentan 3 mögliche Wege, den HDMI Stream am VDR zu empfangen:

    1. VDR iptv-plugin empfängt den ts-Stream vom HDMI Encoder --> wäre meine Wunschkonstellation
      hierfür habe ich folgende 2 channels.conf-Einträge erstellt:
      IP1;IPTV:10:S=0|P=0|F=HTTP|U=192.168.0.12/ts/1_0|A=80:I:0:513=2:660=@4:2321:0:4:0:0:0
      IP2;IPTV:20:S=0|P=0|F=CURL|U=http%3A//192.168.0.12%3A80/ts/1_0|A=0:I:0:513=2:660=@4:2321:0:4:0:0:0
      Bei beiden gibt es kein Bild und es kommen im vdr-Log "dauerhaft" TS-Sync Einträge vom iptv-plugin
    2. VDR iptv-plugin empfängt über tvheadend als Streamserver den Kanal, der wiederum den Stream vom HDMI Encoder wiedergibt
      hierfür habe ich folgenden channels.conf-Einträge erstellt:
      TV6;IPTV:50:S=0|P=0|F=CURL|U=http%3A//192.168.0.18%3A9981/stream/channelid/1814832835?profile=pass|A=0:I:0:513=2:660=@4:2321:0:4:0:0:0
    3. VDR satip-plugin empfängt über tvheadend als Sat-IP-Server den Kanal, der wiederum den Stream vom HDMI Encoder wiedergibt
      hierfür habe ich die channels.conf per w_scan_cpp erzeugt und er hat auch den einen von mir erzeugten Kanal im channels.conf Format ausgegeben:
      HDMI:114000:I0C0M256:C:6900:256=36:257=@15:0:0:1:0:1:0
      Frage: passt das? Frequenz stimmt schonmal, bei den restlichen xPIDs bin ich mir nicht sicher. Gebe ich bei tvheadend leider nicht an und muss auf w_scan_cpp vertrauen. Ich sehe im tvheadend aber, dass zumindest ein Subscribing erfolgt --> Zugriff an sich erfolgt also korrekt, nur verliere ich irgendwo zwischen tvheadend und satip-Plugin das Signal

    Das Videobild von 1 und 2 konnte ich problemlos mit VLC anstelle des VDR's mit iptv-plugin abspielen (die Aufruf-URLs im VLC / Menüpunkt Medieninformationen sind genau die wie in der channels.conf angegeben). Somit ist sichergestellt, dass sowohl der Stream vom HDMI Encoder "funktioniert", als auch das Durchreichen in tvheadend. Letzteres ist natürlich nicht wirklich sinnhaft. Ich dachte, vielleicht verpackt tvheadend den Stream nochmals so, dass das iptv-plugin den Stream abspielen kann.
    Variante 3 funktionierte noch nirgends, auch nicht mit VLC. Könnte vtl. auch daran liegen, das der Streamserver von tvheadend aktiv ist und VLC dann bevorzugt nur den Stream anzeigt und nicht den Sat-IP Server. Das ganze obwohl der Sat-IP Server von w_scan_cpp auch ohne die Angabe der IP Adresse direkt erkannt wird und der Scan ein scheinbar korrektes Ergebnis bringt.


    Wie oben geschrieben funktioniert in VLC die Sat-IP Verbindung noch nicht. In der Wiedergabeliste taucht momentan nur ein tvheadend Eintrag (zwar mit korrektem Sat-IP-Server Port) auf, jedoch verbindet er sich beim Anklicken des einzigen Kanals ganz normal auf den Stream unter dem tvheadend Streamserver Port 9981 und nicht als Sat-IP Client.


    Ich werde spätestens am WE das Logging/Debugging im satip-Plugin einschalten in der Hoffnung, dass ich da etwas brauchbares sehe. Wireshark würde mir bei SatIP dann weiterhelfen, wenn ich zum Vergleich ein Protokoll einer funktionierenden Verbindung hätte. Ich habe auch in einem anderen Thread hier gelesen, dass mitunter tvheadend's Sat-IP Server Probleme hat, wenn der Kanal ein Stream als Quelle hat und kein "richtiges" Device. Das teste ich am WE auch mal mit meinem USB SAT-Empfänger. Falls da der Sat-IP Server korrekt funktioniert, kann man tvheadend nicht als Durchreiche für den Stream nutzen.


    Für Ideen, insbesondere wie das einer der 3 genannten Wege ertüchtigt werden kann, bin ich natürlich dankbar. :)

  • [gelöst]HDMI Eingang als Kanal

    Bin mittlerweile einen grossen Schritt weiter. Konnte nun in tvheadend einen SATIP Server aufsetzen und meinen HDMI Encoder-Kanal als DVB-C Kanal anbieten. Nun habe ich per w_scan_cpp den korrekten(?) channels.conf Eintrag erzeugen lassen (hab nur einen Kanal angeboten, w_scan_cpp gibt auch nur einen Eintrag aus). Er sieht wie folgt aus:

    Code
    HDMI:114000:I0C0M256:C:6900:256=36:257@15:0:0:1:0:1:0

    Leider bekomme ich beim Tunen auf den Kanal folgende Fehlereinträge und ein schwarzes Bild:

    video: not detected wird dann noch regelmässig wiederholt. Wahrscheinlich liegt es am Fehler SATIP-ERROR: bool cSatipFrontends::Attach(int, int) no Frontend found for attaching deviceID 0 (TP 114). Hat hier einer der SATIP Profis eine Idee, an was das liegen könnte bzw. wie könnte ich den SATIP-Server von tvheadend sonst noch prüfen?

  • [gelöst]HDMI Eingang als Kanal

    Habe mir nun einen HDMI Encoder (ON-DMI-16E) zugelegt. Das Teil funktioniert sehr stabil sowohl per Zugriff über Web-Browser als auch per VLC. Leider bekam ich es per iptv noch nicht direkt im vdr ans laufen und habe mir deshalb inspiriert durch diesen Thread tvheadend angeschaut. Mal abgesehen davon, das dessen Konfiguration mehr als gewöhnungsbedürftig ist (vielleicht werde ich auch nur alt... ;) ), funktioniert der Zugriff über tvheadend auf den Encoder relativ gut. Relativ, da ich zeitweise minutenlang ein stabiles Bild habe, dann ruckt es kurz bevor es sich wieder fängt. Könnte an der Konfiguration von tvheadend liegen, aber auch durchaus daran, dass ich es gerade auf meinem Thinkcentre teste und vermutlich parallel noch Prozesse laufen (ist ein FullFeatured Debian Linux und keine Minimal-Installation).

    Wie im o.g. Thread bereits angedeutet, versuche ich nun von VDR auf tvheadend zuzugreifen und idealerweise würde das per satip-Plugin gehen. Nur scheitere ich gerade daran, den Sat-IP Server von tvheadend als DVB-C device (oder auch irgendein anderes) mit dem IP-Stream zu aktivieren. Obwohl der gewählte Sat-IP Server-Port durch tvheadend offen ist, findet w_scan_cpp nichts. Vermutlich ist der Sat-IP Server schlicht noch nicht mit INhalt gefüllt. Hat hierzu jemand Erfahrung, wie man aus tvheadend einen "funktionierenden" Kanal als einen DVB-x Kanal per Sat-IP Server rausbekommt?

    Ansonsten braucht man ja auch noch eine Herausforderung für die kommenden Tage... Prinzipiell bin ich aber schon wesentlich weiter, als mit den "billigen" HDMI2USB Konverter. :)

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

    Zitat von Dr. Seltsam

    Aus Sicht von vdr sind die Kanäle dann normale DVB-C-Kanäle, so dass Du an der channels.conf nichts ändern brauchst. Im satip-Plugin musst Du die Priorität (ggü. evtl. noch vorhandenen lokalen DVB devices) einstellen.

    Bei mir lauten die Plugin-Parameter des satip-Plugins

    -s 192.168.178.90|DVBC-2|minisatip -r 430000

    Blöde Frage: wie komme ich an die passenden channels.conf Einträge für einen DVB-C tvheadend Server? Bei lokalen Sat Tuner-Devices war/wäre w_scan die Lösung. Wie macht ihr das bei satip-Servern, die ihr über das satip-plugin ansprecht? :/

  • IPTV channels.conf für lokalen Stream

    Ich habe einen Stream-Server im lokalen Netz, der unter der Adresse http://192.168.1.12/ts/1_0 z.B. per VLC-Player ein perfektes Bild inkl. Ton liefert. Nun scheitere ich vermutlich an der richtigen channels.conf Angabe. Ich habe folgende Varianten schon durchprobiert:


    Code
    IP1;IPTV:10:S=0|P=0|F=HTTP|U=192.168.1.12/ts/1_0|A=80:I:0:513:660:2321:0:4:0:0:0
IP2;IPTV:20:S=0|P=0|F=CURL|U=http%3A//192.168.1.12%3A80/ts/1_0|A=0:I:0:513:660:2321:0:4:0:0:0

    Bei beiden Einträgen erhalte ich im Log die ähnlichen Zeilen:


    Code
    Feb 10 18:06:45 odroid vdr: [4793] IPTV streamer thread started (pid=4744, tid=4793, prio=high)

    Jedoch bleibt der Bildschirm schwarz. Es kommen keine weiteren (Fehler-) Meldungen.


    Hat einer von euch eine Idee? Insbesondere bin ich mir unsicher bei den zusätzlichen Parametern abseits der URL. Sind die für Single-Streams überhaupt relevant?


    Falls relevant: der Videostream kommt mit dem H264 Codec, 1920x1080, 30fps


    Ergänzung: ich kann am VDR auf der Kommandozeile mit curl 192.168.1.12:80/ts/1_0 -o video.ts den Stream abgreifen. Es gibt also keine Zugriffsprobleme.


    Dank euch schonmal. :)


    MrJoe

  • Unraid & VDR DVB-S2

    Mit Unraid habe ich keine Erfahrung, da ich persönlich gerne das System selbst konfiguriere/aufsetze um dann genau das zu betreiben, was ich wirklich benötige. Ich habe meinen VDR Headless auf einem Debian-basiertem Host per qemu virtualisiert - eventuell hilft dir das als Anhalt. Dort reiche ich eine DD MAXS8 problemlos an die VM durch. Reines doing des PCI(e)-Durchreichens ist kaum Aufwand gewesen:

    * Intel VT-d im Bios einschalten (nutze ein i3-basiertes System)

    * durchzureichendes device per virsh detachen

    * in VM Konfiguration das Device aufnehmen

    * VM starten


    Idealerweise im Host-System die ddbridge blacklisten (gab bei mir zwar dann Folgeprobleme, kann bei anderen Kernelversionen aber auch funktionieren), damit das Device erst gar nicht initialisiert wird (kann sonst Nebeneffekte geben bzw. du musst vor Start der VM den Treiber händisch entladen).

  • Odroid N2+

    Ich habe hier einen Odroid N2, der bei Anlegen der Spannung nur die rote Lampe leuchten lässt. Die blaue Lampe als Heartbeat leuchtet nicht. Es kommt keine Ausgabe über HDMI. Der Wahlschalter steht wie an meinen funktionierenden Odroids auf SPI, gebootet wird von einem USB-Stick (schon alle USB Ports durchprobiert), der ebenfalls an einem anderen Odroid problemlos funktioniert und bootet.


    Ich habe gelesen, dass man den Boot-Vorgang per Console (an Pin 10 Rx, 8 Tx, 38 VCC, 9 Gnd) debuggen kann. Frage: hat das schonmal jemand gemacht? Zweite Frage: macht das überhaupt Sinn oder geht das in Richtung Elektroschrott? Am Ende kann man vermutlich eh nichts mehr ändern (FW update oder dergleichen).


    Ich schaue mal am WE ob ich einen UART Adapter (3,3V TTL) in der Kruschtelkiste finde, notfalls könnte ich auch mit einem zweiten Odroid arbeiten. Weiss nur nicht, ob ich meinen funktionierenden Odroid riskieren will...

  • [gelöst]HDMI Eingang als Kanal

    Zitat von don-baba

    Meint ihr sowas?


    https://www.amazon.de/EXVIST-E…66-4790-acf8-e520aaf28cd3


    HDMI Quelle dran anschließen, Stream als RTSP ausgeben und diesen mit dem IPTV oder SAT-IP Plugin abgreifen.

    Genau, das wäre die Idee. Man spart etwas, wenn man es in China bestellt - mit allen Vor- und Nachteilen.


    blau : hast du selbst einen konkreten Anwendungsfall? Ich dachte mittlerweile schon, dass nur ich den Usecase habe und da lohnt sich eine Umsetzung in SW eventuell nur bedingt. Wenn wir mehrere sind schon eher. :)

  • [gelöst]HDMI Eingang als Kanal

    alles klar, kein prob - kam selbst die letzten Wochen nicht dazu, hieran weiterzuarbeiten. Ich habe mittlerweile auch gesehen, dass es HDMI encoder gibt, die ein HDMI Signal per TS stream/RTMP/RTSP/UDP/TCP/IP/HTTP/ONVIF bereitstellen. Also quasi das, was ich per Tools nachbilden wollte. Eventuell bestelle ich mir mal ein Teil in Fernost... Könnte die Lösung für meinen Anwendungsfall sein.

  • [gelöst]HDMI Eingang als Kanal

    don-baba , hattest du Erfolg bzw. Erkenntnisse bei deinen Tests?

  • [gelöst]HDMI Eingang als Kanal

    Zitat von Dr. Seltsam

    Auf einem anderen vdr habe ich in /var/lib/vdr/plugins/iptv/ den Unterordner vlcinput. Darin die Datei frühstyxradio.conf mit diesem Inhalt:

    Code
    URL="https://ffn-de-hz-fal-stream09-cluster01.radiohost.de/ffn-comedy_mp3-192"

    Der dazugehörige channels.conf-Eintrag lautet:

    Code
    frühstyxradio;IPTV:2:S=0|P=0|F=EXT|U=vlc2iptv|A=2:I:0:0:128=@4:0:0:2:0:0:0

    Auf diesem Rechner habe ich die Datei vlc2iptv in /usr/local/share/vdr/plugins/iptv gegenüber dem Original aus den Plugin-Sourcen an einer Stelle modifiziert:

    Code
    -CHANNEL_SETTINGS_DIR=/etc/vdr/plugins/iptv/vlcinput/
+CHANNEL_SETTINGS_DIR=/var/lib/vdr/plugins/iptv/vlcinput/

    Ok, iptv ist manchmal etwas anders... Interessanterweise sucht iptv die Skript-Dateien nicht unter dem conf-Verzeichnis des VDRs, sondern unter /usr/local/share/vdr/plugins/iptv. Ergebnis:

    • mit meinem Skript analog zur Wiki-Seite: kein Bild, kein Ton - obwohl die TS-Dateien vom hls-Server geladen werden
    • mit dem vlc2iptv Skript bekomme ich zwar einen Ton (etwas gehackt am Anfang, am Ende kommt ein Stück flüssig), aber kein Bild. Jetzt hängt es vermutlich an dem früher im Thread schonmal angedeuteten Problem mit dem passenden Videostreamformat.

    Hier die Ausgabe beim Umschalten auf den vlc2iptv-Kanal:

    Ich sehe im ganzen Log keinen Verweis auf einen Video-Codec. Müsste hier nicht analog zu "codec: audio 'MP2 (MPEG audio layer 2)'" auch ein Video-Codec erkannt werden? Könnte das einer der iptv-Nutzer im Log nachschauen?


    Hat jemand schonmal einen selbst erstellten Stream (egal von welcher Quelle) in iptv gespeist? Vielleicht kann ich anhand der Konfiguration ableiten, was ich bei mir noch ändern muss.

  • [gelöst]HDMI Eingang als Kanal

    Zitat von Dr. Seltsam

    Ich habe mit dem iptv-Plugin und seiner mangelhaften Doku auch schon graue Haare bekommen...


    Bei mir liegen diese Dateien in /usr/local/share/vdr/plugins/iptv:

    Code
    image.sh
iptvstream-notrap.sh
linein.sh
webcam.sh
internetradio.sh
iptvstream.sh
vlc2iptv

    Das dürfte daran liegen, dass vdr mit PREFIX /usr/local kompiliert wurde, sonst wäre es wohl /usr/share/vdr/plugins/iptv

    /var/lib/vdr/plugins/iptv ist bei mir leer.

    Hmm, ich habe bei mir per gepatchter Make.config meine VDRs nach /opt/vdr verlagert und dabei z.B. das CONFDIR nach /opt/vdr/conf verlegt. Darin finde ich dann z.B. auch das ursprünglich leere Verzeichnis plugins/iptv und dort habe ich das Skript abgelegt. Ist aber ein guter Hinweis, eventuell sucht iptv woanders. Schaue ich mir nachher mal an. Wobei die Fehlermeldung da vermutlich eine andere wäre.


    Alternativ ist dein Hinweis aus dem zweiten Post auch interessant, eventuell sollte ich die "aktuellen" Skripte aus den Sourcen nehmen. Dann geht es über die conf-Dateien im Verzeichnis vlcinput.


    PS: nach dem Gewurschtel mit ffmpeg und VLC habe ich vermutlich keine Haare mehr, die grau werden können... :D Der hls-Weg hat auch noch den Nachteil einer gewissen Latenz, die vermutlich nicht beliebig klein werden kann. Das ist mir aber momentan beim proof-of-concept egal, optimieren kann man später.

  • [gelöst]HDMI Eingang als Kanal

    Zitat von lnj

    Do you really need to watch the stream as a channel, or do you just need to watch it? if it doesn’t matter how, then it’s very easy to watch any stream through the MPV plugin, just feed it a playlist.

    At the end my final setup would be, that I have several IPTV channels, all targeting the same HDMI source, but I want to execute some scripts depending on which IPTV channel is chosen to make some adjustments. Plus I want to record the stream of the HDMI input. So yes, somehow I need channels in VDR to distinguish the setups and be able to record it via the VDR mechanisms.

  • [gelöst]HDMI Eingang als Kanal

    Habe nun basierend auf http://www.vdr-wiki.de/wiki/index.php/Iptv-plugin eine vlcstream.sh im conf/plugins/iptv-Verzeichnis angelegt. Dabei als Stream-Link beim VLC Aufruf natürlich http://192.168.0.12/live/stream.m3u8 eingegeben. Datei sah somit so aus:


    Bash
    #!/bin/sh
PARAMETER1="$1"
PORT="$2"
exec sudo -u vdr vlc "http://192.168.0.12/live/stream.m3u8" --sout "#transcode{vcodec=mp2v,acodec=mpga,vb=2400,ab=320}:standard{access=udp,mux=ts{pid-video=1,pid-audio=2,pid-spu=3},dst=127.0.0.1:$PORT}" --intf dummy

    Das sudo musste ich ergänzen, da ich den Test mit meinem Odroid mache und dort VDR unter root laufen muss, gleichzeitig vlc aber standardmässig nicht unter root läuft.


    Die channels conf entsprechend erweitert um die Zeile LC-channel;IPTV:1:IPTV|EXT|vlcstream.sh|1:P:0:1:2:0:0:1:0:0:0. Bekomme nun beim Umschalten auf den Kanal nur ein "channel not available", im Log steht auch nicht mehr als diese Meldung. Ich habe deshalb in vlcstream.sh dummy-Ausgaben ala "echo $2 >>/tmp/vlc" ergänzt und sehe, dass diese Datei weder angelegt noch ergänzt wird. --> es findet scheinbar gar kein Aufruf statt. Woran könnte das Beispiel aus der Wiki-Seite scheitern? Sucht iptv das Skript ausserhalb seines conf/plugins-Verzeichnis? Leider gibt es momentan nicht mehr Fehlerausgaben.

    Zur Info: starte ich das vlcstream.sh-Skript händisch sehe ich an meinem hls-Server-log, dass er die ts-Dateien nacheinander abruft. Das heisst theoretisch scheint das Skript und der VLC Aufruf nicht falsch zu sein. Nun muss ich nur das vlcstream.sh Skript ans Laufen bringen... Bin für Ratschläge dankbar.

  • [gelöst]HDMI Eingang als Kanal

    So langsam verstehe ich die "Schwarzmahlerei". Habe mich durch einige Dokus/HowTos von vlc und ffmpeg gekämpft und es ist noch nicht zufriedenstellend. Bisherige Erkenntnis:

    • mjpeg-streamer geht nicht für das USB capture device (beschwert sich über empty buffer und läuft dann in einen timeout rein)
    • ffmpeg konnte ein Videoschnipsel aufnehmen, den ich dann per VLC abspielen und an einen nginx (HLS-konfiguriert) senden und von da wieder per VLC abgreifen konnte
    • ffmpeg konnte nicht direkt von /dev/video0 an den nginx streamen (Dequeued v4l2 buffer contains corrupted data (0 bytes)
    • VLC konnte nicht direkt von /dev/video0 an den nginx streamen

    Jetzt habe ich mir mal OBS runtergeladen. Damit ist es mir möglich, in der Ablage des nginx-servers die *.ts Dateien erstellen zu lassen, paralle dazu wurde auch eine .m3u8 playlist erstellt und ich konnte problemlos per VLC auf den stream zugreifen. Ok, ist ein etwas komplizierter Aufbau, aber wenn die Grundlage mal steht, kann man noch optimieren. Da OBS scheinbar auch auf ffmpeg zurückgreift, sollte das am Ende das Ziel sein (ffmpeg -> nginx hls -> client).


    Bevor ich mich daran versuche, die Parameter in ffmpeg zu finden die Frage an die Experten, ob und wie ich eine m3u8-playlist im iptv plugin einbinden kann? Geht das direkt oder nur über den Umweg über externes Skript und darin ffmpeg (oder vlc?) nutzen? Falls direkt, wie müsste der channels.conf-Eintrag aussehen? Die Streamadresse, über die z.B. vlc problemlos abspielt, lautet: http://192.168.0.12/live/stream.m3u8.

  • [gelöst]HDMI Eingang als Kanal

    Zitat von Dr. Seltsam

    Selbst für die von pvrinput unterstützten ivtv/pvrusb2-devices, die bereits einen TS-Stream erzeugen, mussten wir den noch aufwendig zerlegen , fehlende Daten (PAT, PMT, PCR) hinzufügen und den Stream wieder neu zusammensetzen. Da hat mini73 saubere Arbeit geleistet (wie immer :] ). Ohne diese Daten lief es zwar grundsätzlich auch, es gab aber in Verbindung mit dem streamdev-Plugin Probleme.

    Zumindest in meinem Anwendungsfall (da ich eh bzgl. Streamdev-Server noch das Problem mit dem Verbindungsaufbau über Firewall-Grenzen hinweg habe) könnte ich mir jetzt konkret für das HDMI capturen auch vorstellen, dass sich die Clients direkt auf die "IPTV-Quelle" verbinden und somit streamdev nicht notwendig wäre. Ist zumindest einen Versuch zwischen den Jahren wert.

    don-baba bin natürlich an deinen Erkenntnissen interessiert. Ich muss mal schauen, welche Capture-Karte ich kurzfristig habe. Eine AverTV sollte irgendwo noch rumliegen.


    PS: ist das wirklich ein Rand-UseCase? Hätte angenommen, dass einige User etwaige HDMI Devices über VDR-Clients anzeigen lassen wollen... Vielleicht bin ich auch schon zu altmodisch und arbeite noch mit HDMI Eingängen... :D