DVBViewer SAT>IP verwendung von x_pmt

[FreakyJ]

Hallo alle zusammen!

 

Ich bin Tester bei TeamMediaportal, programmiere aber auch ein bisschen

Ich habe für MP TVE3.5 einen SAT>IP und UPnP Server geschrieben und auch den von DD bekannten x_pmt Parameter implementiert.

Leider sendet DVBViewer Pro v5.3.1.0 den Parameter nur bei Erkennen des Octopus Nets :/

 

Ich konnte DVBViewer dennoch dazu bringen diesen Parameter auch an MP zu senden, indem ich mit WinMerge geschaut habe was in der config geändert wurde und das auf das RTSP Device von meinem MP SAT>IP Server übertragen habe:

<entry name="RTPUseTCP">1</entry>
<entry name="isRS">2</entry>

Ich weiß nicht was isRS bedeutet?! auf jeden Fall ändert es irgendwie die Bedeutung von RTPUseTCP was dann für 0="kein CI", 1="Beliebiges CI", etc. steht...

 

Ist es möglich, dass man diese Option auch für andere SAT>IP Server verfügbar macht? Z.B. Wenn "Has Ci" aktiviert ist, dass dann einfach der x_pmt Parameter angehängt wird? Oder würde sich das mit den Softcams dann in die quere kommen (weiß nicht wie sich DVBViewer hier genau verhält)?

Ich würde mich darüber sehr freuen Unsere neue TVE3.5 dauert zwar noch ein bisschen, wird aber bestimmt kommen xD Und wie ich gelesen habe soll es den DVBViewer ja bald auch für IOS/Android geben, unsere User würden sich bestimmt freuen einen weiteren Client für ihr Tablet zu haben^^

 

Viele Grüße und macht weiter so mit der guten Arbeit

[nuts]

Moin,

 

doofe Frage zu Beginn: Wozu benötigt dein Server den X_pmt Parameter?

 

Zu den Einträgen: RTPUseTCP 0/1 ist eine reine RS / DVBViewer Geschichte um TCP anstatt UDP zu verwenden (mit TCP hat dein Server nix am Hut oder?). Eher historisch bedingt, da UDP teilweise Probleme verursacht hat.

 

"isRS" puh da wird's schon schwieriger (bin unterwegs und kann nicht schauen).

O= beliebiger Sat>IP Server

1= Recordingservice als Sat>IP Server (=> u.a. Custom Parameter für verschlüsselte Sender)

2= Octopus Net ( x_pmt Gedöns)

Vielleicht?

Ist jetzt aber nur geraten.

 

In dem Fall dürfte es ja erstmal reichen die XML anzupassen? Vielleicht kann man deinen Server dann nach dem Release in die Autoerkennung aufnehmen?

[FreakyJ]

Hey,

 

ersteinmal vielen lieben Dank für die schnelle Antwort

 

 

Wozu benötigt dein Server den X_pmt Parameter?

 

Den benötigt er nur, wenn MP den Sender serverseitig entschlüsseln soll. Das Problem ist, dass MP ja sein eigenes card management hat und die Karten nicht ganz aus der Hand gibt wie es ein SAT>IP Server eigentlich tut, also musste ich etwas darum arbeiten.

Normal bekomme ich über SAT>IP die Frequenz, das System (DVB-X) und die Pids. Nun schlage ich in einer Datenbank nach und nehme den erst besten Sender und tune den. Im Filter Graph von MP häng mein eigener Filter über ein infinite teefilter Parallel, welcher nun den ganzen Transportstrom bekommt, macht sein eigenes PID filtering und sendet die Daten dann zum Client^^

x_pmt hilft mir dann genau die richtigen Tuning details in der Datenbank zu selektieren und somit MP zu veranlassen den Sender dann auch zu entschlüsseln.

 

Das hört sich nun etwas wie ein Hack an gibt aber MP die Möglichkeit mehrere User auf eine Karte zu packen und dabei auch optimal die Aufnahmen zu verwalten und verschiednen Usern unterschiedliche Prioritäten zu geben.

 

 

