Unverschlüsselte Multicast-Kanäle mit anderen Geräten empfangen (Wiki)

Hallo!
Ich habe eine Frage bzgl. der unverschlüsselten Sender auf meinen Panasonic-TVs.
Bisher war es so, dass ich die Entertain-Streams am TV empfangen konnte.
Die funktinieren bekanntlich nicht mehr.
Das Problem ist nun, dass meine Panasonic-TVs offenbar mit den neuen Streams nicht zurechtkommen. Im Sendersuchlauf wird einfach kein Sender gefunden (habe ich wie vorher auch auf dem USB-Stick eingetragen, nur mit den neuen Adressen).
Hat jemand Erfahrung oder kann einen Tipp geben, damit wieder am TV der Stream empfangen wird?
Gruß,
Mark

Hat von euch jemand ffmpeg-basiert (das ist Kodi PVR IPTV Simple Client - also ohne Umweg über tvh, enigma2, u.U tvheadend mit ffmpeg-pipe, oder halt ffmpeg auf der Kommandozeile) die neuen Adressen hell gekriegt? Bei mir immer nur exakt 2 Minuten 10 Sekunden. Außer gleichzeitig läuft der Stream im Receiver oder auf VLC. Viele Konfigurationen habe ich hier beschrieben https://www.kodinerds.net/index.php/Thread/68436-MagentaTV-unter-Kodi-Tvheadend-VLC-ffmpeg-Enigma2/?postID=567706#post567706

Eine Lösung habe ich nicht ganz, aber paar möglicherweise hilfreiche Beobachtungen:

#NAME Magentatv
#SERVICE 5002:0:19:2B5C:41B:1:FFFF0000:0:0:0:rtp%3a//@232.0.20.35%3a10000?sources=87.141.215.251:Das Erste HD
#DESCRIPTION Das Erste HD
#SERVICE 5002:0:1:6DCA:44D:1:FFFF0000:0:0:0:rtp%3a//@232.0.10.35%3a10000?sources=87.141.215.251:Das Erste
#DESCRIPTION Das Erste
#SERVICE 5002:0:19:2B66:437:1:FFFF0000:0:0:0:rtp%3a//@232.0.20.234%3a10000?sources=87.141.215.251:ZDF HD
#DESCRIPTION ZDF HD

Wird bei mir für ca. 2 Minuten hell, dann dunkel (oder halt, wie schon oben beschrieben, der Stream läuft noch anderswo). Hängt vielleicht von der E2-Distribution ab, aber der Stream-Typ 1 bei dir (bei mir 5002) wundert mich, ist normalerweise für „pures TS“ reserviert. Die anderen Ziffern oben vor der UrL sind nicht ganz so entscheidend - die von mir genutzten passen auf Vodofone Kabel-Anschuss: mit denen wird dann zum Seender im Kabelnetz veknüpft, beispielsweise für EPG. Bei meiner Distribution steht die 5002 für „Service-App nutzen“ wohinter sich ffmpeg verbirgt.

Ja, das geht. Hat halt den Nachteil, dass noch ein Server immer im Hintergrund mitlaufen muss, und dass der gesamte Netztraffic erhöt wird. In dem Zusammenhang noch eine Beobachtung: VLC läuft im LAN einwandfrei mit den neuen Adressen. Im WLAN kriege ich auch alle 2 Minuten Abbruch wie bei ffmpeg. Klar, WLAN ist nix wird man gleich sagen … Aber, gehe ich auf tvh von VLC aus ist alles stabil, auch im WLAN (und wohlgemerkt ohne Transkodierung der Nutzdaten in tvh, tvh ist im LAN). Ich weiß, dass früher auch mit VLC stabil im WLAN auf die Streams zugreifen konnte. Bin mir leider nicht mehr sicher, ob das jetzt temporäre Phänomene sind oder ob das mit der Umstellung der Adressen zusammen hing.
Habe mir die SSM RFC mal angesehen - das ist keine leichte Kost, wenn man bislang nur einfache Sockets programmiert hat. Frage mich überhaupt: Macht das ganze Handling das OS oder die Anwendung?

