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.
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.
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 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
Da es thematisch hier wohl am ehesten passt, möchte ich kurz auf mein Projekt IPTV-ReStream aufmerksam machen: Da ich zu Hause MagentaTV verwende, aber oft nicht dort bin, aber dennoch die Streams schauen möchte, habe ich mir das mal genauer angeschaut und ein nun endlich fertiges Programm gebastelt.
TL;DR: Es ermöglicht das Schauen der MagentaTV Sender (aus der Senderliste von Grinch) von überall.
Intern funktioniert es praktisch wie udpxy und abonniert - wie der Mediareceiver oder VLC - einen Sender über SSM. Diese Daten werden dann in HTTP eingepackt und können dort abgerufen werden, wo sie benötigt werden. Um die Nutzung noch etwas zu vereinfachen, habe ich noch ein kleines Webinterface mit Status, Datendurchsatz, etc. und eine Senderliste für VLC integriert.
Verfügbar ist IPTV-ReStream auf GitHub, inkl. Installationsanleitung
Moin c1xx,
freut mich sehr, wenn ich dir mit meinem Projekt helfen konnte .
Für beide Fragen gilt: Ich gehe davon aus, habe es aber selbst nicht getestet.
Da die Anwendung ziemlich schlank ist, sollte es ohne Probleme auf dem Raspberry Pi laufen. Falls du es mal testen möchtest, bin ich gespannt auf dein Feedback.
Unter Windows (bzw. auch macOS) sollte es auch laufen, allerdings klappt es dort nur ohne Docker, da es dort das Host-Networking von Docker nicht unterstützt wir
Gerne helfe ich dir weiter, aber ich würde vorschlagen, dass - um den Thread hier nicht zu sehr in die Länge zu ziehen - die Konversation auf GitHub als Issue oder per privater Nachricht weiterführen
Es gibt ein paar Neuigkeiten, bzgl. des Supports der SSM-Technologie der aktuellen MagentaTV-Kanäle in bekannten Programmen. (Nicht ganz ohne Stolz - hatte auch nach Hinweisen aus dem Forum hier Patch für ffmpeg erstellen können.)
ffmpeg - In aktuellen nightly builds für Windows funktionieren die Streams. Eine Aufnahme ist beispielsweise möglich mit:
Mit Kodi soll es in aktuellen nightly builds auch funktionieren. Habe das allerdings nur mit selbst kompiliertem Kodi probiert, bisher. Kodi nutzt halt auch die ffmpeg Infrastruktur. Der Patch zu ffmpeg wurde aus der Kodi-Diskussion heraus initiiert.
Es gibt viele andere Programme, die intern ffmpeg nutzen. Wird sich sicher auch dahin fortpflanzen.
„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.“
Genau so war es. In den Tiefen des ffmpeg Source-Codes war es durchaus gut versteckt …
Nein, in den offiziellen Releases von Kodi und ffmpeg funktioniert es noch nicht. Mit den nächsten zu erwartenden offiziellen Versionen Kodi 19.0 und ffmpeg 4.3 sollte es aber auf Anhieb gehen,
Kurzes Update. Kodi 19.0 ist mittlerweile offiziell erschienen, die unverschlüsselten Multicast-Kanäle funktionieren bei mir einwandfrei. Ein nützlicher Trick - wenn man im Kodi PVR IPTV Simple Player die neu Option „Enable Timeshift“ nutzt, funktionieren die Multicast-Kanäle nicht ohne weiteres. Man muss Kodi etwas unter die Arme greifen, durch eine Zeile „#KODIPROP:inputstream.ffmpegdirect.open_mode=ffmpeg“ vor jeder#EXTINF-Zeile, die sich auf einen rtp Stream bezieht, also z.B.:
#KODIPROP:inputstream.ffmpegdirect.open_mode=ffmpeg
#EXTINF:-1 tvg-name="SWR RP HD" tvg-id="SWR-rp.de" group-title="Regional;HDVariante" radio="false" tvg-logo="swrhd.png",SWR Rheinland-Pfalz HD
rtp://87.141.215.251@232.0.20.203:10000
Möglicherweise wird das in einem Update noch bequemer gemacht (in dem Kodi direkt erkennt, dass für rtp:// das ffmpeg Modul genutzt werden soll).
ffmpeg 4.3 als eigenständiges Programm ist schon seit längerem offiziell, man braucht nicht mehr die nightly builds für den Support der SSM Streams.
für mich ist das ein neues Thema, hoffe, jemand kann mich auf die richtige Hilfestellung lenken. Etwas zu viele Posts für mich, um das richtige zu extrahieren:
Ich habe im Juni Telekom VDSL50 abgeschlossen inkl. MagentaTV Basic. Ich habe leider keinen Receiver erhalten und befürchte, der ist nicht inklusive in dem Tarif. Jetzt möchte ich dennoch für meine 5€-Aufpreis MagentaTV schauen und bekomme es mit VLC-Player und Fritzbox 7490 nicht hin.
Ich habe sowohl die LiveTV Funktion der Fritzbox benutzt als auch die IPTV Playlist.xspf herunter geladen und mit der neusten Version des VLC-Players (Version 3.0.16 Vetinari (Intel 64bit) auf dem Mac) geöffnet.
Leider bleibt das Bild bei den privaten Sendern nach 1s stehen (Ton läuft weiter). Die öffentlich rechtlichen laufen hingegen problemlos. Auch über LAN bleibt das Problem erhalten.
Würde ich über eine Hilfestellung freuen.
Danke und viele Grüße
JJ
Danke @Kurz, das hat leider nicht geholfen. Habe lediglich „Wi-Fi“ Netzwerkkarte übrig gelassen, da sonst gar keine Verbindung besteht. Habe ebenso vergeblich das auf einem zweiten Mac das ausprobiert. Auf dem zweiten Mac lässt sich überhaupt gar nichts abspielen. Weder mit der IPTV Playlist noch mit der Fritzbox-Live-TV-Playlist.
Also was mich irritiert, ist dass die ÖRs funktionieren und dass das Bild nach einer Sekunde stehen bleibt und der Ton weiterläuft. Denn dann scheint der Multicast an sich ja anzukommen - sonst käme gar nichts, keine Sekunde und auch kein Ton.
Nur warum dann gerade die Privaten stehen bleiben? Technisch sind die meiner Meinung nach identisch (mal davon abgesehen, dass es die Privaten nur in SD unverschlüsselt gibt - aber ich nehme an die ÖR in SD laufen auch?)
Also es klingt wirklich mehr nach einem Problem des VLC. Kannst du beim VLC mal die „Werkzeuge - Meldungen“ aktivieren? Vielleicht steht da was sinnvolles drin?
Also spannend ist ja, dass es nur die Privaten betrifft… Ich würde eigentlich auch die ÖR in SD erwarten. Dann könnte es nämlich am Deinterlacer liegen