Test Movieplayer mit "(c) Wabber-Queue"

[gmo18t]

Hi,

so hier nun ein paar Details zum Test.

1. Kann's - wie schon gesagt - nicht selbst ausprobieren. Ist deshalb ein "unbenutztes neutrino mit cvs-Stand von gestern od. vorgestern und könnte wohlmöglich der totale Reinfall werden ...

2. Diese "neutrino" ist meine spezielle Version mit
- nfs und streamer-Unterstützung
- mit neuer Pointer-Queue (Wabber-Queue)
- ohne vlc-Server Unterstützung
- ohne moviebrowser Unterstützung

3. zu finden gibt es das binary (neutrino-ptrqueue) an sich und dann die erforderlichen movieplayer-Sourcen (mp-ptrqueue.tar) hier:
http://lvempeg.sourceforge.net/test/mp/
Wer's selbst compilieren möchte, sollte diese Sourcen nach 'apps/tuxbox/neutrino/src/gui' kopieren und in "vcrcontrol.c/h" jeweils "#define MOVIEBROWSER" deaktivieren bevor der build gestartet wird.

4. Das Konzept ist so umgesetzt wie ich es im Thread unter der Rubrik "Features Requests" beschrieben hab. Vor allem sollte beim Leerlaufen des Puffers kurz der Stream pausieren (bisher noch ohne Anzeige einer "Puffern..."-Box).
Die Tests sollten sich erst mal auf NFS beschränken, für streamer muß ich noch ein paar Kleinigkeiten anpassen.
Jetzt noch was zur Dimensionierung der Queue bzw. der Puffer:
- 1 Segment ist (32 * 920) bytes groß (hab dabei auf 188Byte alignment geachtet)
- Der Puffer des demux-devices ist genauso groß wie ein Segment (mit ein wenig Reserve, damit's nicht unerwartet klemmt)
- Die Pointer-Queue kann maximal 24 Segmente aufnehmen (high-water)
- Die "low-water" Marke ist auf 2 gesetzt
- Die Optimal-Marke liegt bei (high*3/4)

Die Parameter zur Dimensionierung stehen gleich ganz oben in "movieplayer.cpp", wobei:
"#define SIZE_QUEUE_SEG" die Größe eines Segmentes darstellt und eher nicht geändert werden soll.
"# define N_SEGS_FILE" legt die maximale Anzahl Segmente fst, die in die Queue eingestellt werden können -> Die kann bis auf 24 hochgedreht werden.

6. Zum Testen, muß in einer passenden Laufzeit, z.B. ein aktuelles "yadd" das Origianl-neutrino durch das "neutrino-ptrqueue" ersetzt werden. Alle Einstellungen sollten für's TS-Abspielen via NFS gemacht sein. Der Prüfling (Film) sollte eine vorhandene neutrino-Aufnahme (unmodifiziert sein)

7. Könnte sein, daß Aufnehmen mit diesem neuen neutrino nicht funktionieren ...

8. Wenn man neutrino von einer telnet-session startet, kann man den debug-output beobachten ...
Wäre erst mal prima, wenn's irgendwie spielt - wer weiß was für Fehler noch alles auftauchen.

Na dann viel Spaß ...

- GMo -

[gmo18t]

Hi,

und nochwas: weil ja nun mehr context-switches wegen eines weiteren Threads (zum Lesen) und auch mehr Funktionsaufrufe etc. hinzugekommen sind, wird auch die CPU-Belastung wachsen.

Also auch diese gilt es, zu beobachten ...

- GMo -

[wolgade]

Ich schau mir das heute Abend mal an. Blöderweise habe ich keine wirklich ruckelnden Streams.

[gmo18t]

Ich schau mir das heute Abend mal an. Blöderweise habe ich keine wirklich ruckelnden Streams.

wenn's man überhaupt spielt, wär ja schon prima !


- GMo -

[PauleFoul]

@gmo18t

Schade dann kann ich leider net testen... Hab nur via CIFS gemountet...


Gruß
____Paule

[gmo18t]

@gmo18t

Schade dann kann ich leider net testen... Hab nur via CIFS gemountet...


Gruß
____Paule

Cifs geht auch, aber hat natürlich wesentlich weniger Durchsatz als NFS

- GMo -

[PauleFoul]

@gmo18t

Schade dann kann ich leider net testen... Hab nur via CIFS gemountet...


Gruß
____Paule

Cifs geht auch, aber hat natürlich wesentlich weniger Durchsatz als NFS

- GMo -

Hmm. Irgendwie stürzt Neutrino ab wenn ich den Movieplayer starte.
Kurzer Netztraffic (Buffer füllen) is aber noch da...

Code: Alles auswählen

[mp] Startplay
[mp] PlayFileThread starts
[mp] found pida[0]: 0x00C0, ac3=0
[mp] plain TS file with vpid=(0x00E0) apid=(0x00C0) ac3=(0)
[mp] reader thread started ...
Segmentation fault
zapit shot down :)

Gruß
____Paule

[petgun]

Hmm. Irgendwie stürzt Neutrino ab wenn ich den Movieplayer starte.
Kurzer Netztraffic (Buffer füllen) is aber noch da...

wundert mich jetzt nicht: Hast Du jemals einen Geschwindigkeitstest mit CIFS gemacht? Zumindest beim Versuch mit der maximal moeglichen Geschwindigkeit zu schreiben ist mir Neutrino _regelmaessig_ um die Ohren geflogen...lesen weiss ich nicht mehr. Installiere Dir lieber mal einen NFS-Server und teste dann noch mal.

[Tommy]

@gmo:

seh ich das richtig - einfachste testmethode:

dein neutrino (binary) nach /var/bin,
danach killall -9 neutrino,
danach /var/bin/neutrino?

Falls Du nochmal an den source rangehst - kannst Dus so einrichten das man N_SEGS_FILE als parameter übergeben kann? Würde die tests für viele Leute einfacher machen

[petgun]

Ich schau mir das heute Abend mal an. Blöderweise habe ich keine wirklich ruckelnden Streams.

...ich kann heute Abend leider nicht testen.
Mein Vorschlag fuer Leute wie Dich die testen wollen aber keine ruckelnden Streams haben: Irgendwas vom ZDF/3sat aufnehmen was garantiert in Spitzen mit der Datenrate ueber 8Mbps geht. Dann das Netzwerk auf max 7 Mbps fuer die Wiedergabe 'suboptimieren' zB. durch verkleinern von rsize...das sollte dann trotzdem einwandfrei klappen wenn die Datenrate nicht ueber laenger Zeit (wie gross ist der Buffer eigentlich?) >7 Mbps ist.

[wolgade]

Leider der gleiche Crash wie bei PauleFoul.

Code: Alles auswählen

[mp] actionKey=tsplayback
[ConfigFile] Unable to open file /var/tuxbox/config/bookmarks for reading.
[mp] connecting to streamer (10.10.10.10:8080) ...
[mp] ... failed.
[mp] setting parental to (0)
sh: /var/bin/parental.sh: not found
[timeThread] time(): 24.02.2006 19:18:52, tim: Fri Feb 24 19:18:52 2006
[mp] Startplay
[mp] PlayFileThread starts
[mp] found pida[0]: 0x025A, ac3=0
[mp] plain TS file with vpid=(0x0259) apid=(0x025A) ac3=(0)
[mp] reader thread started ...
[mp] entering player loop
[mp] clear queue done
Segmentation fault
zapit shot down :)
Waiting for controld (max. 9 seconds)
[zapit.cpp:main:2385] shutdown complete
Waiting for controld (max. 8 seconds)
Waiting for controld (max. 7 seconds)
Waiting for controld (max. 6 seconds)
Waiting for controld (max. 5 seconds)
Waiting for controld (max. 4 seconds)
Waiting for controld (max. 3 seconds)
Waiting for controld (max. 2 seconds)
Waiting for controld (max. 1 seconds)
CXA2092 found
The system is going down NOW !!
Sending SIGTERM to all processe[nhttpd] stop requested......
Sending SIGKILL to all processes.
The system is halted. Press Reset or turn off power

Und aus die Maus.

[gmo18t]