Noch ne weitere Beobachtung: vlc nimmt auch das Format
rtp://@232.0.20.35:10000?sources=87.141.215.251 Dann kriege ich auch im LAN nach 2 Minuten Abbruch.

interessante Beobachtungen, dass die ffmpeg Syntax mit sovielen Clients funktioniert… probier mal ob es dann auch mit udp:// statt rtp:// besser klappt.

1 „Gefällt mir“

So, jetzt noch mal vom PC eine etwas längere Antwort

Das macht alles das Betriebssystem. Socketseitig musst du nur eine andere Socketoption mit anderem struct nutzen und die Source Adresse mit angeben.

Deshalb ist das ffmpeg Verhalten ja auch so ungewöhnlich. Das rtp Modul scheint den Join schon richtig zu machen, stellt dann aber nach ein paar ms zurück auf das klassische Multicast ohne Source-Option. Von den Logs ausgehend sieht es irgendwie so aus, als würde der intern noch mal eine SDP bauen - dort fehlt die Source Option - und dann auf diese umstellen :man_shrugging:

Was die anderen Clients angeht (und auch das VLC via WLAN) müsste man vielleicht auch einfach mal mit tcpdump/Wireshark schauen, was da igmp-mäßig abläuft. Wenn nach 2:10min Schluss ist, kommen entweder die IGMP Queries beim Client nicht an, er beantwortet sie nicht oder die Antworten kommen beim Router nicht an. Aber wie gesagt, diese zu beantworten ist alles Sache des Betriebssystems. Nur wenn die Software dem Betriebssystem sagt „IP_ADD_MEMBERSHIP“, dann nimmt es die Source Option raus - sofern sie vorher vorhanden war - und dann funktionieren die neuen Streams meist nicht mehr (Ausnahmen gibts allerdings, wenn der DSL Router, MSAN und der BNG kein Problem damit haben auch IGMPv3 Requests ohne SSM zu bearbeiten).

1 „Gefällt mir“

Bingo! Danke sehr - auch für die ausführliche Antwort. Wie bist du drauf gekommen?

Also auf Linux mit Kommandozeile:

ffmpeg -i udp://@232.0.20.35:10000?sources=87.141.215.251 -map 0 -c copy -copy_unknown -f mpegts d.ts

Ein-Stündige Aufnahme gemacht - schein perfekt funktioniert zu haben. Unter Windows scheint es auch zu gehen.

Enigma2: Geht mit Service-Typ 5002 in meiner Box. Dazu muss die sogenannte Serviceapp installiert sein.

Wer will, kann mal Anlage probieren. Basiert auf älterer Liste von hier (allerdings Reihenfolge nach meinem Gusto), habe nur mal neue Sender hinzugefügt (Voxup), aber keinen kompletten Abgleich gemacht mit der aktuellen Liste. Ist optimiert für Vodafone Kabel (dann werden Logos und EPG richtig angezeigt). Bei Bedarf kann ich das auch für Astra liefern, wenn mir jemand seine lamedb zur Verfügung stellt.
userbouquet.magentatv.tv.zip (1,6 KB)

VLC: udp…sources geht nicht (rtp…Sources-2min10) - Aber da geht ja die normale rtp-Methode

Kodi PVR Simple IPTV Client: muss ich noch genauer testen. Brach jetzt nach 2 Minuten ab.
EDIT: Kodi geht wohl nicht mit PVR Simple IPTV Client, obwohl da auch ffmpeg genutzt wird. Hängt vielleicht von Version/Kompilier-Optionen ab. Was ich sah, war wohl wegen parallelen Tests mit gleichem Stream. Kodi mit tvheadend und entsprechendem Kodi-Client funkt natürlich.

