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

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

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:

Dec 28 14:47:22 odroid vdr: [3680] [softhddev]CreateOsd: left 154, top 621, level 0, using OpenGL OSD support
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]cOglOsd osdLeft 154 osdTop 621 screenWidth 1920 screenHeight 1080
Dec 28 14:47:22 odroid vdr: [3680] switching to channel 2 I-0-2-2 (test)
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]SetPlayMode: 0
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]SetVolumeDevice: 225
Dec 28 14:47:22 odroid vdr: Set Playmode 0
Dec 28 14:47:22 odroid kernel: [ 2489.577424@1] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:22 odroid kernel: [ 2489.577436@1] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:22 odroid kernel: [ 2489.577654@1] spdif_b keep clk continuous
Dec 28 14:47:22 odroid kernel: [ 2489.577661@1] aml_spdif_close
Dec 28 14:47:22 odroid kernel: [ 2489.577742@1] audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Dec 28 14:47:22 odroid kernel: [ 2489.578202@1] aml_spdif_open
Dec 28 14:47:22 odroid kernel: [ 2489.578428@1] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Dec 28 14:47:22 odroid kernel: [ 2489.578906@1] set normal 512 fs /4 fs
Dec 28 14:47:22 odroid kernel: [ 2489.578938@1]      set spdifout clk:6144000, mpll:24576000
Dec 28 14:47:22 odroid kernel: [ 2489.578941@1]      get spdifout clk:6143997, mpll:24575987
Dec 28 14:47:22 odroid kernel: [ 2489.578944@1] aml_dai_set_spdif_fmt , fmt 0x4010
Dec 28 14:47:22 odroid kernel: [ 2489.578946@1] set normal 512 fs /4 fs
Dec 28 14:47:22 odroid kernel: [ 2489.578956@1]      set spdifout clk:6144000, mpll:24576000
Dec 28 14:47:22 odroid kernel: [ 2489.578958@1]      get spdifout clk:6143997, mpll:24575987
Dec 28 14:47:22 odroid kernel: [ 2489.578997@1] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:22 odroid kernel: [ 2489.579004@1] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:22 odroid vdr: [softhddev]Clear: 20ms buffers 0
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]SetVideoDisplayFormat: 1
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]GetSpuDecoder:
Dec 28 14:47:22 odroid vdr: [4065] IPTV streamer thread ended (pid=3680, tid=4065)
Dec 28 14:47:22 odroid vdr: [4063] device 2 receiver thread ended (pid=3680, tid=4063)
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]SetPlayMode: 1
Dec 28 14:47:22 odroid vdr: [3680] [softhddev]SetVolumeDevice: 225
Dec 28 14:47:22 odroid vdr: Set Playmode 1
Dec 28 14:47:22 odroid vdr: set trickspeed to 0
Dec 28 14:47:22 odroid vdr: [4106] device 2 receiver thread started (pid=3680, tid=4106, prio=high)
Dec 28 14:47:22 odroid vdr: [4108] IPTV streamer thread started (pid=3680, tid=4108, prio=high)
Dec 28 14:47:24 odroid kernel: [ 2491.982284@4] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:24 odroid kernel: [ 2491.982293@4] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:24 odroid kernel: [ 2491.982373@4] spdif_b keep clk continuous
Dec 28 14:47:24 odroid kernel: [ 2491.982377@4] aml_spdif_close
Dec 28 14:47:24 odroid kernel: [ 2491.982423@4] audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Dec 28 14:47:24 odroid kernel: [ 2491.982676@4] aml_spdif_open
Dec 28 14:47:24 odroid kernel: [ 2491.982766@4] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Dec 28 14:47:24 odroid kernel: [ 2491.982861@4] set normal 512 fs /4 fs
Dec 28 14:47:24 odroid kernel: [ 2491.982881@4]      set spdifout clk:6144000, mpll:24576000
Dec 28 14:47:24 odroid kernel: [ 2491.982883@4]      get spdifout clk:6143997, mpll:24575987
Dec 28 14:47:24 odroid kernel: [ 2491.982884@4] aml_dai_set_spdif_fmt , fmt 0x4010
Dec 28 14:47:24 odroid kernel: [ 2491.982885@4] set normal 512 fs /4 fs
Dec 28 14:47:24 odroid kernel: [ 2491.982893@4]      set spdifout clk:6144000, mpll:24576000
Dec 28 14:47:24 odroid kernel: [ 2491.982894@4]      get spdifout clk:6143997, mpll:24575987
Dec 28 14:47:24 odroid kernel: [ 2491.982911@4] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:24 odroid kernel: [ 2491.982915@4] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:24 odroid kernel: [ 2491.983525@4] audio_dsp: IEC958_mode_codec= 0, IEC958 type 2 CH PCM
Dec 28 14:47:24 odroid kernel: [ 2491.983526@4] audio_dsp: last mode 0,now 0
Dec 28 14:47:24 odroid kernel: [ 2491.983538@4] audio_dsp: buf=0
Dec 28 14:47:24 odroid kernel: [ 2491.983539@4] audio_dsp: IEC958_mode_raw=0
Dec 28 14:47:24 odroid vdr: pesdemux: pes start code id 0xc0
Dec 28 14:47:24 odroid vdr: pesdemux: new codec 000000 -> 0x15000
Dec 28 14:47:24 odroid vdr: codec: using audio codec ID 0x15000 (mp2)
Dec 28 14:47:24 odroid vdr: codec: audio 'MP2 (MPEG audio layer 2)'
Dec 28 14:47:24 odroid vdr: codec/audio: format change s16p 48000Hz *2 Codec ID 86016 channels
Dec 28 14:47:24 odroid vdr: CAESinkALSA - Use card "hw:0" and set codec format 0
Dec 28 14:47:24 odroid vdr: CAESinkALSA - Set codec for Spdif_b
Dec 28 14:47:24 odroid vdr: CAESinkALSA - Unable to find simple control 'Audio spdif_b format',0
Dec 28 14:47:24 odroid vdr: codec/audio: resample s16p 48000Hz *2 -> s16 48000Hz *2
Dec 28 14:47:24 odroid kernel: [ 2491.987053@4] asoc-aml-card auge_sound: S/PDIF Playback enable
Dec 28 14:47:24 odroid kernel: [ 2492.178700@1] asoc-aml-card auge_sound: S/PDIF Playback disable
Dec 28 14:47:25 odroid kernel: [ 2492.893474@2] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:25 odroid kernel: [ 2492.893483@2] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:25 odroid kernel: [ 2492.893558@2] asoc-aml-card auge_sound: S/PDIF Playback enable
Dec 28 14:47:26 odroid kernel: [ 2493.661200@1] asoc-aml-card auge_sound: S/PDIF Playback disable
Dec 28 14:47:26 odroid kernel: [ 2493.998172@4] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Dec 28 14:47:26 odroid kernel: [ 2493.998181@4] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Dec 28 14:47:26 odroid kernel: [ 2493.998259@4] asoc-aml-card auge_sound: S/PDIF Playback enable
Dec 28 14:47:26 odroid kernel: [ 2494.405904@1] asoc-aml-card auge_sound: S/PDIF Playback disable
Dec 28 14:47:27 odroid kernel: [ 2494.781667@4] fb: clear: osd 0
Dec 28 14:47:27 odroid kernel: [ 2495.001432@4] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200

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.

