jomagic Posted July 23, 2012 Share Posted July 23, 2012 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 Quote Link to comment
jomagic Posted July 23, 2012 Author Share Posted July 23, 2012 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. Quote Link to comment
Tjod Posted July 23, 2012 Share Posted July 23, 2012 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 Quote Link to comment
VinoRosso Posted July 23, 2012 Share Posted July 23, 2012 Wenn du die DVBServer Schwachstelle nutzen willst, die ist nur für den DVBViewer gedacht. Hihi ;-) Quote Link to comment
jomagic Posted July 23, 2012 Author Share Posted July 23, 2012 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 Quote Link to comment
jomagic Posted July 23, 2012 Author Share Posted July 23, 2012 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 ;-( Quote Link to comment
chrisbu Posted July 24, 2012 Share Posted July 24, 2012 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 Quote Link to comment
jomagic Posted July 24, 2012 Author Share Posted July 24, 2012 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 ;-( Quote Link to comment
nuts Posted July 25, 2012 Share Posted July 25, 2012 (edited) 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 Quote Link to comment
jomagic Posted July 25, 2012 Author Share Posted July 25, 2012 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 Quote Link to comment
nuts Posted July 25, 2012 Share Posted July 25, 2012 (edited) Frag mich nur, was flexibler sein soll als das? RTSP/RTP/RTCP kenntnisse auffrischen Edited July 25, 2012 by nuts Quote Link to comment
chrisbu Posted July 25, 2012 Share Posted July 25, 2012 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 Quote Link to comment
jomagic Posted July 25, 2012 Author Share Posted July 25, 2012 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 Quote Link to comment
Tjod Posted July 25, 2012 Share Posted July 25, 2012 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 Quote Link to comment
jomagic Posted October 7, 2012 Author Share Posted October 7, 2012 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 Quote Link to comment
jomagic Posted October 8, 2012 Author Share Posted October 8, 2012 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.