udpstreamts FIX 19.07.2007

[new.life]

..Alles ander führt fast auschliesslich zu artefakte.

..siehe den Bericht meines reproduzierbaren Experiments...nix mit Artefakten/Abbrüchen bei TCP trotz niedriger Signalstärke. Die Datenrate bei meinem Experiment lag sicherlich >6000 Kbps und den von Dir beschriebenen theoretischen Vorteil bei sehr hohen Datenraten im Zusammenhang mit WLAN mag es geben, kann ich aber nicht nachvollziehen und ist imo leicht praxisfremd.

[arno-neutrinoTV]

Es ist doch recht einfach zusammenzufassen:

Wenn die benötigte Bandbreite der DBOX für einen Sender ausreicht um mit TCP zu streamen, dann ist IMMER TCP vorzuziehen, egal ob drahtgebunden oder WLAN. TCP macht nun mal eine Fehlerkorrektur, die es bei UDP nicht gibt.

Wenn die Bandbreit in die Grenzregion kommt, wo TCP beginnt zu stottern (8000-9000), Dann ist UDP zu verwenden. Damit bekommt man den Strom noch über die dbox raus. Wenn die pakete allerdings danach über ein WLAN gehen, dann gehen sie evtl verloren, was den Vorteil wieder zunichte macht. D.h. bei Sender mit hoher Bandbreite (8000-9000) sollte man ein udp-basiertes streamingverfahren nutzen (das ist auch der Grund warum es udrec gibt). Bei udp kommt es halt darauf an wie gut das Netz ist, ein WLAN mit unter 70% Signalstärke ist schon hart an der Grenze. Hier kann höchstens noch udrec helfen, welcher versucht die verlorenen Pakete neu anzufordern.

D.h. Sender mit hoher Bitrate (also höher als man mit TCP verkraften kann) gehen eben nur bei sehr gutem WLAN Empfang, oder eben mit Kabel.. oder eben mit udrec.

Des Weiteren ist zusätzlich jede Box unterschiedlich, was soviel heisst, wenn eine bestimmte bitrate bei einer bestimmten Box mit TCP noch problemlos geht, heisst das nicht, dass es auf allen dbox gleich ist.

Schlusssatz: ich empfehle jedem, bei dem TCP (also streamts) ohne Probleme geht, genau dieses einzusetzen! Alle anderen suchen nach alternativen - ich gehöre zu den anderen.

[arno-neutrinoTV]

Back to topic:

Streame gerade ARD mit recht hoher bitrate eben die Sportschau sendete. Es kommt immer wieder zu kurzen stopper im Bild -das sind genau die Momente in den der kernel datenverwerfen muss (oder was auch immer das wirklich passiert). Allerdings im Gegesatz zu der alten Version von udpstreamts bleibt es nicht dauerhaft hängen (also udpstreamts arbeitet weiter nach solch einem fehler)

Ich denke man kann das wirklich - wie weiter oben schon beschrieben - mit eine thread basierten ansatz nochmal verbesseren. Ich werd mich da bei Gelegheit dran machen.

Ich denke die aktuelle Version wäre reif fürs CVS. D.h. wenn jmd mit zugang dazu es einchecken könnte wäre das Klasse (evlt teste es auch noch andere Leute)

Falls es noch sachen daran gibt,die nicht konform irgendwelcher Coding-conventions sind, so lasst es mich bitte wissen.

[PT-1]

Wurde dies jetzt nun eingecheckt oder gleich eine andere Frage...

Wo steckt der Yjogol ..

[arno-neutrinoTV]

Hi,

Soweit ich weiss, wurde es noch nicht eingecheckt. Ich will auch noch weitere Änderungen vornehmen. Theoretisch könnte man es trotzdem schon einchecken, da es in der jetzingen Version auch bereits eine Verbesserung ist. Ich will allerdings immer noch, in naher Zukunft noch ein paar Änderungen mehr machen.


Bzgl. der api.sh (ist auch mit einer kleinen Änderung im zip vorhanden): Bitte diese NICHT einchecken, da die Änderung nicht mehr benötigt wird.

Grüße
Arno

[PauleFoul]

Kann man das Thema auch richtung HDTV-Aufnahme mit dem IDE-IF erweitern??

Ich hatte das Thema ja hier http://tuxbox-forum.dreambox-fan.de/for ... light=hdtv bereits schon einmal angesprochen.


Gruß
____Paule

[rhabarber1848]

Ist das der korrekte Patch?
udpstreamts_daemon.diff

[arno-neutrinoTV]

Der patch sieht richtig aus. Zumindest waren das meine damaligen Änderungen. Ob der patch zu der heutigen Version des images noch passt kann ich leider nicht sagen. Wenn zwischenzeitlich niemand was an der udpstreamts geändert hat, sollte es noch klappen.

Ich habe vor längerer Zeit den patch auch an yjogol weitergegeben damit es irgendwann ins CVS einfliesst. Wie es scheint, ist es wohl in Vergessenheit geraten (auch von meiner Seite, da ich nicht nachgehakt habe), wäre aber schön wenn man das nacholen könnte, damit neutrinoTV noch ein bischen länger funktionieren kann.

Wenn der patch angepasst werden muss, dann muss ich leider dazu sagen, dass mir aktuell die Zeit dazu fehlt; ich habe seit 2007 kein neues image mehr compiliert und hab somit vmtl keine ahnung wo ich hingreifen muss, wenn der patch nicht mehr direkt anwendbar ist. Ich kann allerdings gerne und jederzeit Fragen zu der Funktionsweise des patches beantworten, falls ein anderer dev das versucht anzupassen.

Beste Grüße
Arno

[rhabarber1848]

wo ich hingreifen muss, wenn der patch nicht mehr direkt anwendbar ist.

Der Patch kompiliert mit dem aktuellen CVS, nur kann ich dessen Funktionalität hier nicht testen.

[rhabarber1848]

committed:
http://article.gmane.org/gmane.comp.vid ... x.scm/2102

[arno-neutrinoTV]

Nochmals (auch hier) Dankeschön!

Grüße,
Arno