Streamen und abspielen von der Box aus

Hallo zusammen,

ich wollte mal sehen, wie es im Moment mit DVR ausschaut.
Wie ich gesehen habe gibt es inzwischen auch schon Bestrebungen eine Platte an die Box zu nageln. Hört sich echt interessant an.

Ich habe mich so etwa im Juni auch mit dem Thema beschäftigt und mal angefangen ein paar Erfahrungen zu sammeln. Ich war dann eigentlich so weit, dass es mir möglich war mit meinem Programm direkt von der DBox aus einen Video- und einen Audiostream auf meinen PC per NFS zu schreiben.

Das Zurückspielen hat nur sehr rudimentär funktioniert, weil der Treiber für den "clipmode" wie es immer heisst, noch nicht so richtig funktioniert hat und weil ich auch keine Auskunft bekommen konnte, wie der Treiber zu erweitern wäre. Aber prinzipiell würden die Daten auch wieder zur Box kommen. Ein wenig konnte man auch sehen, aber leider sehr instabil.

Das Programm, das ich geschrieben habe ist im Prinzip aus streampes entstanden. Mit wenigen Änderungen konnte ich auch die Kollisionen auf dem Netz deutlich reduzieren. Ob sich dadruch auch die Prozessorlast verringert hat habe ich nicht geprüft.

Meine Idee war eigentlich ein Programm zu schreiben, dem man über ein definiertes Interface sagen kann, was es aufnehemen soll (das Programm läuft wie gesagt auf der dbox und nicht auf dem PC). Damit wären dann die ganzen GUIs in der lage den Videorekorder zu steuern. Gedacht war auch, dass ich Zusatzinfos (Filmbeschreibung aus EPG) speichere und eine Art Inhaltsverzeichnis auf der Platte verwalte, von dem man einen Film anhand des Titel zum abspielen auswählen kann.

Die Frage an die erlesene Runde wäre nun, ob an solch einer Lösung Interesse bestünde? Wenn ja bin gerne bereits an dem Ding weiter zu basteln. Ich bräuchte höchstens an der ein oder anderen Stelle etwas technische Infos und irgend jemand, mit dem ich das Interface abklären könnte.

Hi!
Nicht, dass ich dir jetzt großartig helfen kann, aber gehts dir um eine Platte, die an die Box angeschlossen ist oder eine die in einem NFS-Server steckt und übers Netz angesprochen wird?

Tschö,
Sepp.

Hi,
ich finde Deine Idee sehr gut und interessant....Wermuthstropfen fuer die Windows-Fraktion: Entweder Linux installieren oder NFS..und das kostet einiges afaik, oder?? Waere mir pers. das Geld aber wert, wenn dadurch die Uebertragung der Streams zum PC schon mal fehlerfrei klappen wuerde....umgekehrt waere noch traumhafter! Ich hoffe Du bekommst response von den Entwicklern, habe aber den Eindruck dass die oefters an einer selektiven Wahrnehmung leiden....

Weiterhin viel Erfolg bei Deiner Entwicklung,
peter

--
"Nur wer selbst brennt, kann Feuer in anderen entfachen."
[Augustinus Aurelius (354 - 430)]

Ich glaube, dass es sicherlich auch für Windows frei verfügbare NFS-Server gibt. Wenn es aber gar nicht anders geht, oder der Overhead von NFS zu groß ist, kann man auch einen kleinen Server bauen, der die Daten einfach entgegen nimmt bzw. bei anfrage versendet. Mit Java ist sowas in wenigen Stunden gebastelt.

@Sepp776

ich möchte im Moment keine Platte direkt an die Box nageln. Da ist mir der Aufwand zu groß. Ich denke schon an die Lösung mit einem NFS-Server

Es gibt sicher auch einen Samba-Client fuer Linux. Ich hatte das mal in einem anderen Beitrag erwaeht. Da hiess aber, das wuerde zuviel Last auf der Box verursachen...

-Zahni

@Zahni

während der Entwicklung habe ich den BootManager laufen, damit ich
im Debug-Modus den Kernel von meinem PC aus auf die Box laden kann.
Das ganze hat dann auch einen NFS-Server zur Verfügung. Da hab ich dann einfach einBerzeichnis auf meinem PC angelegt (welches ja dann direkt im Verzeichnisbaum der DBox auftaucht) und habe in diesem Verzeichnis die Streams gespeichert. Duch die Änderungen bezüglich dem Streamen hatt ich dann sogar deutlich weniger Kollisionen.

Das Egebnis waren dann jeweils ein Video und ein Audio-Stream. Und beide waren auch einwandfrei. Wie gesagt, sogar das Abspielen auf der Box hat schon fast funktioniert. Ist aber eben sehr instabil.

@ Trumi

Wie sieht es aus mit deinem Programm? Viel Spass beim Programieren wenn ich das könnte würd ich es auch versuchen.
Mfg

@Trumpi,

klick mal hier:

http://tuxbox.berlios.de/forum/viewtopi ... highlight=

-Zahni

Beitrag von **trumi** » Freitag 22. November 2002, 08:58

@Zahni

habs gelesen. Bin mir aber nicht sicher, ob DieMade das schon mal versucht hat. Er hat schon recht, dass NFS natürlich durch den Proz abgearbeitet werden muss, aber ich habe das bei mir ja einfach mal probiert und es hat auch prima funktioniert.
Wie gesagt, um das Problem der Porzessorlast mache ich mir im Moment die geringsten Gedanken. Einen kleinen Server zu bauen ist nicht das Thema, wenn wir merken, dass es mit NFS nicht funktioniert.
Aber um das Thema mit NFS vom Tisch zu bekommen, glaube ich schreib ich einfach mal einen kleinen Server in Java der das ganze Handling auf dem PC übernimmt.

Ich bräuchte eher jemanden der sich mit einer der GUI's auskennt, damit ich klären kann, wie eine sinnvolle Parameterübergabe aussehen muss.

Beitrag von **DieMade** » Freitag 22. November 2002, 09:06

Ich bin mit Gandalfx dabei, den streampes auf UDP umzustricken, um die Prozessorlast zu reduzieren.

Bisher geht das ganze über TCP - sprich Handshaking über eine Half-Duplex-Verbindung. Da kocht der Prozzi bei hohen Bitraten, nur um das Protokoll abzuwickeln.

Siehe http://tuxbox.berlios.de/forum/viewtopic.php?t=14382, Seite 6

Beitrag von **trumi** » Freitag 22. November 2002, 09:24

@DieMade

Wenn ich das richtig verstehe, baut Gandalfx einen weiteren grabber für den PC gebaut. Das Problem der vielen Kollisionen auf dem Netz liegt aber zum größten Teil daran, dass der streampes mit sehr kleinen Puffern arbeitet. Das bedeutet, er benutzt für Video und Audio die gleiche Puffergröße. Wenn wir uns aber anschauen, was so an Audio und was an Videosaten übertragen werden, dann ist recht schnell klar, dass der Videopuffer etwas klein geraten ist. Das beudeutet, dass der Proz sehr häufig versucht Videodaten zu verschicken. Ich habe bei meinem Programm die Puffer für Video und audio etwas angepaßt und die Kollisionen haben deutlich abgenommen.

Wobei ich gestehen muss dassmir noch nicht so recht klar ist, warum überhaupt Kollisionen auftreten, wenn sonst eigentlich nix im Netz los ist.
Die umsetzung von 10 auf 100Mb kann es nicht sein, weil das gleiche bei einem reinen 10Mb Netz auch auftritt (habe ich ausprobiert).

Ob also der Umbau auf UDP so viel bring bin ich mir nicht sicher. Aber etwas weniger Kollisionen sollten dann schon auftreten. Die Frage ist nur, was passiert wenn ein Packet tatsächlich mal verloren geht? UDP behebt das ja nicht und dann ist der Stream futsch.

Beitrag von **DieMade** » Freitag 22. November 2002, 09:53

Die Kollisionen kommen zustande, da bei TCP jedes Paket bestätigt werden muß und so wird aus der "Einbahnstraßen-Kommunikation" wieder eine Full-Dulpex-Verbindung, da der Server AKC-Pakete verschickt und schon haste COLs auf dem Netz (wg. Half-Duplex!).

Ein verlorenes Paket sollte Gandalfx später im ggrab abfangen und "padden", so wie es ein guter Receiver auch macht, bevor "Klötzchen" kommen.

Auch bei guten CD-Playern werden Fehler im Datenstrom ja so kompensiert: man spielt einfach den letzten Ton, bis wieder gültige Daten anliegen (vereinfacht ausgedrückt).

Beitrag von **trumi** » Freitag 22. November 2002, 10:10

Wie die Kollisionen entstehen ist mir schon kalr, die Frage ist aber, wenn niemand sonst im Netzwerk unterwegs ist müsste ja die DBox ständig versuchen irgend welche Daten zu schicken und das ganze noch bevor die Ok-Meldung von der Gegenstelle da ist. Wie gesagt, bei mir hat sich das ganze dadruch reduziert, dass ich die Puffer angepaßt habe und nicht so häufig versucht wird etwas zu senden.
Wir sollten mal ausrechnen, was da so an Daten über Leitung geht.

Wenn ich richtig informiert bin, wird die Kollision auf der Hardwareseite erkannt und abgefangen. Das heißt also, dass durch die UDP übertragung der Rückweg gespart wird und falls das Medium gerade mal beleegt sein sollte wird das UDP-Packet nicht verworfen. Also abgesehen vom retransmit bei TCP auch eine zuverlässige Sache. Und genau genommen sollten dann auch überhaupt keine Kollisionen mehr auftreten und der Sender (DBox) kann ungebremmst senden.