... ja, so sieht das dann aus, wenn man nicht selbst "live" gehen kann Aber einen segfault-Verursacher hab ich schon gefunden.
Wird aber noch dauern bis ich den nächsten Schuß freigeben kann.

- GMo -

[wolgade]

Sag bescheid, wenn es soweit ist. Eine Datei in die Yadd zu schieben geht ziemlich fix.

[Npq]

@gmo18t: Der Puffer im Demux-RAM ist zur Zeit bei SPTS genau 128 kiByte groß, wenn du 1 MiB per write() übergibst, werden diese 1 MiB in 188 Byte-Blöcken direkt ins Demux-RAM geschrieben.

Der Transfer ist blockierend, es wird aber nicht gewartet bis die gesamte Queue leer läuft, sondern bis eben 188 Byte frei sind.

Wenn ich dazu komme (im Moment leider wie üblich nicht) probiere ich mal, das zu profilieren (eine kritische Aufnahme habe ich schonmal *g*).

Aber bin erst mal gespannt, wie dein Level-Triggered-Ansatz (zu deutsch "Waber") funktioniert.

[gmo18t]

... sooo, wer nun nochmal einen Testlauf durchführen möchte, kann jetzt wieder ein frisches neutrino (gleicher Link wie oben) downloaden.

viel Erfolg ...

- GMO -

[wolgade]

Klappt erst heute abend. Poste dann die Ergebnisse.

[petgun]

... sooo, wer nun nochmal einen Testlauf durchführen möchte, kann jetzt wieder ein frisches neutrino (gleicher Link wie oben) downloaden.
viel Erfolg ...

..leider kein Erfolg. Hab' das Teil in eine aktuelle Yadd von DietmarW kopiert...der Movieplayer klappt auch, allerdings ohne Bild (Video wird aber auch uebertragen)...und der Ton ruckelt (Aussetzer) bei dem bereinigten Testfile.

[gmo18t]

... leider schlechte Nachrichten - es hat sich ausgewabbert: bin jetzt mal dazugekommen, selbst etwas intensiver zu testen und leider wird durch die Thread-Synchronisation (locks, context-wechsel), der Fluß des Streams deutlich gestört, d.h. vor allem zwischen den einzelnen write-calls in's DVR-Device gibt es zu lange Pausen, so daß der demuxer "nonstop" Aussetzer hat und zu den durch petgun beschriebenen Symptomen neigt !

Grundidee war ja, mit einer relativ kleinen Segmentgröße (ca. 30K) zu arbeiten. Das bewirkt halt relativ viele read/writes, die sich gegenseitig "sperren" bzw. "aufhalten" (bitte nicht mit deadlocks verwechseln)

Bei größeren Segmenten, aber enstprechend (zu) kleiner Queue, spielt der Film schon besser sogar ruckkelfrei über längere Passagen, doch immer noch alles andere als aktzeptabel und gleichfalls ist damit das von mir erdachte Prinzip hinfällig, weil es ja nur Sinn mit kleinen Segmenten macht.

