Größerer Buffer beim Movieplayer

[petgun]

Es gibt halt noch was zu verbessern... wo gibt es das nicht?

ja, mit dieser Erkenntnis bist Du einigen hier voraus....gottaehnliche Gebilde sind aber per Definition nicht zu verbessern.

[teddy278]

Hallo,

soweit ich sehe gibt es schon alles, was wir brauchen... insbesondere ein "Ringbuffer"-Objekt, das die ganze Arbeit macht.

Zum Thema Threads: Das Abspielen von VLC-Streams ist soweit ich sehe tatsächlich so gelöst wie von mir angedacht: Ein Thread liest, einer schreibt und die beiden kuscheln miteinander über den Ringbuffer. Wenn der eine zu schnell ist macht er Pause, wenn der andere zu schnell ist gibt's ne Fehlermeldung.

Irgendwie doch ganz nett, mal wieder in fremden Quelltexten rumzustochern.


Bye,
Christian

[gmo18t]

nächstes Posting ist das Richtige (zu wild geklickt) ...

[gmo18t]

Hallo.

ja der dvrBuf, in den mit "write" geschrieben wird, ist tatsächlich um Einiges größer als die Häppchen, die gelesen werden.

OK - wieviel MB sind es denn? Es ginge mir ja um einen üppigen Puffer, um Spitzen abzufangen wenn der NIC nicht nachkommt. Meine Vermutung ist, daß dvrBuf nicht allzu großzügig bemessen ist (und sich nicht unbedingt leicht vergrößern läßt, insbesondere im Hinblick auf Boxen mit geringem Arbeitsspeicher).

Code: Alles auswählen

#define PF_BUF_SIZE   (800*188)
#define PF_DMX_SIZE   (PF_BUF_SIZE + PF_BUF_SIZE/2)

damit kannst du's ausrechnen ...
Natürlich hab ich auch andere Werte wie oben probiert, aber bei größeren Werten hat sich am Ruckeln nix geändert.

Wäre nicht weiter schlimm, wenn folgende entscheidende Frage beantwortet wäre:
Wieviel Platz wird im Treiber "verputzt" bis "Platz vorhanden" gemeldet wird, also der write()-Aufruf zurückkehrt ?
Etwa der ganze Puffer ??? (das wäre dann ein Ruckelgrund).

Es würde ja schon "reichen", wenn write() zwar sofort zurückkehrt wenn wieder etwas Platz ist ...

... und wer weiß das ?
meine jetzt, bei wieviel Platz das write() zurückkommt, wenn's geblocked ist -> das ist Treibersache !!!
Diese Frage müßte erst beantwortet werden (wär doch schon mal ne Forschungsaufgage für nen gestanden Theoretiker).

Wie wär's wenn man read und write in unterschiedliche Threads legt? Read liest fröhlich vor sich hin, solange Platz im (vorgelagerten, neu zu schaffenden) Buffer ist, und write schreibt so schnell es halt geht die Daten weg, wenn noch welche im Buffer liegen. Wenn write dann warten muß, bis dvrBuf wieder leer ist stört's nicht weiter. Multithreading müßte die dbox doch unterstützen, wenn ich den Text richtig interpretiere?

Extra threads für's Lesen hab ich auch schon probiert - ohne Erfolg.
Wenn jemand die ominöse Ursache wüßte, wär's ja auch kein Problem, ne Lösung zu finden.

Mag ja sein, daß ein größere Buffer sich positiv auswirken könnte, aber im Moment scheint da noch irgendeine "andere Geschichte" den Einfluß der Buffergröße zu egalisieren.

Aber ich halt mich jetzt solange raus, bis jemand "glaubt", die "wahre" Ursache gefunden zu haben
Zu bedenken gilt dabei nur: "Glaube" ist Auslegungssache

- GMo -

[petgun]

Aber ich halt mich jetzt solange raus, bis jemand "glaubt", die "wahre" Ursache gefunden zu haben
Zu bedenken gilt dabei nur: "Glaube" ist Auslegungssache