Zu den Einträgen: RTPUseTCP 0/1 ist eine reine RS / DVBViewer Geschichte um TCP anstatt UDP zu verwenden (mit TCP hat dein Server nix am Hut oder?). Eher historisch bedingt, da UDP teilweise Probleme verursacht hat.

 

Danke Nein mein Server hat mit TCP nichts am Hut

 

 

"isRS" puh da wird's schon schwieriger (bin unterwegs und kann nicht schauen).
O= beliebiger Sat>IP Server
1= Recordingservice als Sat>IP Server (=> u.a. Custom Parameter für verschlüsselte Sender)
2= Octopus Net ( x_pmt Gedöns)
Vielleicht?
Ist jetzt aber nur geraten.

Hehe würde aber passen, auch wenn das ebenfalls etwas nach einen "Workaround" klingt xDD

 

 

In dem Fall dürfte es ja erstmal reichen die XML anzupassen? Vielleicht kann man deinen Server dann nach dem Release in die Autoerkennung aufnehmen?

Ja für den Moment schon

Stört der x_pmt Parameter andere SAT>IP Server? Weil ihr das nicht generell mit rein nehmt?

 

Schönen Abend noch^^

[nuts]

Nunja es gibt derzeit 2 Sat>IP Server die eine Serverseitige Entschlüsselung anbieten.

Das wäre der RS und der von DD. Beides soweit ich weiß proprietäre Erweiterungen des Standards.

Beide werden im DVBViewer entsprechend behandelt und so ist es auch richtig.

 

Vermasselt hat das Astra, die eine serverseitige Entschlüsselung gleich mit in die Sat>IP Spezifikationen aufnehmen hätte sollen.

Sämtliche Custom Parameter (vielleicht kommen ja noch mehr Sever mit eigenen, anderen Ideen?) einfach mal mitzuschicken ist keine empfehlenswerte Herangehnsweise. Das geht irgendwann sicher schief!

[Griga]

IsRS gibt den Server an:

RTSPServerUnknown = 0;
RTSPServerRS = 1;
RTSPServerOctopusNet = 2;

Die Bedeutung von UseTCP hängt vom Server ab:

IsRS = RTSPServerUnknown:

UseTCP ohne Bedeutung

IsRS = RTSPServerRS:

TCP verwenden wenn UseTCP > 0, ansonsten UDP

IsRS = RTSPServerOctopusNet:

UseTCP =

0 = No CI,

1 = Any CI (x_pmt bei Session-Start und verschlüsselten Sendern)

2 = CI #1 (x_pmt bei verschlüsselten Sendern, x_ci=1)

3 = CI #2 (x_pmt bei verschlüsselten Sendern, x_ci=2)

[MaxB]

@FreakyJ: Kann man den MP2-Server TVE3.5 auch mal testen? Edit: Ja, Download der "Alpha-Versionen" ist öffentlich

MP kann doch auch Analog-TV, klappt da auch die Zuspielung von Analog TV zum DVBViewer? Dann würde ich mich glatt als Betatester anbieten wollen, erst recht wenn die "HVR 930c" von Hauppauge mit allen 3 Empfangsarten (Analog TV DVB-C & DVB-T) voll unterstützt werden würden! Das man die 3 Empfangsarten nicht gleichzeitig nutzen kann ist mir klar, ich würde das nur gerne im Kabelnetz mal ausprobieren.

 

Edit/Nachtrag: Ich habe mich in den letzten 2,5 Stunden über MP2 ein wenig auf deren Seiten und im Forum belesen und mir ein paar Fragen selbst beantwortet:

1. Live TV scheint da scheinbar eher noch vor "Alpha" zu sein
2. Analog TV (mein Hauptgrund für einen Test) wird vermutlich mit der HVR930c nicht laufen (mit MP 1.8 vermutlich schon)
3. Der Schwerpunkt von MP liegt ganz woanders als bei mir (es geht da eher um Film und Audiosammlungen usw.)

=> Falls ich wirklich mal Langeweile haben sollte werde ich MP1.8/2.x Beta? durchaus nochmal an testen, da ich aus persönlichen Gründen gelegentlich auch mal Analog TV kontrollieren muss und hier dringend nach einer funktionierenden Netzwerklösung suche... Am liebsten mit Transcoding um dies auch mal per Remote erledigen zu können. DVB deckt der RS für meine Zwecke vollkommen ab!

Edited July 8, 2014 by MaxB

[FreakyJ]

Vielen lieben Dank @Griga und @nuts , dass ihr so schnelle antwortet und so hilfsbereit seit

 

Gibt es auch eine Möglichkeit DVBViwer v5.2.9.0 dazu zu bewegen den x_pmt parameter zu senden?

Ihr habt irgend etwas geändert von 5.2.9.0 auf 5.3.1.0, sodass das Bild mit der neuen DVBViewer version schwarz bleibt nach einem Kanalwechsel, rufe ich aber die RTP URL mit VLC dann auf, so sehe ich dort das Bild... Also scheine ich irgend etwas zu machen was dem neuen DVBViewer nicht passt :/ Mit dem 5.2.9.0 funktioniert es aber ohne Porbleme. Irgend eine Vermutung welche von euren Änderungen damit zusammen hängen könnte?

Weiß im Moment nicht so recht wie ich das debuggen soll, sodass ich herausfinde was der neuen DVBViewer version plötzlich nicht gefällt^^

 

@MaxB

Jaa MP unterstützt auch Analoges Tv

Dieser Branch ist work in progress: https://github.com/MediaPortal/MediaPortal-1/tree/EXP-TVE3.5-MP1-MP2_mm_working

Führt aber einen TsMuxer ein, sodass MP aus dem analogen Signal einen TransportStream macht. Über meinen UPnP Server müsstest du das dann auch in DVBViewer einbinden können, habe ich nun aber noch nicht getestet^^

SAT>IP unterstützt logischer weise kein analoges Signal Esseidern ich würde da nun eine probitäre Erweiterung für machen wie mit dem x_pmt parameter^^

 

TVE3.5 soll ein eigenständiges Projekt werden wie MP1 und MP2. TVE3.5 gibt es dabei in zwei Formen:

1) Es kann als Plugin im MP2 Server laufen

2) Es kann als stand alone Service laufen

Ziel ist es eine offene Plattform zu bieten die möglich viele Clients unterstützt (MP, DVBViewer, XBMC, Tvs, VLC, ...). Wir unterstützen sogar Hardware Transcoder und ziel ist es das Transcoding noch etwas auszubauen.

Verwendest du MP1 mit der TVE3 so kannst du mit Hilfe von MPExtended + WebMediaPortal auch jetzt schon Transcoding + Webinterface bekommen

http://wiki.team-mediaportal.com/1_MEDIAPORTAL_1/17_Extensions/Remote_Access/MPExtended

[Griga]

Gibt es auch eine Möglichkeit DVBViwer v5.2.9.0 dazu zu bewegen den x_pmt parameter zu senden?

 

Nein.

 

Ihr habt irgend etwas geändert von 5.2.9.0 auf 5.3.1.0, sodass das Bild mit der neuen DVBViewer version schwarz bleibt nach einem Kanalwechsel(...) Mit dem 5.2.9.0 funktioniert es aber ohne Porbleme. Irgend eine Vermutung welche von euren Änderungen damit zusammen hängen könnte?

 

Zu ungenaue Angaben, um etwas daraus schließen zu können.

[FreakyJ]

bitte löschen, siehe Post darunter

Edited July 8, 2014 by FreakyJ

[FreakyJ]

 

Zu ungenaue Angaben, um etwas daraus schließen zu können.

Was würdest du denn brauchen? Wie kann ich bessere Angaben bereit stellen? Kenne mich dafür zu wenig mit DVBViewer aus :/

 

 

Also wenn ich in DVBViewer 5.2.9.0 einen Kanelwechsel auf einen anderen Transponder via SAT>IP auf dem MP server mache, dann funktioniert das. Mache ich das gleiche mit DVBViewer 5.3.1.0 klappt das nicht, sondern das Bild bleibt schwarz. Gebe ich dann aber die rtp URL rtp:[slash][slash] 192.168.178.26:PORT in VLC ein, so sehe ich das Bild, welches eigentlich DVBViewer anzeigen sollte...

Es werden also Daten an DVBViewer gesendet, dieser bekommt es nur irgendwie nicht mit

 

Edit:

Der Eridtor hatte meinen Text gefressen oO

Das passiert sobald ich eine RTP adresse eingebe oO

Edited July 8, 2014 by FreakyJ

[Griga]

Welche Sender, mit/ohne Transponderwechsel, mit/ohne Verschlüsselung, Problem eingrenzen, unter welchen Bedingungen tritt es auf / nicht auf...

 

Eine mögliche Ursache wäre, dass der Sequence Counter im RTP Header bei einem Senderwechsel springt. Das hat das in der 5.3.1 eingeführte Packet Reordering noch nicht auf der Rechnung.

 

• Ergänzt: IPTV/RTSP-Gerät: Die Sortierung von in falscher Reihenfolge eintreffenden RTP-Paketen senkt die Wahrscheinlichkeit von Aussetzern und Wiedergabestörungen deutlich, insbesondere bei TV/Radioempfang über WLAN.

Die Folge ist, dass die Wiedergabe manchmal (nicht immer) in Abhängigkeit von der Bitrate sehr lange braucht, um in die Gänge zu kommen (bei HD einige -zig Sekunden). Das Problem zeigt sich auch bei bestimmten SAT>IP-Servern wie dem Digibit R1.

[FreakyJ]

 

Welche Sender, mit/ohne Transponderwechsel, mit/ohne Verschlüsselung, Problem eingrenzen, unter welchen Bedingungen tritt es auf / nicht auf...

Egal welche Sender, egal zwischen welchen Transpondern, egal ob FTA oder nicht FTA.

 

Senderwechsel auf einem Transponder funktionieren, Senderwechsel zwischen zwei Transpondern funktionieren nicht.

 

 

Eine mögliche Ursache wäre, dass der Sequence Counter im RTP Header bei einem Senderwechsel springt. Das hat das in der 5.3.1 eingeführte Packet Reordering noch nicht auf der Rechnung.

Muss ich heute Abend mal untersuchen, aber das ist sehr wahrscheinlich die Ursache!

Wenn ich zwischen den Transpondern wechsle stoppt MP kurz den Filter Graph und somit auch den RTP Stream, dnach wir dieser neu gestartet d.h. der RTP counter fängt wieder von vorne an. Hast du schon eine vorab version, die das berücksichtigt wo ich es mal mit testen könnte?

 

 

Die Folge ist, dass die Wiedergabe manchmal (nicht immer) in Abhängigkeit von der Bitrate sehr lange braucht, um in die Gänge zu kommen (bei HD einige -zig Sekunden). Das Problem zeigt sich auch bei bestimmten SAT>IP-Servern wie dem Digibit R1.

 

Also mit v5.2.9.0 + MP SAT>IP Server sind die Umschaltzeiten DVBViewer typisch sehr sehr kurz

[Griga]

Wenn ich zwischen den Transpondern wechsle stoppt MP kurz den Filter Graph und somit auch den RTP Stream, dnach wir dieser neu gestartet d.h. der RTP counter fängt wieder von vorne an.

 

Musse nit tun Von vorne (im Sinne von "bei Null") ist ohnehin falsch.

 

Ich habe die Sache lang und breit mit Digital Devices diskutiert. Das Problem lag zwar bei OctopusNet nicht direkt an, aber ich wollte wissen, wie es aus der Server-Perspektive aussieht. Schließlich sind wir übereingekommen, dass ein Server sowas nicht tun darf bzw. nur, wenn der Client (!) mit TEARDOWN und SETUP den Stream explizit stoppt und neu startet.

 

Das macht der DVBViewer bei einem Senderwechsel jedoch nicht, sondern schickt im Interesse einer schnellen Umschaltung nur mit PLAY neue Parameter. Aus Client-Sicht wird der Stream also nicht angehalten! Wenn der Server trotzdem den Sequence Counter springen lässt, ist das im Client aufgrund verschiedener Unwägbarkeiten ausgesprochen schwer zu behandeln. Gemäß den RTP-Spezifikationen muss der Counter beim Start des Streams mit einem zufälligen Wert initialisiert werden. Der Client kann nicht wissen, ob es sich um eine netzwerk-bedingte Diskontinuität handelt, bei dem die Reordering-Mechanismen einschreiten müssten, oder um einen vom Server veranlassten (gewollten) Sprung, Es bleibt deshalb nur eine heuristische Vorgehensweise, oder anders gesagt der Versuch, gut zu raten.

[FreakyJ]

Hehe ich würde es ja auch gerne vermeiden, wenn es ginge, wenn aber MP den Filtergraph schlißet ist auch mein RTP Server dahin :/

Für das eigentliche RTP Streaming verwende ich Live555, wüsste auch nicht, dass ich da einen Parameter übergeben kann der den Start des Counters bestimmt

 

Ich verstehe vollkommen die Problemeatik auf client seite. Aber meine Frage ist nun ob der DVBViewer in Zukunft versuchen wird einen gewollten Sprung zu erkennen oder ob ich versuchen muss irgendwie einen workaround zu bauen, was nicht einfach werden dürfte und ich gerne vermeiden würde?

[Griga]

Aber meine Frage ist nun ob der DVBViewer in Zukunft versuchen wird einen gewollten Sprung zu erkennen

 

Das Problem sind Rückwärtssprünge relativ zum nächsten erwarteten Sequence-Wert, die (abgesehen vom Wrap Around) normalerweise nicht vorkommen. Das wird in Zukunft jedoch behandelt werden.

[FreakyJ]

Ihr seit die Besten!

Kannst du schon in etwa eine Version sagen nun bin ich angefixt und würde es am liebsten gleich ausprobieren

[Griga]

Kurzfristig zur Verfügung stellen kann ich nur eine DVBViewer GE-Testversion. Du bräuchtest zunächst zusätzlich zum DVBViewer Pro eine DVBViewer GE 3.5.1-Installation (siehe Mitgliederbereich, ReadMe lesen!).

[FreakyJ]

Das wäre super! Dann würde ich heute Abend alles installieren und gleich mal ausprobieren

[Griga]

Ok. Ich weiß noch nicht genau, wann ich zum Upload komme, aber ich sage dann hier Bescheid.

[FreakyJ]

Perfekt!

[MaxB]

@FreakyJ: Da Du und Griga euch erstmal auf einen gemeinsamen Nenner gebracht habt, möchte ich jetzt doch nochmal (dank Deiner an mich gerichteten Antworten, danke dafür!) wegen dem Analogen TV nachfassen:

1. Welche Komponenten müsste ich mir auf dem "Server" installieren, damit ich Analoges TV über die HVR 930c per UPNP in meinem Netzwerk abgreifen könnte, am Besten auch inkl. dem WEB-IF?
2. Würde der "TVE3.5" alleine dafür genügen oder müsste ich MP2 + TVE3.5 als Plugin installieren?

Ich habe zwar wirklich versucht mir die Antworten dafür selbst zu erlesen, aber euer Projekt ist mir etwas zu mächtig (verzweigt auch extrem häufig in andere Bereiche) um das eindeutig zu beantworten...

[FreakyJ]

 

Welche Komponenten müsste ich mir auf dem "Server" installieren, damit ich Analoges TV über die HVR 930c per UPNP in meinem Netzwerk abgreifen könnte, am Besten auch inkl. dem WEB-IF?

Du müsstest diesen Branch installieren:

https://github.com/MediaPortal/MediaPortal-1/tree/EXP-TVE3.5-UPNP_Server

Aber das ist alles stark WIP daher würde ich von einem produktiven Einsatz abraten, aber ausprobieren kannst du es gerne

Du müsstest den Branch durch den compiler jagen^^

Oder du kannst auch bei MP einen Thread auf machen und mich mit @FreakyJ tagen, dann musst du einfach MP 1.8 als standalone server installieren (installiert alles nötige so rum herum), ich lade dir die compilierten Binaries hoch, dann musst du noch einen Wert in der Datenbank ändern, einen Filter registrieren und du kannst loslegen^^

Hört sich nach etwas arbeit an, aber wie gesagt es ist keine offizielle Version

 

Ob MPExtended mit TVE 3.5 funktioniert weiß ich nicht, hat noch niemand getestet

 

 

1. Würde der "TVE3.5" alleine dafür genügen oder müsste ich MP2 + TVE3.5 als Plugin installieren?

TVE3.5 alleine würde genügen

 

 

Ich habe zwar wirklich versucht mir die Antworten dafür selbst zu erlesen, aber euer Projekt ist mir etwas zu mächtig (verzweigt auch extrem häufig in andere Bereiche) um das eindeutig zu beantworten...

Über TVE3.5 gibt es auch nicht viel im öffentlichen Bereich

[MaxB]

Sieht mir als MP-Neuling doch recht kompliziert aus (letzter MP-Test ist Jahre her), ich denke, ich warte noch ein wenig bis eine TVE3.5 Installation als Setup vorhanden ist, trotzdem vielen Dank für die Antworten.

PS: Einen separaten PC mit Win 7 hätte ich recht schnell vorbereitet, vielleicht magst Du das ja im Hinterkopf behalten und mir irgendwann mal ein Hinweis auf ein Setup geben?

[FreakyJ]

Gerne

[Griga]

Der DVBViewer GE 3.5.1.4 ist im Mitgliederbereich, Beta-Sektion verfügbar (nach unten scrollen...). Bitte in einer regulären 3.5.1-Installation die im Test-Paket enthaltenen Dateien ersetzen.

 

Im UseTCP-Parameter in der Datei Konfigurationsordner\Setup.ini, Sektion [Hardware] ist anders als beim DVBViewer Pro sowohl der Server als auch die Betriebsart kodiert. Die oberen 4 Bit geben den Server-Typ an:

 

RTSPServerUnknown = 0;
RTSPServerRS = 0x80;
RTSPServerOctopusNet = 0x40;

 

und die unteren 4 Bit die Betriebsart:

 

Bei RTSPServerUnknown: Ohne Bedeutung

Bei RTSPServerRS: UDP = 0x00, TCP = 0x01

Bei RTSPServerOctopusNet: Kein CI = 0x00, Any CI = 0x01, CI #1 = 0x02, CI #2 = 0x03

 

Für dich dürfte also 0x41 = 65 dezimal passend sein.

 

Weiteres in der Anleitung.

[FreakyJ]

Perfekt! Die Umschaltzeiten sind viel besser

Echt super Support hier, die 15€ habe ich noch kein einziges mal bereut

 

An welchen Kriterien erkennt ihr die SAT>IP Geräte, welche den x_pmt parameter unterstützen? Also defakto den DD Onet^^

 

 

<friendlyName>OctopusNet</friendlyName>
<manufacturer>DigitalDevices</manufacturer>
<manufacturerURL>http://www.digitaldevices.de/</manufacturerURL>
<modelDescription>OctopusNet</modelDescription>
<modelName>OctopusNet</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>http://www.digitaldevices.de/OctopusNet.html</modelURL>
<serialNumber>2379</serialNumber>
<UDN>uuid:dd848d00-26ec-11eb-8000-54847b001296</UDN>

Ich würde ja auf "manufacturer" tippen Wenn dem so ist, wäre es cool, wenn der DVBViewer in Zukunft auch nach "Team MediaPortal" schauen würde

[Griga]

An welchen Kriterien erkennt ihr die SAT>IP Geräte, welche den x_pmt parameter unterstützen?

 

ModelName

[FreakyJ]

 

ModelName

 

Wäre nice wenn der DVBViewer in der nächsten Version auch nach "MediaPortal SAT>IP Server" checken würde und Danke nochmal!