Die bisherige Methode, das Lesen und Schreiben innerhalb des selben Threads in einer Schleife zu erledigen, bewährt sich also schon. Deshalb hab ich als letzten Versuch ein dazu passendes Verfahren implementiert, das ein wenig dem "Wabber" ähnelt aber wesentlich besser läuft (hab's schon in echt getestet):

Es wird ein größerer Puffer verwendet (ca. 1MB). Auch hier wird nur mit "Happen" von ca 30K gefüllt, jeweils Lesen und sofort Schreiben.
Jedoch nach dem Start des Films (oder nach Springen u.ä.) wird der Demuxer solange angehalten bis der Puffer mit genügend read/write vollständig gefüllt wurde - dann erst wird der Demuxer gestartet.

Das kann man mit einem Badewanne vergleichen, die per Eimer gefüllt wird. Allerdings bleibt der Ablauf erst mal solange verschlossen, bis die Wanne voll ist, danach zieht man den "Stöpsel" und versucht das auslaufende Wasser mit neuen "Eimer-Happen" auszugleichen ...

Solange also die Bitrate niedrig ist wird der Puffer (die Wanne) voll bleiben, wenn Spitzen auftreten, sollte dies durch die vorhandene Reserve abgefangen werden. Danach kann sich der Puffer auch wieder erholen, aber nur wenn die anschließende Bitrate längere Zeit geringer ausfällt als der maximale Netzwerkdurchsatz.

Nun kann man diesen Puffer auch größer auslegen z.B. das Doppelte und den Demuxer nur solange anhalten, bis er halbvoll ist (würde z.B. auch mit 3/4 oder 1/4 Füll-Variationen funktionieren).
Vorteili: Wenn dir durchschnittliche Bitrate geringer als der Netzwerkdurchatz ist, sollte der Puffer eher in Richtung voll laufen und hätte auch Reserve für mehrere Sekunden Spitzen im Stream. Andererseits würde es nach dem Springen, nicht zu lange dauern, bis man wieder ein Bild sieht.

Nur eins kann man mangels DBox Resourcen nicht - egal mit welchem ausgeklügelten Prinzip: einen Stream ruckelfrei abspielen, dessen durchschn. Bitrate größer als der maximale Netzwerkdurchsatz ist !

Für die Auslegung der maximalen Puffergröße muß man sich noch einen sinnvollen Wert überlegen. Ich werd jetzt mal für's Erste ein neutrino bereitstellen, welches einen 2MB Puffer verwendet, der nach obigen Prinzip beim Start zu 1/2 "vorgefüllt" wird.

Damit man später in Tests verschiedene Szenarien vergeichen kann, werd ich dann bei Gelegenheit noch den Wert, der für die Anzahl Puffer bei der Direktaufnahme in den neutrino settings existiert, auch als faktor zu Festlegung der Puffergröße im movieplayer "mißbrauchen"
Ist halt weniger Aufwand für mich und man braucht nicht immer neu zu compilieren !
...und irgendwann (wenn's passt) kann das als eigenständige Option in die Settings rein.

- GMo -

[gmo18t]

... und hier ist das binary
http://lvempeg.sourceforge.net/test/mp/neutrino

viel Spaß !

- GMo -

[petgun]

...Nur eins kann man mangels DBox Resourcen nicht - egal mit welchem ausgeklügelten Prinzip: einen Stream ruckelfrei abspielen, dessen durchschn. Bitrate größer als der maximale Netzwerkdurchsatz ist !

Für die Auslegung der maximalen Puffergröße muß man sich noch einen sinnvollen Wert überlegen. Ich werd jetzt mal für's Erste ein neutrino bereitstellen, welches einen 2MB Puffer verwendet, der nach obigen Prinzip beim Start zu 1/2 "vorgefüllt" wird..

..es wird fuer viele entaeuschend sein, dass so etwas (ZDF 'Diabolic'):



imo so gut wie unmoeglich ruckelfrei mit dem Moveiplayer ueber Netzwerk abzuspielen ist...ein Kaestchen sind etwa 6 Sekunden auf der Zeitachse...selbst wenn Dein Waber-Ansatz die Situation verbessert, so einen grossen Buffer der da evtl. hilft, kann man imo auf der Box nicht implementieren. Ich playdiere fuer die 'Reparatur' der vorhandenen Ringbuffer-Implementation.

Vielen Dank fuer Deine Muehe,
peter

[gmo18t]

...
Ich playdiere fuer die 'Reparatur' der vorhandenen Ringbuffer-Implementation.

ich glaube, du hast auch nicht verstanden wie ein Ringpuffer funktioniert ?
Aber egal, es gibt ja auch keine bisherige "Ringbuffer-Implementation" beim TS-Abspielen !
... Ringpuffer gibt's nur, wenn per VLC abgespielt wird ...

ich klink mich jetzt aus, hab da sowieso schon zuviel Zeit reingesteckt.

- GMO -

[petgun]

..ich glaube, du hast auch nicht verstanden wie ein Ringpuffer funktioniert ?

..ich glaube unterscheiden zu konnen zwischen dem was Du als waber-queue und dem was Du als klassischen Ringbuffer bezeichnest.

Aber egal, es gibt ja auch keine bisherige "Ringbuffer-Implementation" beim TS-Abspielen !... Ringpuffer gibt's nur, wenn per VLC abgespielt wird ...

das wirst Du besser wissen...ich denke das was Gagga versucht hat zu coden sollte wohl das werden was bei Euch Informatikern als Ringbuffer bezeichnet wird.

ich klink mich jetzt aus, hab da sowieso schon zuviel Zeit reingesteckt.

alles klar...muss ich jetzt wieder als Spielverderber oder als Grund fuer Deinen Rueckzug herhalten? Beweise doch einfach das ich keine Ahnung habe und Deine waber-queue hier beim Movieplayer zum Erfolg fuehrt.

[petb]

...
Ich playdiere fuer die 'Reparatur' der vorhandenen Ringbuffer-Implementation.

ich glaube, du hast auch nicht verstanden wie ein Ringpuffer funktioniert ?
Aber egal, es gibt ja auch keine bisherige "Ringbuffer-Implementation" beim TS-Abspielen !
... Ringpuffer gibt's nur, wenn per VLC abgespielt wird ...
ich klink mich jetzt aus, hab da sowieso schon zuviel Zeit reingesteckt.
- GMO -

Hohecker, sie sind raus.
Was, wieso das denn ?

Ne im Ernst, hab ich dein Posting falsch verstanden ?
Ich dachte das das zweite jetzt von dir angedachte Szenario das ganze im gleichen Thread zu machen besser geht ?!?!?!?

Das es nicht geht wenn der Netzwerkdurchsatz dauerhaft zu hoch ist, war ja klar.
Aber wenn ich einge ZDF Streams abspiele, hat es bisher noch nie geruckelt, solange es um eine oder auch mehrere Boxen ging die nur abgespielt haben.
Nur wenn auch einige gleichzeitig aufgenommen haben war es ruckelig, weil eben ab und zu kurze Stopper im Netz sind.

Da würde es hoffe ich bestimmt was bringen.
Und die Stereams die ich mir mal angeschaut habe sind alle mit stark schwankenden Raten, ich hatte noch keine die über 9MBit ging.
Aber jede Menge die mal 6 MBit und ab und zu mal Richtung 8 usw. gingen.
Also auch da hoffe und glaube ich würde es was bringen.
Und nicht zuletzt auch wenn ich mehrere Boxen betrachte und niederratige Streams abspiele.
Alle die mehr als 1 Box haben und gleichzeitg auf und abspielen wollen würden dann profitieren.

Und als Parameter den Ringbuffer bei der Aufnahme zu nehmen, ist doch ok.

Ich fände es jetzt schade, wenn das ganze wieder in der Versenkung verschwinden würde.
Also sag ich bitte, gib nicht so schnell auf.
Bye
PetB

[digi_casi]

im enigma vlc movieplayer ist ein einfacher fifo (den gabs schon in enigma) implementiert... ein thread schreibt so schnell wie moeglich rein, der andere fuettert dvr... fertig.
denke sowas sollte der "ringbuffer" auch machen... aber vielleicht hat er ja n bug.

[gmo18t]

...
Ich fände es jetzt schade, wenn das ganze wieder in der Versenkung verschwinden würde.
Also sag ich bitte, gib nicht so schnell auf.

... muß leider andere Prioritäten setzen, hab nämlich schon zu viel meiner verfügbaren Zeit verbraten.
Da das Ergebnis bisher noch nicht überwältigend war und im Vergleich zur bisherigen Lösung nicht unbedingt eine erkleckliche Verbesserung erreicht wurde (auch nicht mit meinem letzten Vorschlag), ist es mir einfach zu schade da noch mehr Aufwand reinzustecken.

@digi_casi:
so wie's bisher läuft ist das ja auch nix anderes als ne fifo: der movieplayer (= der eine Thread) liest die Daten vom Netz so schnell er kann und schreibt sie in den Puffer des Treibers (= der andere Thread). Dieser zieht saugt die Daten dort eben raus und schafft wieder neuen Platz.

Und mal so nebenbei: es entseht langsam so der Eindruck, daß der movieplayer nur noch ruckelt. Also eigentlich spielt er ja ganz prima und wenn man seine Netzwerkinfrastruktur vernünftig zusammen hat, dann sogar auch die allermeisten Filmen problemlos.

- GMo -