Zitat von don-baba

Ja das wäre auch ein Witz. Der Caja Dateiexplorer sagt mir auch es handele sich um einen MPEG-2-Transportstrom.
Da der Caja aber auch nur TS Endungen als MPEG-2 kennt...

Wenn ich die Aufnahme aber im vlc öffne sagt er mir als Stream 0 "Codec: H264 - MPEG-4 AVC (part 10) (h264)"

Auch Kodi sagt mir bei den Aufnahmefetzen es seien h.264er Dateien.

Ich glaube wenn man über die Kabelpeitsche analog aufnehmen möchte dann macht er das als MPEG-2...?

Die tests kommen aber frühestens nächste Woche.

Alles anzeigen

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

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.

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.

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.

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:

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:

Feb 19 20:39:37 odroid vdr: [4512] switching to channel 42 C-0-1-1 (HDMI)
Feb 19 20:39:37 odroid vdr: [4757] device 2 receiver thread ended (pid=4512, tid=4757)
Feb 19 20:39:37 odroid vdr: [4518] SATIP-ERROR: bool cSatipFrontends::Attach(int, int) no Frontend found for attaching deviceID 0 (TP 114)
Feb 19 20:39:37 odroid vdr: message repeated 2 times: [ [4518] SATIP-ERROR: bool cSatipFrontends::Attach(int, int) no Frontend found for attaching deviceID 0 (TP 114)]
Feb 19 20:39:37 odroid vdr: [4512] [softhddev]SetPlayMode: 1
Feb 19 20:39:37 odroid vdr: [4512] [softhddev]SetVolumeDevice: 68
Feb 19 20:39:37 odroid vdr: Set Playmode 1
Feb 19 20:39:37 odroid vdr: set trickspeed to 0
Feb 19 20:39:37 odroid vdr: [4760] device 3 receiver thread started (pid=4512, tid=4760, prio=high)
Feb 19 20:39:39 odroid kernel: [ 2030.035982@0] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Feb 19 20:39:39 odroid kernel: [ 2030.035994@0] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Feb 19 20:39:39 odroid vdr: pesdemux: pes start code id 0xc0
Feb 19 20:39:39 odroid vdr: video: not detected
Feb 19 20:39:39 odroid kernel: [ 2030.036576@0] spdif_b keep clk continuous
Feb 19 20:39:39 odroid kernel: [ 2030.036584@0] aml_spdif_close
Feb 19 20:39:39 odroid kernel: [ 2030.038617@1] audio_ddr_mngr: frddrs[0] released by device ff642000.audiobus:spdif_b
Feb 19 20:39:39 odroid kernel: [ 2030.039026@1] aml_spdif_open
Feb 19 20:39:39 odroid kernel: [ 2030.039295@1] audio_ddr_mngr: frddrs[0] registered by device ff642000.audiobus:spdif_b
Feb 19 20:39:39 odroid kernel: [ 2030.039493@1] set normal 512 fs /4 fs
Feb 19 20:39:39 odroid kernel: [ 2030.039526@1]          set spdifout clk:6144000, mpll:24576000
Feb 19 20:39:39 odroid kernel: [ 2030.039528@1]          get spdifout clk:6143997, mpll:24575987
Feb 19 20:39:39 odroid kernel: [ 2030.039531@1] aml_dai_set_spdif_fmt , fmt 0x4010
Feb 19 20:39:39 odroid kernel: [ 2030.039533@1] set normal 512 fs /4 fs
Feb 19 20:39:39 odroid kernel: [ 2030.039544@1]          set spdifout clk:6144000, mpll:24576000
Feb 19 20:39:39 odroid kernel: [ 2030.039545@1]          get spdifout clk:6143997, mpll:24575987
Feb 19 20:39:39 odroid kernel: [ 2030.039584@1] spdif_info: rate: 48000, channel status ch0_l:0x100, ch0_r:0x100, ch1_l:0x200, ch1_r:0x200
Feb 19 20:39:39 odroid kernel: [ 2030.039592@1] aml_spdif_fifo_ctrl, bit depth:16, frddr type:1, toddr:type:1
Feb 19 20:39:39 odroid kernel: [ 2030.048000@0] audio_dsp: IEC958_mode_codec= 0, IEC958 type 2 CH PCM
Feb 19 20:39:39 odroid kernel: [ 2030.048004@0] audio_dsp: last mode 0,now 0
Feb 19 20:39:39 odroid kernel: [ 2030.048030@0] audio_dsp: buf=2
Feb 19 20:39:39 odroid kernel: [ 2030.048032@0] audio_dsp: IEC958_mode_raw=2
Feb 19 20:39:39 odroid vdr: pesdemux: new codec 000000 -> 0x15002
Feb 19 20:39:39 odroid vdr: codec: using audio codec ID 0x15002 (aac)
Feb 19 20:39:39 odroid vdr: codec: audio 'AAC (Advanced Audio Coding)'
Feb 19 20:39:39 odroid vdr: codec/audio: format change fltp 48000Hz *2 Codec ID 86018 channels AC-3 pass-through
Feb 19 20:39:39 odroid vdr: CAESinkALSA - Use card "hw:0" and set codec format 0
Feb 19 20:39:39 odroid vdr: CAESinkALSA - Set codec for Spdif_b
Feb 19 20:39:39 odroid vdr: CAESinkALSA - Unable to find simple control 'Audio spdif_b format',0
Feb 19 20:39:39 odroid vdr: codec/audio: resample fltp 48000Hz *2 -> s16 48000Hz *2
Feb 19 20:39:39 odroid vdr: video: not detected
Feb 19 20:39:40 odroid kernel: [ 2030.466259@1] asoc-aml-card auge_sound: S/PDIF Playback enable
Feb 19 20:39:42 odroid kernel: [ 2032.677305@0] fb: clear: osd 0

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?

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.

Zitat von blau

Aber Joe_D hat hier geschrieben (Zitat):

"Ist der tvheadend Sat>IP-Server "ganz normal" mit VLC erreichbar?

Bei VLC unter "Ansicht" -> "Wiedergabeliste" unter "Lokales Netzwerk" -> "Universal Plug'n'Play"??

Normale SAT>IP-Server werden dort sichtbar, man kann dann einfach die Liste der Kanäle anklicken. So mal als ersten Test.

Ansonsten ist Wireshark ein gutes Tool um zu schauen was zwischen SAT>IP-Server und satip-Plugin hin und hergeht.

Oder das Logging erweitern, da muss man aber die satip-Plugin Experten fragen..."

Hast du schon versucht, ob VLC den tvheadend Sat>IP-Server sehen kann?

Alles anzeigen

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.

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

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