ok, was wuerdest Du sagen wenn mein ominoeses (fuer einige sicher grenzwertiges file) testfile.ts nach entfernen/transkodieren (von 256kbps nach 192kbps) der Tonspur ohne Probleme mit dem Movieplayer abgespielt werden koennte? Das Experiment mache ich heute Abend und poste das Diagramm hier.
Aber auch ohne das folgende Experiment koennte man imo eine Aussage wagen...vor allem wenn man die Zusammenhaenge so gut kennt wie Du. Schau Dir bitte das erste Diagramm noch mal an und betrachte die Datenrate bei der es audiomaessig an zu stottern faengt (1)....meilenweit von meiner maximalen Datenrate entfernt...spaeter kommt es zu einem Abbruch (2) mit Standbild trotz weiter laufendem/neu gestartetem Datentransfer mit der maximalen Datenrate...sorry, aber das laesst bei mir nur einen Schluss zu. Aber "..noch irgendeine "andere Geschichte".." hoert sich wenigstens schon mal nach Zweifel an...

[Torsten73]

Hi,
ich glaube das Petgun da nicht ganz falsch liegt. Ich kann da noch folgende Beobachtung draufsetzen:
Nimmt man einen Film mit 2 Audiospuren auf ist man nicht in der Lage eine stabile Wiedergabe mit der 2. Audiospur (i.d.R. Englisch) zu erreichen. Die Wiedergabe ruckelt katastrophal und ist nicht in den Griff zu bekommen. Das habe ich schon in der Anfagszeit des SFU Geschichte festgestellt (damals bei Herr der Ringe auf Premiere 1) und heute ist es immer noch so. Das ist sehr ärgerlich, da ich mir manche Filme sehr gerne im O-Ton mal ansehen würde. Die Wiedergabe mit der deutschen Tonspur funktioniert dagegen einwandfrei!

Bisher hat sich noch keiner gefunden der mir eine Lösung dazu nennen konnte. Ev. Möglich wäre per PX alle Spuren bis auf die O-Ton zu entfernen, was ich aber noch nicht getestet habe (weiß auch nicht wie, sollte aber möglich sein).

[digi_casi]

Code: Alles auswählen

#define PF_BUF_SIZE   (800*188)
#define PF_DMX_SIZE   (PF_BUF_SIZE + PF_BUF_SIZE/2)

das kann aber nicht der ringbuffer sein, oder? das waere ja arg klein.
ich hab im enigma movieplayer:

Code: Alles auswählen

#define BLOCKSIZE 65424*4
#define INITIALBUFFER BLOCKSIZE*10

[Tommy]

Ich hatte mit Enigma noch nie Berührung - wie läuft der Movieplayer da? Gibts ähnlich Probleme? Wenn der perfekt läuft kann man Ihn nach Neutrino portieren? Evtl auch probeweise von der commandline aus - wenns mit der gui nich passt?

Edit:
@petgun: hast Du dein Referenzfile mal unter Enigma getestet? Die stream sollten ja neuerdings passen?!

[digi_casi]

ka, aber eventuell isses einfacher, das dbox driver zeugs einzubauen.
bisher laeuft der nur auf der dreambox.

[Tommy]

Achso - ich dachte auch unter dbox enigma

[petgun]

..abschliessend zu dem Thema noch ein Diagramm dieses Testfiles mit der von orginal 256kbps auf 192kbps transkodierten Audiospur:



wird, wie Ihr alle sehen koennt, problemlos mit dem Movieplayer abgespielt...kein Ruckeln/Tonstoerung..einwandfrei! Ich schliesse daraus, das der Movieplayer erst mal 'nur' ein Syncproblem? mit Audiospuren hat die nicht 192kbps sind/irgendwie asynchron werden/kleine Fehler haben.
Ein vergrosserter Buffer wird bei diesem Fehler natuerlich nicht helfen.

@teddy278
jede Wette das Deine Referenzaufnahme (die mit dem Zug) auch nur durch dieses Audiosync-Problem beim Abspielen aus dem Tritt kommt....mit der Datenrate hat das nix zu tun.

[digi_casi]

dann transcodiert doch den ton einfach auf 192 kbps...
den unterschied hoert doch eh keiner ;-)

[petgun]

dann transcodiert doch den ton einfach auf 192 kbps...
den unterschied hoert doch eh keiner ;-)

jau das ist der ultimative Wuergaround.....bis der Fehler gefixt wird ;-)

[digi_casi]

wenn das der fehler ist, dann ist der aber in den drivern...
denn der movieplayer reicht ja nur den stream an die driver weiter...

[petgun]

wenn das der fehler ist, dann ist der aber in den drivern...
denn der movieplayer reicht ja nur den stream an die driver weiter...

..Du meinst die Treiber die fuer den Clipmode verantwortlich sind?

[digi_casi]

jo, denke schon.
der vlc auf dem pc transcoded die files in einen dvb transport stream, schickt den zur box... der movieplayer empfaengt den und gibt den an den treiber zur anzeige.
der movieplayer veraendert den stream nicht.
also entweder ist der fehler beim transcoden im vlc oder in den treibern auf der box.

[petgun]

also entweder ist der fehler beim transcoden im vlc oder in den treibern auf der box.

..vlc ist nicht im Spiel bei ts direkt.

[digi_casi]

also entweder ist der fehler beim transcoden im vlc oder in den treibern auf der box.

..vlc ist nicht im Spiel bei ts direkt.

ach so... jo, dann bleiben nur die treiber, wenns nicht mit der bandbreite zusammenhaengt.

[petgun]

..dann bleiben nur die treiber...

...und Hilfe dazu gibt's nur bei Obi, oder?
Ich will das noch nicht ganz glauben das es am Treiber liegt....gibt es eine Moeglichkeit diesen Clipmode mit den Treibern ohne Movieplayer zu testen?...da war doch was..?

[digi_casi]

yep, so siehts aus

[petgun]

yep, so siehts aus

...gibt es unter Enigma eigentlich auch diese Ruckel Probleme? Ihr benutzt doch auch diese Treiber, oder?

[digi_casi]

ne, da gibts andere treiber...
ka, ich verwende den movieplayer nur zum abspielen von selbst aufgenommenen dvds... und da gibts keine ruckler

[digi_casi]

aber ich transcodiere audio auch immer auf 192

[teddy278]

Hallo.

Code: Alles auswählen

#define PF_BUF_SIZE   (800*188)
#define PF_DMX_SIZE   (PF_BUF_SIZE + PF_BUF_SIZE/2)

damit kannst du's ausrechnen ...
Natürlich hab ich auch andere Werte wie oben probiert, aber bei größeren Werten hat sich am Ruckeln nix geändert.

Das wundert mich gar nicht, schließlich geben diese Werte doch nur die Häppchengröße an, die am Stück gelesen wird. Wenn du den Wert vergrößerst, hast Du zwar hinten mehr Luft beim write(), dafür wird's vorne eng, weil das read () länger dauert. Mit größeren Werten hier wird es meiner Ansicht nach eher schlechter als besser.

Wäre nicht weiter schlimm, wenn folgende entscheidende Frage beantwortet wäre:
Wieviel Platz wird im Treiber "verputzt" bis "Platz vorhanden" gemeldet wird, also der write()-Aufruf zurückkehrt ?
Etwa der ganze Puffer ??? (das wäre dann ein Ruckelgrund).

Es würde ja schon "reichen", wenn write() zwar sofort zurückkehrt wenn wieder etwas Platz ist ...

... und wer weiß das ?
meine jetzt, bei wieviel Platz das write() zurückkommt, wenn's geblocked ist -> das ist Treibersache !!!
Diese Frage müßte erst beantwortet werden (wär doch schon mal ne Forschungsaufgage für nen gestanden Theoretiker).

Wenn man die beiden Prozesse voneinander abkoppelt, ist's egal, wie groß der Speicher ist. Jetzt sieht es so aus, daß erst gelesen werden kann, wenn das Schreiben beendet ist... Ziel sollte es sein, daß unabhängig davon gelesen wird, ob der kleine dvrBuf schon voll ist oder nicht. Maßgeblich sollte der (großzügige) Ringbuffer sein.

Extra threads für's Lesen hab ich auch schon probiert - ohne Erfolg.

Mit oder ohne "echten" Ringbuffer? Wenn die beiden Threads nur abwechselnd immer wieder exakt denselben Speicherbereich am Stück vollschreiben und leerräumen, nützt Multithreading auch wenig, weil beide abwechsend auf dieselbe Ressoruce zugreifen müssen -> des hamma jetz au scho.

Mag ja sein, daß ein größere Buffer sich positiv auswirken könnte, aber im Moment scheint da noch irgendeine "andere Geschichte" den Einfluß der Buffergröße zu egalisieren.

Aber ich halt mich jetzt solange raus, bis jemand "glaubt", die "wahre" Ursache gefunden zu haben
Zu bedenken gilt dabei nur: "Glaube" ist Auslegungssache

Glauben wir nicht alle, die wahre Ursache zu kennen? Ist ja nicht ausgeschlossen, daß es mehrere Probleme auf einmal gibt, die sich vielleicht gegenseitig noch beeinflussen. Wobei ein Ringbuffer doch eigentlich keines der möglichen Problem verschlechtern sollte, oder?

@teddy278
jede Wette das Deine Referenzaufnahme (die mit dem Zug) auch nur durch dieses Audiosync-Problem beim Abspielen aus dem Tritt kommt....mit der Datenrate hat das nix zu tun.

Aber warum sollte das Audiosync-Problem mit der Datenrate zusammenhängen? Meine Probleme traten bisher stets an den Stellen auf, an denen ProjectX mir eine hohe Bitrate signalisierte. Und die Störungen waren meist nicht am Ton bemerkbar, sondern an Standbildern und anschließender fehlerhafter Synchronisation. Der Ton stockt danach (hoffentlich), wenn's wieder synchron läuft.

Und das Stocken bei schnellen Bewegungen habe ich sehr oft, auch bei Langweiler-Kanälen wie Premiere Film. Einzig sat1 war kürzlich mal völlig fehlerfrei, allerdings war die .ts nach einer Stunde auch genauso groß wie eine halbe Stunde .ts von Eisenbahn Romantik.

Versteh mich nicht falsch, ich kann mir gut vorstellen, daß irgendwelche Audiospuren zu Problemen führen... Aber das ist nicht meine Baustelle. Mir ging es erstmal darum, ein Problem anzugehen, nämlich das des zu geringen Buffers. Verzetteln bringt nichts.

wenn das der fehler ist, dann ist der aber in den drivern...
denn der movieplayer reicht ja nur den stream an die driver weiter...

Und das ist der Knackpunkt: Der Movieplayer macht beim Abspielen nichts besonderes, er schiebt nur Daten durch die Gegend. Und das könnte man optimieren.

Wobei sich das Thema für mich wohl eigentlich eh erledigt hat. "Du Schatz, der neue Receiver kann zwei Programme gleichzeitig aufnehmen und wir können ein drittes gucken." - "Echt? Du hast doch die dbox eh nie gemocht." Hach, Frauen.


Bye,
Christian

[petgun]

aber ich transcodiere audio auch immer auf 192

also keine Ruckler, was dann meine Theorie mit Deinem ultimativen Wuegaround bestaetigt ;-) Ich glaube Deinem Urteil mit der alleinigen? Treiber-Verantwortung fuer dieses Probem, hoffe aber trotzdem weitere kompetente Meinungen dazu zu hoeren.