Beitrag von **petgun** » Freitag 22. November 2002, 11:16

Bitte diskutiert hier weiter!

danke,
peter

--
"Du kennst mich doch, ich hab' nichts gegen Fremde.
Einige meiner besten Freunde sind Fremde. Aber
diese Fremden da sind nicht von hier!" (Methusalix)

Beitrag von **trumi** » Freitag 22. November 2002, 11:23

@petgun

über was?
Über die Netzlast unt TCP/IP oder über das Programm zum Streamen?

Hi,
wg UDP ist die Hauptintention, die CPU-Last ein bischen zu drücken. Ist auch erst mal ne Idee. Ich habe gerade erst ein CDK-gebaut, und werde beim Streamen jetzt nur das Senden der Daten über IP auskommentieren, und dann schauen, was die CPU auf der Box macht. Sollte das nennenswert runtergehen, kann mit UDP eine Verbesserung erreicht werden. Bei mir wirds dauerhaft über 6000-kBit/s kritisch bis zum Abbruch. Die CPU auf der Box ist dann am Anschlag (bei ca. 5000 kBit/s hatte ich ca. 80% system time).

Imho ist hier auch tcp unnötig wg. Datensicherung, da bei Paketverlust ein Stocken in Sekundengrößenordnung auftritt, und damit ein Pufferüberlauf auf der Box auftritt.

Bei tcp können sehr wohl kollisionen auftreten, da nicht auf die quittung von jedem Paket gewartet wird, sondern der sender ein sendefenster hat (bei linux dynamisch mit normalerweise 64k). Soviel Daten können gesendet werden, bis wieder eine Quittung da sein muß. Normalerweise sollten zwar Kollisionen nicht viel ausmachen, habe aber mit manchen Hubs schon schlechte Erfahrungen gemacht. Das mit den Kollisionen ist dann ein netter Nebeneffekt.

In der nächsten Zeit mehr, wenn ich ein wenig gemessen hab.

________________
Gruß
Gandalfx

Beitrag von **petgun** » Freitag 22. November 2002, 11:56

@trumi

einfach weiter machen hier. Ich find's gut wie Du an die Sache rangehst...zB. mit der Puffergroesse....Du hast es getestet und festgestellt das die Kollisionen 'deutlich' abnehmen....auch wenn's laut Gandalfx nicht so wichtig ist....glaub ich pers. nicht. Die potentiellen Entwickler hier kennen das Programm sicher in und auswendig und kennen alle Zusammenhaenge...aber das kann auch zu 'Betriebsblindheit' fuehren...vor lauter Baeumen sieht man den Wald nicht mehr. Du scheinst etwas pragmatischer an die Sache ranzugehen...find ich gut.....ebenso wie DieMade und Gandalfx hier weiterhin oeffentllich kontrovers diskutieren ohne ueberheblich zu werden.

@Gandalfx

>In der nächsten Zeit mehr, wenn ich ein wenig gemessen hab.

super! Ich bin sicher das Du(Ihr) auf dem richtigen Weg seid und nachhaltig die Streaming/Resync Problematik klaert.

Echt geil, macht bitte weiter so!

gruss,
peter

Beitrag von **trumi** » Freitag 22. November 2002, 12:06

freut mich, wenn es Dir gefällt wie wir Diskutieren.

Aber mein Problem ist nicht, dass es beim Streamen Resyncs etc. gibt (bei mir funktioniert das übrigens schon seit einiger Zeit problemlos, aktuelle Image drauf, ich glaube seit 1.5 gabs da keine probleme mehr).
Ich finde es eigentlich nur schade, dass wir zum Streamen und später vielleicht auch abspielen von Aufnahmen nicht direkt die DBox nehmen können. Das mit dem Streamen geht ja wohl mit dem Streamserver, aber ich würde auch gerne auf der DBox sehen, was ich schon aufgenommen habe und dann einen Film auswählen der abgespielt werden soll. Also nicht nur das reine Aufnehmen, sondern auch eine etwas komfortable Lösung für das Abspielen. Schliessliche haben wir doch da eine schöne Möglichketi mit der Box.

Beitrag von **petgun** » Freitag 22. November 2002, 12:25

hi,

@Gandalfx

>wg UDP ist die Hauptintention, die CPU-Last ein bischen zu drücken..

scheint ja auch das Hauptuebel zu sein!
Seh ich das richtig: Wenn das Streaming ueber UDP abgewickelt wird, koennen wir die bisherigen Grab-Programme (NGrab, WinGrab, TuxVision) in die Tonne hauen? Mach ich aber gerne, wenn ich dann mit Deinem GGrab fehlerfrei arbeiten kann. Die Autoren der bisherigen Programme arbeiten doch bestimmt mit Dir zusammen und werden ihre Programme auf UDP umstellen...hoffe ich...muss da eigentlich viel umgeschrieben werden? VLC kann jedenfalls auch UDP Unicast/Multicast und ich freue mich jetzt schon auf ein neues Image das mit Deiner Streaming-Modifikation laeuft.

Weiterhin viel Erfolg! Wann ist es denn soweit ?? ;-)
Gruss,
peter

--
Erbsen zählen ist nicht schlimm. Schlimm ist, wenn man glaubt, daß
das irgendjemanden interessiert.

@petgun,
mal langsam. Es ist erst mal nur eine IDEE, nicht mehr. Mich störts im Moment oft, z.B. bei ARD, wenn die Datenrate sehr hoch ist, das der Stream abreißt. Ist sowas wie sportlicher Ergeiz ;-)

@trumi
gut, von der box aus steuern ist ok. Per NFS oder so: geht vielleicht, aber wird den armen Prozessor ein wenig belasten.
Als Idee, wie du auch schon angesprochen:
Server läuft auf dem PC, in einem Verzeichnis bzw. Baum liegen die MPEG-Dateien. Die Box holt sich das Inhaltverzeichnis als Auswahlliste. Vielleicht Titel=Dateiname oder zusätzliche Info-datei mit EPG-Infos.
Dann Start und Stop des Streamings Richtung Box per FB.
Zu machen wäre: Protokoll zum Server -> mache Anleihen beim neutrino XML-Ansatz. Der Stream selber kann dann getrennt von der Control-Connection laufen.
Btw. weiß jemand, in welchem Datenformat die Box beim Clipmode gefüttert werden will? (Hab mich mit dem Thema noch nicht tiefer beschäftigt)

__________
Gruß
Gandalfx

Beitrag von **trumi** » Freitag 22. November 2002, 13:05

@Gandalfx

Der Clipmode wird einfach durch den Treiber avia_gtx_dvr angestoßen.
Wenn der Treiber geladen ist (insmod oder so, müsste nochmal nachschauen) dann gibt es zwei Devices (muss auch nochmal nachschauen wie sie genau heißen und wo sie liegen). Die beiden Devices werden dann einfach geöffnet und man kann Daten in die devices schreiben. Ich hab das schon versucht und hat auch prinzipiell funktioniert. Im Juni, als ich damit rumprobiert habe gabs da noch ne ganze Menge Probleme. Ich wollte dann an dem Treiber weiterschreiben, aber das Problem ist, dass die Infos dazu nda sind. Und ohne Datenblätter ist einfach nix zu wollen.

Beitrag von **petgun** » Freitag 22. November 2002, 13:10

hi,

@trumi

>..bei mir funktioniert das übrigens schon seit einiger Zeit problemlos,
> aktuelle Image drauf, ich glaube seit 1.5 gabs da keine probleme mehr..

wenn ich mir die ganzen Threads zu dem Thema anschaue, ist das absolut fehlerfreie grabben aber nicht die Regel und eine Antriebsfeder fuer Gandalfx sein ggrab zu entwickeln.
Dein 'erweiterter Clipmode' waere ja dazu noch der absolute Hammer...mach einfach mal weiter so....ohne das Rad neu zu erfinden...damit Du schneller zum Ziel kommst ;-)

@developer

Fuer das naechste Image mit integrierter gandalfx-Streamingengine, mit dem man fehlerfrei grabben kann, spendiere ich euch ein grosses Fass (50L) Koelsch (nicht diskussionsfaehig ;-)) dass Ihr dann auf der kommenden Release-Party anschlagen koennt....Prost! Soll eine symbolische Anerkennung sein.

Gruss,
peter

--

Ich hasse diesen Römer namens Status Quo!
[Ray Bradbury: Fahrenheit 451]

@trumi
ich meinte eher, welches format die Daten haben müssen:
wie im File: Streams für video und audio zusammen als Program Stream, oder als transport stream, oder zwei getrennte PES-Streams oder....

Beitrag von **trumi** » Freitag 22. November 2002, 13:25

@Gandalfx

ich habe einfach die beiden Streams, die ich von der Box gespeichert habe wieder als Daten zurückgespielt. Das sind wenn ich das richtig in Erinnerung habe PES-Streams, weil ich für Video und Audio dem Demuxer sage, dass ich genau diesen einen Stream für die angegeben PID haben will.

Ein Problem das ich auch noch hatte war die Synchronisation zwischen Bild und Ton. Ich habe im Treiber aber gesehen, dass es da eine Einstellung für gibt, die nach meinem Verständnis falsch war. Möglicherweise ist das inzwischen behoben. Dort stand (so wie ich das verstanden habe) das keine Synchronisation im bei der Ausgabe stattfinden soll.