Größerer Buffer beim Movieplayer

[wolgade]

Warum sollte man jetzt noch einen neuen Fred aufmachen...was gibt es da noch zu diskutieren?

Ging nicht ums diskutieren. Das wird hier über mittlerweile 14 Seiten gemacht. Gerade deshalb hatte ich die Befürchtung, daß Gagga oder andere, die hilfreich sein könnten, einen ernstzunehmenden Bugreport schlicht nicht mitbekommen. Wenn gmo18t das Problem jetzt löst, kann man sich einen zusätzlichen Thread tatsächlich schenken.

ausserdem ist da ein "ringbuffer" drin... ziemlich unuebersichtliches gebilde... von dem ich annahm, dass er die pufferung zwischen empangsthread und anzeigethread herstellt.

Ich hab selber gerade mal in den Code geguckt und bin nicht wirklich schlau draus geworden. Das kann aber an mir liegen. C ist nicht so mein Ding, hab halt mal Pascal gelernt. Der Code ist vor allen Dingen sehr spärlich kommentiert.

'©wabber-queue' ist eher erstes Semester Informatikstudium und ein funktionierender Ringbuffer mit dem ganzen Pointerhandling ist wahrscheinlich etwas schwieriger zu coden und zu debuggen und vielleicht >zweites Semester, oder?

Hier liegst du meiner Ansicht nach falsch. Die "wabber-queue" ist nichts anderes als ein funktionierender Ringpuffer mit dem ganzen Pointerhandling. gmo18t will den Ringpuffer in einen eigenen Thread verfrachten, was ich für eine gute Idee halte.

Edit:
@gmo18t: Da sich unsere Postings überschnitten haben: Ich rede von TS-Abspielen über NFS. In movieplayer.cpp habe ich aber auch hauptsächlich VLC-Gedöns gefunden. Wo ist die Methode zum TS-Abspielen implementiert?

[PauleFoul]

...warum wird der Teststreifen aus dem RAM sauber gespielt?

mein Teststreifen ist ungeeignet und kann imo auch nicht fehlerfrei aus dem Ram abgespielt werden...der Womble Mpeg Video Wizard scheint bei *.ts Ausgabe nicht Movieplayer kompatibel zu muxen wenn die Audiospur >192kbps ist.

Petgun glaub mir einfach. Er läuft aus dem RAM erste Sahne. Über Netz
ruckelt er sich einen ab...

(getestet mit Sagem 64MB)


Gruß
____Paule

[PauleFoul]

...tja, das dachte ich auch - paule hat aber berichtet, dass er ein Teil aus DEINEM "Womble-Schnipsel" fehlerfrei abgespielt hat....und eben das irritiert mich (nach wie vor )....

..er hat nicht verraten welchen Teil und wie er das Teilstueck erzeugt hat...ein Schnitt mit einem geeigneten Programm reicht schon um den 'Fehler' zu beseitigen....der generell auch erst nach >30 Sekunden eintritt.

Mit ProjektX das Ende weggeschnitten. Damit ich das Teil in den Speicher
bekomme. Über Netzwerk läuft das geschnitte übrigens genau so schlecht
wie das ungeschnitte.

Gruß
____Paule

[PauleFoul]

@all hier,

ääääähhhm, ich bin ja schon mal gespannt auf das Ergebnis, was passiert wenn die Theorie von gmo18t umgesetzt wird/ist. Sehe ich das richtig, dass es ungefähr dem entspricht was Teddy278 schon wollte?

Ob das aber mit der LED so wirklich der ideale Beweis ist, halte ich für fraglich. Es zeigt nur das ständig Daten übertragen werden, in welcher Datenmenge allerdings nicht. Es kann genauso gut ein Zeichen dafür sein, dass der Buffer derzeit ständig aufgefüllt/nachgefüttert wird. Wenn bei der Übertragung UDP Pakete verloren gehen und der Buffer gerade neu gefüllt wird/werden soll zeigt die LED auch fast keine Reaktion - das ist für mich ein schlechteres Zeichen als die ständig blinkende LED bei funtionierender Übertragung

Spooky

Da müssen aber viele Pakete verloren gehen wenn die LED immer bis
zum Ende blinkt. Ausserdem wird ein "PaketLost" normal beim füllen
des Speichers gehandelt und nicht beim Leeren... (Kleines Handshake 1x1)


Gruß
____Paule

[gmo18t]

@PauleFoul
nochmal nachgefragt: benutzt Du bei deinen Tests immer "TS abspielen" über NFS-filesystem ?

- GMo -

[wolgade]