Die ausführlichere Antwort muss ich mir mit Ruhe zu Gemüte führen. Kennt von euch jemand das Ähnliche Problem mit vlc im WLAN. Am Rechner wird es kaum liegen - Kabel rein, und es geht. (Wie gesagt, liegt es auch nicht an der WLAN-Bandbreite, über tvh geht es ja perfekt.) Mein Router: Speedport W921V.

Im Grunde durch ausprobieren. Man sieht relativ schnell ob es funktioniert, wenn man tcpdump nebenher laufen lässt und auf igmp filtert.

# tcpdump -i eth0 -v igmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
### Start: IGMP Join
18:21:56.827701 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 56, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 2 group record(s) [gaddr 232.0.10.35 allow, 1 source(s)] [gaddr 232.0.10.35 to_in, 1 source(s)]

### regelmäßiger IGMP Query von der FB an alle
18:22:10.021704 IP (tos 0xc0, ttl 1, id 50113, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
### Antwort vom Server
18:22:11.983454 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]
### ggf. noch weitere Antworten von anderen Rechnern im Netz und andere Gruppen

### und dann dreht sich das im Kreis im Minutentakt
18:23:10.022433 IP (tos 0xc0, ttl 1, id 55524, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:23:17.387212 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

18:24:10.023816 IP (tos 0xc0, ttl 1, id 56711, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:24:10.459478 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

18:25:10.027621 IP (tos 0xc0, ttl 1, id 59829, offset 0, flags [DF], proto IGMP (2), length 36, options (RA))
    fritz.box > all-systems.mcast.net: igmp query v3
18:25:11.975507 IP (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 60, options (RA))
    192.168.2.4 > igmp.mcast.net: igmp v3 report, 3 group record(s) [gaddr 232.0.10.35 is_in, 1 source(s)] [gaddr 224.0.0.251 is_ex, 0 source(s)] [gaddr 239.255.255.250 is_ex, 0 source(s)]

Habe dann auch mal neben dem relativ alten ffmpeg, das bei Ubuntu dabei ist, aus dem github Master eine neue Version gebaut - verhält sich aber genauso.

1 „Gefällt mir“

Bin leider nicht so tief im Thema wie Du, daher jetzt mal die für Dich vermutlich dumme Frage: Was muss ich auf meiner Dream nachinstallieren und ggfs. starten, dass ffmpeg als Service 5002 bentutzt wird?

Wenn ich in der bisherigen Syntax „rtp“ mit „udp“ ersetze (siehe meinen alten Beitrag) und der Stream gleichzeitig woanders läuft, bekomme ich massive Bildruckler und Klötzchenbildung, was auf ein hohe Auslastung der CPU bzw. des Netzwerkes hinweise würde, kann ich mir aber nicht vorstellen.

Gruss -LERNI-

Bei echter Dreambox kann ich leider nicht mit reden. Wenn das vorher (alte Adressen) bei dir geklappt hat mit Service-Typ 1, kannst ja mal meine Anlage aufmachen und mit Editor deiner Wahl (z.B. Notepad) alle 5002 ersetzen durch 1. Vielleicht geht es dann von Natur aus auf der Dreambox.
Auf meiner open Enigma basierten Box geht es nicht mit 1, nur mit 5002. Zu finden unter Menü->Einstellungen->System->Serviceapp, wo man Serviceapp konfigurieren kann (ich musste es aber nur aktivieren, wenn ich mich recht entsinne).
Sonst Mal in Dream Forum nachfragen.

1 „Gefällt mir“

Ich glaub eher, dass der dann wirklich meint es ist direkt UDP. War früher beim VLC auch so und ich bin selbst erstaunt, dass ffmpeg sich nicht auch so verhält - das ist eher „Glückssache“ (oder intern wird der gleiche Decoder verwendet, der eben auch den RTP erkennt). Der Client muss den RTP Header zumindest entfernen. Wenn er es direkt als MPEG interpretiert, hast du durch den Header immer wieder Datenmüll drin und dann kommt es eben zu den Störungen, weil ein MPEG Decoder damit nichts anfangen kann.

2 „Gefällt mir“

Habe ich natürlich schon probiert, aber ohne Erfolg. Wenn in das richtig sehe, ist „ffmpeg“ in dem „gstreamer“-Plugin integriert und es bedarf vermutlich keiner separaten Installation. Trotzdem, alle Versuche, die Syntax auf die neuen Adressen anzupassen sind bisher gescheitert. Wenn ich mit Wireshark trace, kann ich auch erkennen, dass die Dreambox immer nur „any Source“ ins Internet schreit und natürlich keine Antwort bekommt:


Hingegen klappt es mit dem VLC auf dem PC problemlos, da wird die Anfrage korrekt abgesetzt und beantwortet:

Entweder kann es der „gstreamer“ tatsächlich nicht, oder die Syntax stimmt nicht.

Gruss -LERNI-

Bei mir ist das noch was anderes als gstreamer. Siehe:


(Was jetzt hervorgehoben ist, soll nix bedeuten). Du siehst die Nummern 5001 und 5002. Bei mir laufen die Streams mit 5002. GstPlayer liegt auf 5001. Meines Wissens liegt die native IPTV-Abspiellogik auf 4097. Kannst ja mal die ersten 7 Sender von 4097 bis 5003 durchnummerieren nach #SERVICE.

Nachdem was @Grinch gesagt hat, wird die 1 (die jedenfalls bei mir nur bei echtem ts funktioniert) wohl auch bei dir kaum gehen. Hatte allerdings verstanden, dass das bei dir mit den alten Entertain-Streams ging?

Danke, mit udp, das war der richtige Gedanke. Jetzt läuft alles wunderbar und weder Bild noch Ton ruckeln.:medal_sports::grinning:

AVM hat das Verzeichnis 1/ schon mal aktualisiert:
http://download.avm.de/tv/
Die noch fehlenden Sender haben sie aber (noch?) nicht aufgenommen.

http://download.avm.de/tv/tv1.html
sollte wieder funktionieren.

Kleines Update für Enigma2-Benutzer, sofern ihre Box “ServiceApp” auf Stream-Typ 5002 unterstützt.

  1. Optimiert für Astra 19.2 Nutzer

userbouquet.magentatv.tv.astra192e.zip (1,5 KB)

  1. Optimiert für Vodafone Kabel Nutzer

userbouquet.magentatv.tv.vfkabel.zip (1,6 KB)

Optimiert heißt, dass die Programm-Logos und EPG auch funktionieren sollten. Sonst funktionieren die Sender auch, halt ohne Logos/EPG wenn man nicht weiteren Aufwand treibt

@lerni, falls du in Dreambox Forum mit Entwickler-Beteiligung unterwegs bist: das sollte für die Entwickler dort kein Problem sein. Ausgehend von den Links oben von @Grinch und insbesondere von http://wiki.wlug.org.nz/SourceSpecificMulticastExample konnte ich in weniger als 60 Minuten ein einfaches Programm schreiben, das die Streams empfängt und als funktionierendes .ts abspeichert. Wenn du Entwickler auf den Link hinweist, sollte er doch Interesse haben.

Dass ffmpeg mit udp statt rdp funktioniert erkläre ich mir so: Die Streams senden verlässlich einen 12-Byte langen rtp-Header, der in ts natürlich falsch ist und weg muss. Da der aber nicht mit dem ts-Kenner anfängt (0x47) wird da irgendwo ne Logik sein, die Garbage überspringt, bis der Anfang erkannt wird (und vermutlich noch prüft, ob auch 188 Bytes weiter wieder 0x47 steht, etc.).

Dass ffmpeg mit rtp überhaupt 2 Minuten funktioniert, kann ich mir nicht erklären. Sehe da auf Anhieb keinen Code, der SSM vollzieht. (Bei udp in ffmpeg sehr wohl).

Und jetzt, wo es so leicht war, die Streams mit eigenem Programm zu “empfangen”, wollte ich auch den Verbindungs-Abbrüchen bei vlc im WLAN nachgehen. Was soll ich sagen - die passieren nicht mehr :slight_smile: Kann mir aber wirklich nicht vorstellen, dass es nur ganz direkt am WLAN lag, da ja tcp auf tvheadend ging. Und UDP/rtp sollte sehr viel unempfindlicher sein als tcp.

3 „Gefällt mir“

Im Rahmen von Bemühungen der Mithilfe, die neuen SSM Streams in Kodi zum Laufen zu kriegen (ohne tvheadend) noch eine Beobachtung, die auch insbesondere für dich @lerni interessant sein könnte. Kodi nutzt in Wirklichkeit ja auch ffmpeg als Decoder genauso wie mein E2-Receiver. Vielleicht ist das bei deiner dreambox auch nicht anders. Wenn ich ffplay (das ist das Darstellungsprogramm aus der ffmpeg-Suite) von alten ffmpeg-Distributionen nutze, erhalte ich auch solche Darstellungsfehler, wie von dir beschrieben.

manchmal auch die typischen grünen Fehler oder sowas

Mit aktuellen ffmpeg-Versionen passiert das nicht. Vielleicht hast du die Chance auf Update?

Plausible Erklärung für die Fehler hat @Grinch geliefert.

Hallo @bit
Zur Zeit habe ich nicht so viel Zeit, mich um meine Dream zu kümmern. Im Dreamboxforum hat man mir keine Hoffnung gemacht, dass da noch was kommen wird, sondern geraten, auf openATV zu wechseln.

Das ist aber ein größerer Akt und den muss ich zurück stellen, bis meine “Regierung” für längere Zeit ausfällt. Da steht in Kürze ein leider längerer KKH und Reha-Aufenthalt an, dann werde ich das mal angehen.

OT.
Zur Zeit mache ich fast nur noch Upgrades von Win7 auf WinX bei allen Bekannten und Verwandten, eine eher undankbare Aufgabe. Außerdem muss ich meinen SBS2011 noch upgraden, der bekommt ja inzwischen auch keine SecurityUpdates mehr.

Hier noch der Link zum Dreambox-Forum:

Finde es aber Klasse, wie Du Dich hier reinhängst.

VG aus der schönsten Stadt der Welt.

LERNI-

1 „Gefällt mir“

Gibt es hier im Forum auch eine Programmier-Ecke oder Ähnliches?

Ja, genauso sehe ich das jetzt im ffmpeg Quellcode. Kann ffmpeg Quellcode auch so manipulieren, dass es nach Erstellen der binaries mit rtp funktioniert für die MagentaTV-Streams. Einen guten Patch habe ich noch nicht. Vielleicht gibt es ja jemanden mit Interesse hier, oder gar jemanden, der ffmpeg Quellen gut kennt. Will aber den Wiki-Artikel hier nicht durch Programmier-Diskussion überfluten. Da hier allerdings genau der richtige Kontext steht, halt die Anfrage erstmal hier. Und mit den ffmpeg-Entwicklern direkt kann man sich leicht schwer tun. Sicherlich wird man dort auch kaum jemanden finden, der das mit MagentaTV testen kann.

Falls es interessiert, Kodi funktioniert bei mir nun mittlerweile auch mit den MagentaTV Streams ohne tvheadend mittels des „UDP-Tricks“ auf meinem Linux-System. Meine Kodi-Installation auf Windows möchte ich im Moment nicht riskieren … https://forum.kodi.tv/showthread.php?tid=350901

Eine Programmierecke gibts nicht - glaube dazu ist der Bedarf hier zu gering :wink: Aber es spricht ja nichts dagegen einen Thread dazu zu öffnen. Spontan würde ich sagen in der Kategorie MagentaTV - auch wenn es prinzipiell andere IPTV Anbieter mit SSM betrifft. Davon ist mir hier aber noch keiner über den Weg gelaufen :sweat_smile: