Stream Port des recsvr direkt abgreifen

[jomagic]

Hallo,

 

ich versuche jetzt schon ein paar Tage lang herauszufinden, wie man den Video Stream vom ServerPort direkt abgreifen kann und zB an ein Media Objekt direkt weiterleitet.

Bin gerade dabei mich in die W8 Metro programmierung einzuarbeiten und fand das ne nette Übung, da ich schon länger was in die Richtung machen will.

 

Ich hab mir die Kommunikation per Wireshark genau angesehen und einiges in C# mit Sockets probiert. Die Connects an sich klappen auch aber ich krieg keine Response.

(außer ! - 1 einziges Mal - dann nie wieder ;-( ).

 

Zudem habe ich auch den Steuerserver versucht, entsprechende kommandos wie SETTUNER,... UNSETTUNER versucht (mit WShark ermittelt) aber auch die Fernsteuerung geht nicht.

 

In der svcdebug.log und im recsrv Webinterface erscheint mein Client auch aber leider nciht in der Art und Weise wie ein DVBViewer Client es auslöst.

Bin schon am verzweifeln und für einen guten Tip dankbar.

 

Anscheinend reicht es ja nicht einfach nur den Socket Aufruf zu starten..

 

Merci,

jo

[jomagic]

PS: nein,... das Webinterface ist keine Alternative. Mir zu langsam. Ich will einen vollständigen aber einfachen Client erstellen.

Einfach per Sender-/Favoritenliste den Control Server füttern und das gestreamten Video anzeigen. ImMo habe ich niccht vor auch EPG und Aufnahmen usw. zu verwalten.

[Tjod]

Wenn du die DVBServer Schwachstelle nutzen willst, die ist nur für den DVBViewer gedacht.

Wenn ich richtig liege musst du da sehr viel selber machen. Das heißt du musst dem DVBServer genau mitteilen welche PIDs und welche Frequenz der einstellen soll.

Außerdem musst du damit rechnen das sich Plötzlich was an der Schnittstelle ändert ohne dass das bei den Änderungen aufgeführt ist. Da es für irgend eine Neuerung oder Verbesserung im Zusammenhang mit dem DVBViewer von voreilt ist.

 

Das einfachste wäre wahrscheinlich das direkte streaming aus dem Webinterface zu nutzen.

http://IP:8089/stream.html?aktion=channellist_m3u

[VinoRosso]

Wenn du die DVBServer Schwachstelle nutzen willst, die ist nur für den DVBViewer gedacht.

 

Hihi ;-)

 

 

 

[jomagic]

Hi,

 

sowas in der Art hatte ich schon erwartet. Schwachstelle ausnutzen heiß aber eher, eine Hack ausführen...

Ich wollte eigentlich nix hacken. Bin davon ausgegangen, da "darf" man dran.

 

Mit der Channellist habe ich übrigens auch ne Weile geturtelt aber das ist +/- so langsam wie der WebStream ... obschon, langsamer als der Flowplayer und event. Transcoding kann das auch nicht mehr sein ;_)

 

Also eigentlich hatte ich bisher ein paar 100 Zeilen Code zusammen, die auch Conects zusammengebracht haben, nur eben keine Rückmeldungen (also Stream responses).

Komisch ist nur, dass man im Wireshark wenig sieht, dass der Client an den Servber schickt (also DVBViewer -> RECSRV).

 

Der TCP Stream liß sich auf ein paar Zeilen eingrenzen ... und wenn man im WS die Comunication filter und den Stream RAW in ne Datei schreibt, kriege ich ja auch ein astreines Bild ;-)

Ich schau mal, ob da noch was an den UDP's passiert. Irgendwie muss da ja was gesendet werden, dass den Senderwechsel auslöst und den Stream neu verschickt.

 

Andere Frage. Gibt es eine Möglichkeite den recsrv in einem höheren Log Level laufen zu lassen? Da steht leider nie viel drin in der Log Datei ;-(

 

Danke,

Jo

[jomagic]

PS: das ist die gesamte Kommunikation, wenn man DVBViewer als Client startet (jedenfalls TCP).

Dann gibts noch jede Menge SMB aufrufe, wahrscheinlich um die vorhandenen Aufnahmen zu ermitteln, was mich aber nicht sonderlich interessiert aktuell.

 

SETID {15A49069-7958-429E-A4D0-3D7611F35EC4}

 

BOSS 1

 

SETTUNER 1.12187.27500.10600.1.0.3.3.104.163.44.12003.1.0.0.24.0.1089.1.

 

FAILED.

 

ADDPID 163.104.0.44.105

 

Bei einem Senderwechsel gibts dann ncoh Befehle wie UNSETTUNER und DELPID.

Entweder, das ist dann also ne Com Geschichte oder es könnte wirklich relativ einfach sein ... naja 3 Tage Arbeit aber noch nix zum laufen bekommen ;-(

[chrisbu]

Das Thema Kommunikation eines Unicast Device im DVBViewer mit dem Recording Service (unicast Server) finde ich sehr interessant. Bei mir geht es eher um ein Problem, das beim Verbindungsaufbau bei mehreren parallelen DVBViewer Zugriffen auftritt und dabei manchmal kein Stream startet. Siehe auch den Thread dazu: http://www.DVBViewer.tv/forum/topic/49997-mehrere-DVBViewer-am-rs-tv-stream-startet-manchmal-nicht/

 

Von daher wäre ich an Deinen Erkenntnissen sehr interessiert, was den Verbindungsaufbau (also Anmeldung des DVBViewers, Anforderung des Streams, Rückmeldungen, Bedeutung von Fehlermdeldungen in dem Kontext wie z.B. "TUniCastServer Error!" in der svcdebug.log oder "Gotstr SIG 96" im debug.log des DVBViewers, bis hin zum Anlaufen des eigentlichen Streamings, evtl. Abhängigkeiten von Timings bei dem ganzen Prozess) angeht. Vielleicht hilft das ja bei der Ursachenforschung zu meinem Fehlerbild weiter.

 

Falls Du ein kleines Progrämmchen zum Laufen bekommst, das sich wie ein DVBViewer am RS anmeldet und einen Stream empfängt, würde ich mich sehr freuen, wenn Du das für meine Fehlersuche zur Verfügung stellen könntest. Es würde schon reichen, wenn nur der Stream empfangen und nicht ausgegeben, sondern verworfen wird. Damit könnte man super probieren, wenn man mehrere Verbindungen parallel aufmacht, wie sich der RS dabei verhält und vielleicht besser als mit dem DVBViewer sehen, warum es bei mehreren parallelen Verbindungen manchmal nicht klappt.

 

Ich hatte auch schon vor, mich wie Du mit WireShark in die Kommunikation zu hängen und die Sache zu analysieren. Vielleicht kannst Du mir da Deine bisherigen Erkenntnisse zukommen lassen? Wir scheinen ja, wenn auch aus unterschiedlicher Motivation, irgendwie an dem gleichen Thema interessiert zu sein.

 

Danke und Gruß, Chris

[jomagic]

Hi Chris,

 

kann ich gerne machen. Allerdings macht das Progrämmelchen noch nciht mehr als einen Socket zu setzen und dann die obigen Parameter zu schicken.

Im log File kommt dann aber nich annähernd das raus, was bei einem korrekten DVBViewer Client stehen sollte. Also diese "Tuning to" Geschichten.

Ich krieg maximal raus, dass ich als Streaming oder CMD Client eingeloggt bin per Socket... Ein einziges mal hab ich was empfangen - warum auch immer - aber dann nie mehr.

 

Zieh dir mal Wireshark und setze einen Filter auf ip.src und ip.dst (demnach zwischen Server und Client).

Dann such die Portws, die du laut Einstellung im Server abgreifst (bei mir 3456= Stream und 4022=Cmd).

 

Per rechtem Mausklick auf so'n Packet => Kontextmenü "Follows Conversation" auswählen.

 

Dann kriegst du ein Fenster in dem Quasi ales wissenswerte drin steht. Anfangen kann ich damit aber auch leider wenig.

Serverseitig habe ich parallel dazu noch den Procmon mitlaufen lassen und auf den recsrv gefilter. Viele schöne Info's aber ich komm trotzdem nicht weiter.

 

Bye,

Jo

 

PS: habe den obigen Rat mal befolgt und versuche mich daran den http - upnp Stream soweit zu optimieren, dass die Umschaltzeiten besser werden.

Die besten Erfahrungen habe ich aktuell mit dem WMP Plugin gemacht. Ich hab mir aus Spaß ne Seite gebaut, die 4x das embedded Plugin einbindet und dann jeweils auf 4 verschiedene Adressen

(also zB http://dvb-server:7522/upnp/channelstream/11.ts ) zugreift.

 

Das geht fast ruckelfrei. 4 verschiedene Sender werden gestreamt und angezeigt ;-) Der upnp Server ist also mal gar nicht so schlecht nur dauert das Buffern zu lange.

Wenn jemand nen Tip hat wo man den Buffer auch (viel) niedriger einstellen kann, wäre ich dankbar.

 

Ne andere Alternative wäre dann noch HTML5 mit einem eingebetteten Player aber der kann dann wieder kein mpgts soweit ich's verstehe. Dann wäre ich aber wenigstens plattformunabhängiger unterwegs.

Scheint aber auch keine nativ Streams, sondern nur auf dem Webserver hinterlegt Files zu spielen. Http abgreifen is nicht ;-(

[nuts]

Ich habe mal intern nach einer Doku der Geschichte angefragt und folgende Antwort bekommen:

Es wird demnächst etwas flexibleres geben als der Unicast TCP kram und das wird dokumentiert werden.

 

Des weiteren sollst du lieber deine RTSP/RTP/RTCP kenntnisse auffrischen.

Spaß beiseite. Ich würde für solch ein Projekt die oben angesprochene Entwicklung abwarten.

Edited July 25, 2012 by nuts

[jomagic]

Na das hört sich ja vielversprechend an. So langsam wird mir auch klar warum da nix ankommt.

Frag mich nur, was flexibler sein soll als das?

 

Ich harre der Dinge...

 

Merci,

Jo

[nuts]

Frag mich nur, was flexibler sein soll als das?

 

RTSP/RTP/RTCP kenntnisse auffrischen

Edited July 25, 2012 by nuts

[chrisbu]

Hallo Jo,

 

erst mal vielen Dank für Deine Informationen zum Logging mit Wireshark, die sehr hilfreich sind. Ich fürchte nur, dass ich da wohl auch nicht mehr sehen werde als Du und nicht wirklich eine Ursache für die Verbindungsprobleme mehrerer DVBViewer parallel per Unicast zum RS entdecken werde. Zumindest kann ich Deine schon mal geäußerte Vermutung, dass beim Verbindungsaufbau noch weitere Kommunikation läuft, die nicht über die beiden Ports (Control-Server und Stream-Server) läuft, insoweit bekräftigen, dass ich auch schon darüber gegrübelt habe. Denn in einem anderen Fehlerfall (Timeraktualisierungen wurden vom RS nicht an den über zweite Netzwerkkarte angebundenen DVBViewer weitergegeben) habe ich nach langer Ursachensuche und einigen Posts im Forum den goldenen Hinweis vom Entwickler bekommen, dass es dafür einen (undokumentierten) UDP Broadcast an FF:FF:FF:FF:FF:FF gibt und dann endlich in die richtige Richtung suchen können (Win7 gibt solche globalen Broadcasts nur an die primäre Netzwerkkarte raus, während XP das noch über alle Karten rausgab). Würde mich also nicht wundern, wenn es im Kontext des Verbindungsaufbaus / Stream-Starts zum DVBViewer auch eine uns bisher unbekannte Kommunikation per Broadcast oder Multicast gibt.

 

Ich werde das mit dem Wireshark vielleicht mal an einem Wochenende in Angriff nehmen. Wenn ich dabei was interessantes rausbekommen sollte, das auch für Dich hilfreich sein kann, gebe ich Dir hier natürlich Bescheid.

 

Angesichts der Aussage von Lars, dass es demnächst eine völlig neue Schnittstelle geben soll, die (wenn ich das richtig verstanden habe) die Unicast-Schnittstelle ablösen soll, also auch für die Anbindung des DVBViewers genutzt wird, fragt man sich natürlich, ob es noch Sinn macht, da jetzt viel Aufwand in die Fehlersuche mit der alten Schnittstelle zu inverstieren, die ja auch überhaupt nicht dokumentiert ist. "Demnächst" ist ja auch ein sehr dehnbarer Begriff. Ich vermute, dass es dafür ja Anpassungen sowohl im DVBViewer als auch im Recording Service geben muss. Ob das so bald kommen wird? Aber wer weiß, manchmal geht ja auch alles sehr schnell.

 

Gruß, Chris

[jomagic]

Hi Chris,

 

ich gehe aber mal stark davon aus, dass es sich beim UDP Broadcast nur um das WOL handelt.

Schalte das WOL mal in der Config des Clients aus. Hab's noch nicht probiert aber das scheint doch das MagicPacket zu sein, dass den Server auch aufwecken darf.

 

@nuts: auffrischen ist gut ;-) das is ne ganz neue Materie für mich.

Mich wundert nur, dass in den Logs des WS so wenig per UDP läuft. Multicastadressen sind auch wenig drin und kommen sicher von einem Windows Service, der auf meinem Client rödelt.

Was genau läuft denn per UDP? Der Video Stream oder die Commands des CMD Clients? Irgendwie komme ich da mit den Ports und Adressen nicht zurecht, bzw kann die nicht zuordnen.

 

PS: wenn du ne gute Site hast, auf der (nachvollziehbare) Beispiele für Uni-Multicast Apps stehen, wäre ich dir dankbar.

 

Bye,

jo

[Tjod]

Unter anderem die Updates der Timer liste werden als UDP Broadcast verteilt.

http://www.DVBViewer.tv/forum/topic/49900-timerliste-des-rs-wird-im-DVBViewer-nicht-immer-angezeigt/page__view__findpost__p__369014

[jomagic]

Hallo,

 

wollte hier noch einmal den aktuellen Stand der Recherche hinterlassen.

In der Beta gibt es nun einen neuen RTSP Server, der prima funktioniert.

Kein Vergleich zu den vorherigen Streaming Lösungen.

 

Wie oben im Thread vermerkt, sollte ich mich mal über RTP, RTSP schalu machen und hab mir die Sources für einen Client besorgt (Uniriotec ... einfach mal googeln).

Der bringt alles nötige mit um den Stream zu catchen. Ich arbeite gerade an der Implementation.

 

Hier ein Kommunikationsprotokol beim Senderwechsel mit connect auf den RTSP Server - wer sich die Sources von Unirotec anschaut wird die parallelen finden ;-)

 

PLAY /stream=15?delpids=101,102,0,104,2171 RTSP/1.0

 

CSeq: 25

 

Session: 2344

 

 

 

RTSP/1.0 200 OK

 

CSeq: 25

 

Session: 2344;timeout=20

 

RTP-Info: url=rtsp://192.168.78.104/stream=15;seq=8667;rtptime=51355156

 

 

 

 

 

PLAY /stream=15?delpids=18 RTSP/1.0

 

CSeq: 26

 

Session: 2344

 

 

 

RTSP/1.0 200 OK

 

CSeq: 26

 

Session: 2344;timeout=20

 

RTP-Info: url=rtsp://192.168.78.104/stream=15;seq=8667;rtptime=51355835

 

 

 

 

 

SETUP /stream=15?src=1&freq=11953&msys=dvbs&plts=off&fec=34&pol=h&ro=0.35&sr=27500&mtype=qpsk&tnr=1,11953,27500,10600,1,0,3,3,120,110,100,28006,1,0,24,0,1079,1&prio=1 RTSP/1.0

 

CSeq: 27

 

Session: 2344

 

Transport: RTP/AVP;unicast;client_port=52002-52003

 

 

 

RTSP/1.0 200 OK

 

CSeq: 27

 

Session: 2344;timeout=20

 

Transport: RTP/AVP;unicast;destination=192.168.78.30;source=192.168.78.104;client_port=52002-52003;server_port=6202-6203

 

com.ses.streamID: 15

 

 

 

PLAY /stream=15?addpids=18 RTSP/1.0

 

CSeq: 28

 

Session: 2344

 

 

 

RTSP/1.0 200 OK

 

CSeq: 28

 

Session: 2344;timeout=20

 

RTP-Info: url=rtsp://192.168.78.104/stream=15;seq=8667;rtptime=51484112

 

 

 

 

 

PLAY /stream=15?addpids=110,120,0,130 RTSP/1.0

 

CSeq: 29

 

Session: 2344

 

 

 

RTSP/1.0 200 OK

 

CSeq: 29

 

Session: 2344;timeout=20

 

RTP-Info: url=rtsp://192.168.78.104/stream=15;seq=8667;rtptime=51484792

[jomagic]

Hi,

 

nachdem ich mich damit einige Stunden rumgeschlagen habe ist der Client funktionstüchtig.

Es ist mir jetzt möglich den RTSP Server dazu zu bringen etwas an den Client zu schicken, dass auch tatsächlich der TS Stream ist.

Nun muss ich mich noch an Debuggen machen und die TS Daten filtern, da der Video Stream noch ziemlich kaputt ist aber zumindest ein Bild erscheint.

 

Wenn das erstmal steht, dann implementiere ich das in ne Metro App. Sollte dann nicht mehr so schwierig sein.

 

Jo