@gmo18t: Ich bin zwar nicht PauleFoul, aber ich kann seine Angaben bestätigen und benutze TS über NFS. Mein Edit oben hast du wahrscheinlich übersehen.

[PauleFoul]

ich steuere hier mal mein wissen zu, da ich mir den neutrino mp angeschaut habe, bevor ich den fuer enigma implementiert habe...
am anfang werden 3(?) s video gebuffert, weil man als erstes mal die pids bestimmen muss...
ausserdem ist da ein "ringbuffer" drin... ziemlich unuebersichtliches gebilde... von dem ich annahm, dass er die pufferung zwischen empangsthread und anzeigethread herstellt.
offensichtlich ist dann ein bug drin zwischen dem anfaenglichen buffern zur bestimmung der pids und dem anschliessenden abspielen dieses buffers und dem weiteren xfer von daten vom pc.

du beziehst dich aber jetzt auf den VLC basierten Teil des movieplayers.
der ist hier erst mal nicht gemeint. Ich hoffe der Test von @PauleFoul wurde mit "TS abspielen" über NFS gemacht (hatte ich bisher gar nicht nachgefragt) ...

- GMo -

Nee über VLC!!

Quatsch... ist ein TS-File gewesen. Über TS-abspielen.


Gruß
____Paule

[PauleFoul]

@PauleFoul
nochmal nachgefragt: benutzt Du bei deinen Tests immer "TS abspielen" über NFS-filesystem ?

- GMo -

Das Verzeichnis ist über CIFS gemountet.


Gruß
____Paule

[PauleFoul]

An alle die hier gerade alles was meine Person betrifft in Frage stellen!

Entschuldigung das ich nach einem Problem gesucht habe was anscheinden nicht da sein darf und keinen Enduser interessiert.

Hätte ich gewusst das eine so (Entschuldigung) blödsinnige Diskussion
daraus entsteht hätte ich die Erkenntnis nicht gepostet.


Paule

[digi_casi]

also wir muessen hier schon unterscheiden, ueber was wir reden...
ts-abspielen ueber nfs oder cifs und ts-abspielen ueber vlc sind zwei unterschiedliche paar schuh und auch unterschiedlicher code.

[Spooky]

...warum wird der Teststreifen aus dem RAM sauber gespielt?

mein Teststreifen ist ungeeignet und kann imo auch nicht fehlerfrei aus dem Ram abgespielt werden...der Womble Mpeg Video Wizard scheint bei *.ts Ausgabe nicht Movieplayer kompatibel zu muxen wenn die Audiospur >192kbps ist.

Petgun glaub mir einfach. Er läuft aus dem RAM erste Sahne. Über Netz
ruckelt er sich einen ab...

(getestet mit Sagem 64MB)


Gruß
____Paule

gmo18t hat Folgendes geschrieben:
@PauleFoul
nochmal nachgefragt: benutzt Du bei deinen Tests immer "TS abspielen" über NFS-filesystem ?

- GMo -


Das Verzeichnis ist über CIFS gemountet.


Gruß
____Paule

Es stellt keiner Deine Person in Frage, aber Du hast leider ab und zu am Thema vorbei geantwortet. Die Abspielprobleme, unabhängig von der Buffer Problematik, erklären sich mit Deiner letzten Antwort von selbst. Wenn Du nicht gerade eine Dreambox benutzt, dann ist CIFS zu langsam für viele Streams. Und mir liegt die Vermutung nahe, dass Du das Ruckeln im Vorspann des Testfiles meinst , richtig ? Wenn ja, hast Du und petgun aneinander vorbeigeredet.

Spooky

[PauleFoul]

Es stellt keiner Deine Person in Frage, aber Du hast leider ab und zu am Thema vorbei geantwortet. Die Abspielprobleme, unabhängig von der Buffer Problematik, erklären sich mit Deiner letzten Antwort von selbst. Wenn Du nicht gerade eine Dreambox benutzt, dann ist CIFS zu langsam für viele Streams. Und mir liegt die Vermutung nahe, dass Du das Ruckeln im Vorspann des Testfiles meinst , richtig ? Wenn ja, hast Du und petgun aneinander vorbeigeredet.

Spooky

An alle die hier gerade alles was meine Person betrifft in Frage stellen!

Entschuldigung das ich nach einem Problem gesucht habe was anscheinden nicht da sein darf und keinen Enduser interessiert.

Hätte ich gewusst das eine so (Entschuldigung) blödsinnige Diskussion
daraus entsteht hätte ich die Erkenntnis nicht gepostet.


Paule

Es geht hierbei um die Buffer Geschichte und nicht um den Teststreifen.

