Ich habe ein Multicast streamts gemacht (es kann auch Unicast streamen und funktioniert gut mit dem 500). Aber ich finde dass Multicast ist sehr Netzwerk intensiv? Aber wenn Sie es testen wollen ist es am http://www.ridax.se/dreambox

Mich würde mal das reine Multicast Protokoll interessieren...also die Server/Client Anfragen/Antworten. Ich bin gerade dabei einen Teil des mencoder codes für die dreambox zu portieren um den TS Stream in realtime zum Mpeg-PS zu convertieren. Das soll für einen Server von nutzen sein, der für meinen Kiss DVD player die files auf der box, sowie den tv stream zur Verfügung stellt. Die streamts -ps Option bringt ein leicht fehlerhaftes Format, womit der Kiss Player nicht zurechtkommt. sonst würde es auch mit dem Code gehen. Evtl. würde ich mir mit dem Multicast Protokoll, was der Player auch beherrschen soll, das lästige Protokoll zum streamen des Players ersparen und somit den ganzen Timingaufwand.

cheers

Meinen Sie streamts -ts (nicht -ps)? Haben Sie mein streamts in Unicast modus probieren? Es soll ein besseres transport stream machen.

Ich biete Ihnen das DU an.

Zitat

Meinen Sie streamts -ts (nicht -ps)? Haben Sie mein streamts in Unicast modus probieren? Es soll ein besseres transport stream machen.

Nein ich meinet streamts -ps aus dem cvs. Damit wird kein ts stream gestreamed sondern in Echtzeit ein MPEG-PS Format erzeugt. Da mein Player, der als Client der Box dienen soll nur MPEG Streams versteht, kann ich mit den TS Streams nichts anfangen und streamts mit Option "-ps" streamt ein unsauberes MPEG PS Format, deswegen der Ausweg mit den mencoder Sourcen. Mencoder und ffmpeg zumindest packen das locker in Echtzeit auf der Dreambox.

Warum ich am Multicast Protokoll interessiert bin. Der Player beherrscht angeblich auch dieses Protokoll, "unabhängig" vom Format das gestreamt wird. Da das Protokoll des kissplayers (eine Art HTTP Protokoll) aber keinen Raw Stream empfängt sondern immer die gewünschten Bytes anfordert, ist damit ein gewisser Bufferaufwand auf der Serverseite (Dreambox9 verbunden, der den Echtzeit MPEG-PS Stream bis zur Anfrage der gewünschten Bytes zwischenbuffert. Bisher habe ich das mit perl auf der Dreambox gelöst, was aber noch nicht so exakt performed. Wenn das Multicast Protokoll in der Hinsicht etwas mehr Vorteile bringen würde, wäre das für mich evtl. interessant. Deswegen die Frage nach dem Aufbau des Protokolls.

cheers

Aber "-ps" ist nicht implimentiert in dem Dreambox image? Es ist in ein #ifdef und nicht inkludiert wenn es ein Dreambox ist, glaube ich.

Wenn ich Multicast streamen sende ich die gleiche Daten wie im Unicast (ein transport stream wenn ich glück habe ) doch mit udp multicast statt tcp.

Zitat

Aber "-ps" ist nicht implimentiert in dem Dreambox image? Es ist in ein #ifdef und nicht inkludiert wenn es ein Dreambox ist, glaube ich.

Hehe man kann es aber so drehen, daß es für die Dream passt.

Zitat

Wenn ich Multicast streamen sende ich die gleiche Daten wie im Unicast (ein transport stream wenn ich glück habe Augen rollen ) doch mit udp multicast statt tcp.

Ob tcp oder udp wäre egal, das Protokoll interessiert mich, also:

Client asking: ......give me infos about ...and so on
Server answering: so her are some important informations ...and so on.
Client asking: ....
Server answering: ......

cheers

Zitat

Original von krallekit

Hehe man kann es aber so drehen, daß es für die Dream passt.

Du meinst #ifdef wegnehmen? Aber es soll ein Grund sein, das die #ifdef's da sind.

Zitat

Client asking: ......give me infos about ...and so on
Server answering: so her are some important informations ...and so on.
Client asking: ....
Server answering: ......

cheers

Client asking: http://my.dreambox.ip:31339/0,sid,pid,pid
Server answering: OK\n\r\n\r ts-stream

Ist dass was du meinst?

Zitat

Du meinst #ifdef wegnehmen? Aber es soll ein Grund sein, das die #ifdef's da sind.

So in etwa. Das ist ja nur die bedingte Compilierung, die im Falle der Dreambox nur die ts Option zulässt. Ich habe bei Zeiten, ca. 1 Jahr her, einfach mal probiert die TRANSFORM Option zu aktivieren und damit auch die ps Option zuzulassen. Warum das als default deaktiviert ist weiß ich nicht. Vielleicht das fehlerhafte ps Format, obwohl das auch unter X86 Platformen, mit Benutzung einer Tv Karte, Probleme bereitet.

Zitat

Client asking: http://my.dreambox.ip:31339/0,sid,pid,pid
Server answering: OK\n\r\n\r ts-stream

Ist dass was du meinst?

Das ist ja das typische Protokoll, das auch streamts verwendet. Client fragt, Server antwortet und sendet stream im nowait modus, also alles was geht.

Ist das bei Multicast bzw. Unicast auch so?

Als Gegenbeispiel mal ein kurzer Ausschnitt aus dem Protokoll des KissPlayer.

Kiss fragt: nach Dateiliste
Server Antwort: Dateiliste
Kiss fragt: erste 64 Bytes der gewählten mpeg ps datei
Server Antwort: sendet erste 64 Byte der gewählten mpeg ps datei
Kiss fragt: erstes paar 531xxx Bytes
Server Antwort: erstes paar 531xxx Bytes
Kiss fragt: letzten 531xxx Bytes
Server Antwort: letzten 531xxxBytes
Kiss fragt: erstes paar 531xxx Bytes
Server Antwort: erstes paar 531xxx Byte
Kiss fragt: zweites paar 531xxx Bytes
Server Antwort: zweites paar 531xxx Byte
Kiss fragt: drittes paar 531xxx Bytes
Server Antwort: drittes paar 531xxx Byte
...und so weiter.

Du siehst, man kann nicht einfach wie bei streamts den kompletten Stream raw durch das Netzwerk streamen. Die Dreambox muß immer auf die Anfrage des Clienten (Players) warten und das für die komplette Zeit des Streams. Dies wiederum erfordert das puffern des Tv Streams bis zum Zeitpunkt der Anforderung durch den Player.

Da wäre ein Protokoll, wie es streamts verwendet schon besser, deswegen mein Interesse am Multicast/Unicast. Wenn aber streamts schon diese Protokoll von Grund auf beherrscht, kann ich ja damit nochmal einen Versuch starten.

cheers