Fakt ist, das es aus dem RAM läuft. CIFS hin oder her!

Und an Petgun rede ich bestimmt nicht vorbei...


Gruß
____Paule

[petgun]

...man..ich dachte jetzt brauchen wir nur noch auf die Umsetzung von gmo18t warten...stattdessen geht die Diskussion hier weiter

@PauleFoul
...ich bin schon sehr verwundert das Du mit CIFS arbeitest...nach meiner Erfahrung ist mit CIFS bei max. 6,5 Mbps Schluss mit lustig.
Mein Testfile ist ungeeignet und nur wenn Du das Teil _komplett_ ohne Nachbearbeitung/Schnitt aus dem Ram abspielen kannst, waere 'ruckelfrei' eine Ueberraschung. Ich gehe davon aus, dass Womble den Stream fuer den Schnitt demuxen/muxen muss und das macht es bei Streams mit einer Audiospur >192kbps die als *.ts ausgegeben werden nicht richtig/anders als der Movieplayer das haben moechte...das hat mit der Bufferdiskussion hier _nix_ zu tun.

Die gleichzeitige Beobachtung der Netzwerktransfer-LEDs und der Darstellung des Streams mit dem Movieplayer kann man imo auch unter CIFS so interpretieren das etwas mit dem Bufferhandling nicht stimmt und ich hoffe das wird jetzt nicht schon wieder in Frage gestellt.

[wolgade]

Irgendwie werden hier mehrere Dinge gleichzeitig diskutiert. Und ich schreib es jetzt noch ein drittes Mal:

Ich kann die Beobachtungen von PauleFoul bestätigen, und ich nutze TS-Abspielen über NFS.

Und jetzt geh ich das Werk von gmo18t testen. Ist fruchtbarer als dieser Thread.

[petgun]

Und jetzt geh ich das Werk von gmo18t testen. Ist fruchtbarer als dieser Thread.

..ein 'Werk' dass es mit Sicherheit nicht geben wuerde, wenn es diesen un'fruchtbaren' Thread nicht gaebe.

Und ich schreib es jetzt noch ein drittes Mal:

..tja, haetten wir nur von Anfang an auf Dich gehoert ;-) Jetzt hast Du doch einen neuen uebersichtlichen Fred und brauchst Dich hier nicht mehr zu wiederholen....und wenn Du Dich nicht ab Seite...13 diese Freds so kompetent und rege an der Diskussion hier beteiligst haettest, waere es sicher nicht so gut ausgegangen...Danke!

[wolgade]

..ein 'Werk' dass es mit Sicherheit nicht geben wuerde, wenn es diesen un'fruchtbaren' Thread nicht gaebe.

Das stell ich nicht in Abrede. Aber hier wird über mehrere Dinge durcheinander geredet. Das und nur das halte ich für unfruchtbar.

Jetzt hast Du doch einen neuen uebersichtlichen Fred und brauchst Dich hier nicht mehr zu wiederholen....

Ich hab mich wiederholt, weil wiederholt gefragt wurde, ob hier von TS über NFS die Rede ist. Irgendwie scheint das jedesmal verlorengegangen zu sein. Kein Wunder, wenn jeder über was anderes redet. Deshalb hab ich es mal mit Fettschrift probiert. Scheint jetzt funktioniert zu haben.

....und wenn Du Dich nicht ab Seite...13 diese Freds so kompetent und rege an der Diskussion hier beteiligst haettest, waere es sicher nicht so gut ausgegangen...Danke!

Manchmal verrutscht du schon ein bißchen auf der Tastatur, oder?

Kannst du mir mal bitte zeigen, wo ich mir hier selber Lorbeeren verpasst habe!

Ich habe die Beobachtung von PauleFoul überprüft und bin zum gleichen Ergebnis gekommen. Hinterher hat sich dann herausgestellt, daß wir unterschiedlich mounten. Mir ging es dann darum klarzustellen, daß das Phänomen nichts mit irgendeiner CIFS-Problematik zu tun hat, sondern unter NFS auch auftritt. Das alles ändert nichts daran, daß PauleFoul der erste war, der mal einen Blick auf die Netzwerk-LED geworfen hat.

[petgun]

hi,
der fred ist ja hier gegessen...kann man also auch mal was fuer die Informatikbildung tun..

'©wabber-queue' ist eher erstes Semester Informatikstudium und ein funktionierender Ringbuffer mit dem ganzen Pointerhandling ist wahrscheinlich etwas schwieriger zu coden und zu debuggen und vielleicht >zweites Semester, oder?

Hier liegst du meiner Ansicht nach falsch. Die "wabber-queue" ist nichts anderes als ein funktionierender Ringpuffer mit dem ganzen Pointerhandling.

..ich bin kein Informatiker verstehe unter einem Ringbuffer aber etwas anderes als unter der von gmto18 beschriebenen ©wabber-queue.

Nach meinem Verstaendnis gibt es bei einem Ringbuffer diese Action-Trigger Marken 'low-high water marks' nicht, sonder 'nur' zirkulierende Pointer auf die naechste freie/zuletzt belegte Speicherzelle und es wird staendig gelesen und geschrieben.
Bei der ©wabber-queue wird der Buffer zB. erst dann wieder gefuellt wenn der Fuellstand unter die low-water Marke sinkt. Imo ist das nicht so 'elegant' wie ein Ringbuffer.
Was man idealerweise einsetzt um ein bestimmtes Problem zu loesen, also Ringbuffer oder so eine wabber-queue weiss ich nicht...wuerde mich aber interessieren.
Ich hoffe wir bekommen hier noch die kompetente Erklaerung eines Fachmanns.

cu,
peter

[Torsten73]

Hi,
da hat man mal 2 Tage keine Zeit und darf dann 3 Seiten lesen

Also an der Wabber-Queue sehe ich noch einen Vorteil, nämlich dass die Netzauslastung etwas gleichmäßiger wird. Das könnte sich ebenfalls positiv auswirken.

Ich will Euch mal eine Beobachtung aus den Anfängen meiener Movieplayer Versuche schildern (sofern ich das noch richtig hinbekomme):

Früher habe ich mit JTG aufgenommen und UDREC. Damals habe ich die HDD LED beobachtet und die blinkte schön regelmäßig bei der Aufnahme.

Dann kam DirectRecording. Und ich stelle auf SFU-NFS um. Seitdem macht die Festplatten LED beim Aufnehmen nur noch stakato.
Das gleiche gilt bei der Wiedergabe, die damals noch mit VLC gemacht wurde.
Ich hatte damals schon gefragt, ob das Normal ist. Konnte aber keiner mir Erklären und habe es auch nicht weiter hinterfragt, da es ja anscheinend "funktionierte".

Nun wenn ich das mal mit Euren Beobachtungen kombiniere, dürfte das auch auf einen nicht optimalen Puffer hinweisen, oder? Denn wenn der Puffer 3s beträgt, sollte tatsächlich immer Peakweise Maximalauslastung sein, dann kurz Pause, dann wieder volles Rohr, etc. Aber das wurde ja schon geschrieben.

Ich bin mal auf Gmo es Versuche gespannt. Ich stelle mich natürlich auf fürs Testen zur Verfügung...

Cu
Torsten

[gmo18t]

Bei der ©wabber-queue wird der Buffer zB. erst dann wieder gefuellt wenn der Fuellstand unter die low-water Marke sinkt. Imo ist das nicht so 'elegant' wie ein Ringbuffer.

... dann hast Du aber nicht richtig gelesen, denn das Auffüllen ist im Prinzip immer aktiv. Das Wiederbefüllen ist nicht von der low-Marke abhängig, sondern von der Optimal-Marke, die ungefähr so groß ist wie high !
Ringbuffer sind normaleweise fix in der Grösse und eher was für bytweises Puffern. Ne Pointer-Queue (fifo) kann ich im Prinzip dynamisch wachsen/schrumpfen lassen (hab ich aber noch nicht so geproggt), um kurzeitig Spitzen abzufangen und außerdem lassen sich damit ganze "Datenblöcke" (Segmente) elegant und effizient handlen.

Im übrigen würde dir ja dann bereits 1 Semester, also nur 3-6 Monate, ausreichen, um in Zukunft auch längere Threads in der "developer"-Rubrik treiben zu können ...
Dann würde sich die Codequalität im CVS auch wahrscheinlich mächtig steigern. Ich sehe schon den petgun eschen Einzeiler für "HDTV jetzt doch auf der DBox" vor mir.

- GMo -

[petgun]

Im übrigen würde dir ja dann bereits 1 Semester, also nur 3-6 Monate, ausreichen, um in Zukunft auch längere Threads in der "developer"-Rubrik treiben zu können ...
Dann würde sich die Codequalität im CVS auch wahrscheinlich mächtig steigern. Ich sehe schon den petgun eschen Einzeiler für "HDTV jetzt doch auf der DBox" vor mir.

...ich denk drueber nach
Fass dich kurz liegt mir halt nicht...und woher soll ich wissen was ich meine bevor ich es gesagt/gelesen habe?
Verrate mir bitte, wenn das alles so sonnenklar und einfach ist, wie man Dich und die anderen Macher mit kuerzeren Threads ueberzeugen kann das etwas flasch laeuft/der Fehler am code liegt?

[Torsten73]

Und noch eine Beobachtung:

Behauptung:
Der Pufffer soll die Spitzen des Datentransfers abfangen, Umkehrschluß wäre dann, dass der Netzwerktraffik relativ gleichmäßig bliebe, da die Spitzen nicht mehr sich bemerkbar machen dürfen und in den Talphasen müste man eine Anhebung sehen.
Das wird zwar keine gerade Linie, aber wenn man mit Netmeter oder Windows sich den Datenstrom ansieht, verhält er sich zur Zeit exakt proportional zu den Bildsequenzen, d.h. bei starken Bildänderungen von hell nach dunkel oder schneller Bewegung, springt die Transferrate sprungartig hoch. Und genau in den Momenten, wenn in diesem sprungartigen Anstieg die Spitze bei mir über die 1,15 Mb geht kommt es zum Ruckeln.

Ich hoffe das war verständlich

Das ist mind. ein genauso eindeutiger Beweis dafür, das der Buffer eigentlich nicht funktioniert.

Soll heißen wenn Gmo es Version was bringt, müßte man es sofort an der Netzwerkauslastung erkennen können.

Cu
Torsten

[Ekkehard]

Habe mir mal die Mühe gemacht und den ganzen Thread bisher durchgelesen. Puh!

Ich habe nämlich auch ein Ruckler-Problem beim TS-Wiedergeben über CIFS (dbox2 über Router an PC mit Windows XP).
Aber nur, wenn die Auflösung 720 x 576 beträgt. Wird eine Aufnahme mit der Auflösung 480 x 576 wiedergegeben (z.B. SciFi aus Premiere), dann habe ich überhaupt keine Ruckler! In jedem Fall ist die Audio-Rate 192 kbps.

Meine Mount-Parameter sind:
ro,soft,udp nolock,rsize=8192,wsize=8192
Kann man da noch etwas optimieren?

[snowmen]

nur, wenn die Auflösung 720 x 576 beträgt. Wird eine Aufnahme mit der Auflösung 480 x 576 wiedergegeben (z.B. SciFi aus Premiere), dann habe ich überhaupt keine Ruckler!

logisch , durch die reduzierte Bildgröße sind auch weniger Daten zu übertragen .

Meine Mount-Parameter sind:
ro,soft,udp nolock,rsize=8192,wsize=8192
Kann man da noch etwas optimieren?

sollte da nicht ein "rw" stehen ?

wenn Dein Win-NFS das unterstüzt probier mal :

rw, soft, udp, nolock, rsize=8192,wsize=16384 (oder 32768)

und Serverseitig in die exports : <Freigabe> rw , no_root_squash ,async

[gmo18t]

... ein Ruckler-Problem beim TS-Wiedergeben über CIFS ...

dann solltest du mal fleißig weiterlesen im Forum, dann findest du auch eine Erklärung dafür ...

- GMo -

[Zwen]

Der Pufffer soll die Spitzen des Datentransfers abfangen, Umkehrschluß wäre dann, dass der Netzwerktraffik relativ gleichmäßig bliebe, da die Spitzen nicht mehr sich bemerkbar machen dürfen und in den Talphasen müste man eine Anhebung sehen.

Nein, wieso ?
Die Kurve entspricht relativ genau dem Verlauf der Bitrate des Streams.
Es wird ja immer darauf geachtet, dass der Buffer voll ist. Ergo wird bei Sequenzen mit Hoher Bitrate (die viele Bits aus dem Buffer verbrauchen) auch viel über Netzwerk in den Buffer nachgeladen, da er ja schneller geleert wird. Bei ruhigen Sequenzen nimmt der Buffer-Füllstand nur langsam ab, deswegen wird auch nur langsam nachgeladen.
Wenn der Stream nie die maximale Netzwerk-Performance übreschreitet, sollte die Kurve identisch mit dem Bitratenverlauf sein (mal abgesehen von der initialen Befüllung => Max Netzwerk-Traffic und der finalen Leerung => kein Traffic). Wenn es Squenzen gibt, die die Netzwerkperformance überschreiten, geht die Kurve natürlich nicht über die Maximale-Netzwerkperformance hinaus, dafür bleibt sie dann etwas länger am Max-Ausschlag.
Das Ziel des Buffers ist ja nicht eine gleichmässige Netzwerkauslastung zu erzielen, sondern maximale Reserven an Daten zu haben, falls die Daten einmal schneller "verbraucht" werden, als sie gelesen werden können...

Zwen