Größerer Buffer beim Movieplayer

[petgun]

...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.

[Spooky]

@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

[rolano]

..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.

Yeppp - dat stimmt!
@paule
...wie verhält sich Dein "RAM-Schnipsel" wenn Du ihn über das Netzwerk spielst??? Sollte ja kein Problem machen, wenn petguns Annahme stimmt.

[Tommy]

@petgun:

ist es Dir evtl möglich einen grenzwertigen stream aufzunehmen der von vornherein <=20MB ist? Dann könnten:

a) wir ausschließen das irgendwelche Tools den stream verändern
b) die user mit Speichererweiterung vergleichstests aus dem RAM machen.

Du könntest evtl. die Splitsize auf 20MB einstellen und eine Deine "berühmt berüchtigten" Sender/Sendungen mitschneiden. Ist zwar Schnipselei aber könnte gehen oder? Dann hätten wir zumindest ein "echtes" Referenzfile.

[rolano]

@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. (...)

Hi,
ich bewege mich hier als dummer Enduser zwischen Leuten mit deutlich mehr Fundamentalwissen: Trotzem meine bescheidene Meinung, so wie sie sich mir derzeit darstellt:
Du hast sicher Recht, dass blinkende LED es kein idealer Beweis (wenn es denn überhaupt ein Beweis ist); aber es ist zumindest mal eine THEORIE/ein Anhaltspunkt - genauso wie gmo18 selbst auch nur von einer THEORIE und nicht von einer Lösung spricht.

Da die ursprüngliche Diskussion ja im Sande verlaufen ist, halte ich es zumindest für schön, dass es eine neue THEORIE gibt.......sollte sie sich als falsch herausstellen.....dann halte ich es mit Sherlock Holmes "Wenn man alles Unmögliche ausschließt, ist das was übrig bleibt zwangsläufig die Wahrheit" (zugegeben ein eher freies Zitat). Und: wenn diese Wahrheit lautet: Besser als der MP derzeit ist geht es beim besten Willen nicht, dann solls zumindest mir Recht sein.

.....einfach den Schwanz einziehen und sich jetzt schon mit dem Status Quo zufrieden geben....nöööö das würde bedeuten:

"Der Klügere gibt nach - Eine traurige Wahrheit: sie begründet die Weltherrschaft der Dummen." (Marie von Ebner-Eschenbach)

In Anbetracht der Empfindlichkeiten die hier hin und wieder auftauchen, zu diesem Zitat gleich die Klarstellung: DAS soll eine grundsätzliche Feststellung und keine Anspielung auf irgendeine bestimmte Person/Personengruppe sein.

Gruß
rolano

[petgun]

..ist es Dir evtl möglich einen grenzwertigen stream aufzunehmen der von vornherein <=20MB ist? Dann könnten:...

...ich kann keine hohe Datenrate >8,5 Mbps vorhersagen...iss aber auch nicht notwendig. Wenn man geeignete Tools nimmt, kann sich jeder selbst so ein File erzeugen und der Schnipsel von FaselMan (mein remuxter Schnipsel ;-)) iss doch zumindest am Anfang hochratig genug...viel mehr kommt da imo nicht...der Schnipsel hat 45MB und sollte imo bei den Leuten mit 64MB noch ins Ram passen..oder?

@Spooky
...wenn wir von einem _funktionierenden_ Ringbuffer reden der quasi immer voll ist, die Fuell-Entleerungs-Pakete sehr klein sind und die Abtastrate fuer das Netzwerkdiagramm viel zu niedrig ist, wuerden die Beobachtungen von Paule auch noch passen....und der Movieplayer-Code koennte wieder heilig gesprochen werden...wenn das beobachtete Ende anders waere. Der Film muesste um den Inhalt des Buffers nachlaufen _ohne_ Netzwerktransfer...macht er aber nicht.

<edit>
Schlussfolgerung zum beobachteten Ende hinzugefuegt
</edit>

[Tommy]

Schnipsel hat 45MB und sollte imo bei den Leuten mit 64MB noch ins Ram passen..oder?

wird knapp - aber man kann ja den sectionsd ausschalten

Ich wollte ja nur ausschließen das irgendwelche Schnitttools den stream "verwomblen" Da Du Dein LAN bis zur Extase optimiert hast, kannst Du IMHO von uns allen die "fettesten" streams aufnehmen.

[Spooky]

@petun & rolano


um Himmels willen, ich hatte/habe nicht vor den Movieplayer heilig zu sprechen. Veränderung und Optimierungen sind mir immer recht, auch wenn sich später rausstellen sollte, dass es Querschläger gibt oder gar nichts gebracht hat.

Ich versuche sowas von mehreren Standpunkten zu sehen und nach verschiedenen Ursachen zu forschen. Es ist natürlich erstmal auch nur Theorie, bis man es probiert hat. Entweder es klappt oder geht schief. Wenn es schief geht, heist das noch nicht einmal , dass die Theorie falsch war. Vielleicht war sie einfach nur nicht fertig/vollständig/umfangreich genug.

Was ich gemacht habe, die oben genannte Beweisführung in Frage gestellt. Und nicht weil ich sie von vornherein ablehne, sondern weil mir Situationen bekannt sind, in denen die Symptome die gleichen sind, aber die Ursache eine andere sein kann - nicht muß !

Ohne den Programmcode vom Movieplayer zu kennen bzw. zu verstehen,jetzt mal eine Theorie. Sie kann durchaus völliger Blödsinn sein:
Ist Euch schon aufgefallen, dass beim Abspielen mit dem Movieplayer das Ende des TS-Files nie ganz erreicht wird. Wenn man es am PC anschaut sieht man meist noch einen Hauch mehr.

a.) Vielleicht ist es der Rest im Buffer, welcher zwar noch gefüllt wurde (siehe PauleFouls gleichzeitiges erlöschen der LED's) aber nicht mehr abgespielt wird, warum auch immer (Buffer wird nicht mehr weiter gefüttert = Wiedergabe STOP, NFS meldet "Datei fertig übertragen" bevor der Buffer leergeschrieben wurde = Wiedergabe STOP o.ä.). Bis jetzt habe ich nirgends gefunden, wie groß der derzeitige Buffer ist, für wieviele sec o. ms. er in etwa puffern kann und ob es damit genau dem entsprechen kann was am Ende noch fehlt.

b.) Der Movieplayer blendet einfach zu zeitig aus

Ich sehe jedenfalls der Theorie/dem Vorschlag von gmo18t positiv entgegen.

Spooky
Edit:
kosmetische Korrekturen zum besseren Verständnis
Edit:

[petb]

So ganz versteh ich die Euphorie nicht.
Das Verhalten war doch die ganze Zeit über klar.
Ich glaube gagga sagte mal der MP hätte einen Puffer.
Beim Start lief es immer eine kurze Zeit glatt.
Wenn es anfing zu ruckeln machte man einen resync und es ging wieder eine kurze Zeit glatt.

Also vermuteten wir ein größere Puffer würde was bringen.
Ob der Puffer jetzt eventuell zu klein ist oder nicht so funktioniert wie er sollte, ist ja aus Sicht des Endusers nicht wichtig.
Jemand der den Source lesen kann und sich an die Arbeit gemacht hätte, wäre da mit Sicherheit drüber gestolpert.
Leider sind die meisten hier, als auch ich, nicht in der Lage den Source so zu lesen und zu verstehen.
Aber das Verhalten grundsätzlich hat ja auch schon petgun in seinen Netz-Performance Bildern dargestellt.

Also war gedanklich/vermutlich der Puffer die ganze Zeit unser Ziel.
Und das wir nun denken das der Puffer nicht sauber läuft ist ja wieder nur eine Vermutung.

Ich freue mich aber das es jetzt ein wenig kanalisiert weiter geht.
Was ich die letzten Tage an Test es mit Netzwerkkarten und Protokollen usw. angestellt habe.
WAF ist fast im Keller gelandet..."Nee Schatz, jetzt nicht mit dieser Box kucken, da musste die andere nehmen." " Ach geh doch bitte ins Schlafzimmer, ich nehme hier grad was auf und schaus mir mit der anderen an, aber nimm nicht die Nokia im Schlafzimmer, weil da ist der Server über CIFS gemountet.... Was fürn fisdfg ?.... Sambaaa....Ich schmeis die Boxen bald aus dem Fenster" usw.

Nur kurz Timeshift geht relativ gut, bei nicht hochratigen Aufnahmen wenn CIFS, tcp und eigene karte im Server zugrunde liegt
Alles andere muckt immer ein wenig.
Und bei einer Konstellation hat er das Fileende sogar nachgeführt.
Bye
PetB

[petgun]

Und das wir nun denken das der Puffer nicht sauber läuft ist ja wieder nur eine Vermutung.

..die sich imo Dank der Beobachtungen von PauleFoul nicht mehr wiederlegen laesst...was dazu gefuehrt hat, dass gmo18t/???? sich den ganzen Sapsch noch mal anschaut und den _Fehler_ beseitigt oder einen anderen Weg geht (Wabbel-Queue).

--
Um klar zu sehen, genügt oft schon ein Wechsel der Blickrichtung.
[Antoine de Saint-Exupéry]

[Spooky]

Offtopic:
@Petb,
was Dein Timeshifting betrifft, hast Du schonmal "streamer" von gmo18t ausprobiert. Immerhin hat er das genau für so einen Einsatzweck entwickelt. Durch TCP kann es zwar bei extremen Datenraten zu Rucklern kommen, aber besser funktionieren als CIFS sollte es allemal.
Offtopic:

[petb]

Und das wir nun denken das der Puffer nicht sauber läuft ist ja wieder nur eine Vermutung.

..die sich imo nicht mehr wiederlegen laesst...was dazu gefuehrt hat, dass gmo18t/???? sich den ganzen Sapsch noch mal anschaut und den _Fehler_ beseitigt oder einen anderen Weg geht (Wabbel-Queue).

Ja, ich sag ja, ich freue mich das es jetzt kanalisiert weiter geht und das Testen und suchen nach Fehlerquellen bzw. Ideen wieder etwas zurückgeschraubt werden kann.

Vieleicht kann sich ja gagga noch erinnern wie er damals den Puffer angelegt (Programmiert) hat.
Vieleicht sollte der ja nur dafür sorgen das das File sauber anfängt zu laufen.
Vieleicht war der Puffer ja nie gedacht als Dauerpuffer ?

Ich freu mich auf die Arbeit/das Ergebnis von gmo18t (hoffentlich bekommt er es in Griff)
@spooky
Danke, hab ich bisher nicht, weil ich nicht genau wusste ob:
ich ein anderes als das JTG Image brauche und ob es auch mit 6 Boxen gleichzeitig, auf dem linux server läuft, es damit klarkommt wenn eine aufnahme sofort hitereinander kommt, also Ende 20:15, Start 20:15. ??
Bye
PetB

[Spooky]

@Petb

"streamer" ist "nur" die Abspielvariante. Das letzte fertige Image was ich kenne und ein gepatchtes Neutrino für "streamer" mitgeliefert hat, ist Yadi 2.1.0.7. Durch die Integrierung vom Moviebrowser ist "streamer" bei den neueren Images Yadi 2.1.0.10, JtG und co. auf der Strecke geblieben. Wie weit die Anpassung an den Moviebrowser durch gmo18t o. Günther dahingehend fortgeschritten ist, weiß ich leider nicht.
Zum Aufnehmen kannst Du trotzdem NFS verwenden o. nimmst "recorder" von gmo18t.

Spooky

[petgun]

Hi,
<OT>

..ob es auch mit 6 Boxen gleichzeitig, auf dem linux server läuft..

..hast Du die Boxen eigentlich bei Deinen Experimenten mit Switch(es) in verschiedenen Netzwerksegmenten...von wegen collision domain?
</OT>

[petb]

Hi,
<OT>

..ob es auch mit 6 Boxen gleichzeitig, auf dem linux server läuft..

..hast Du die Boxen eigentlich bei Deinen Experimenten mit Switch(es) in verschiedenen Netzwerksegmenten...von wegen collision domain?
</OT>

Beides.
Bis vor wenigen Tagen habe ich 6 Boxen am Switch, gegen einen Nic im Server, alle in einem Subnetz gehabt.
Für die Abspieltests/Timeshifttests habe ich jetzt eine Box direkt an einen eigenen Nic im Server laufen.
ABER auch mit den 6 (plus eine Spiel/Testbox) klappt bis auf Timeshift und das mehrfache Abspielen einer hochratigen Aufnahme alles.
Also so Sachen wie 4 x aufnehmen und 2 x Abspielen geht
6 x Aufnehmen oder auch 6 x abspielen geht auch.
Nur bei hochratigen Sachen gibts beim Abspielen Ruckler.
Daher will ich die 2 Boxen auf denen ich fast nur abspiele gegen Nic Nr.1
und die anderen 4 gegen Nic Nr 2 laufen lassen.

Oder was hast du gemeint ?

Was ich übrigens festgestellt habe, ist das sehr viele Switche Probleme mit udp haben.
Es klappt z.B. wenn ich tcp nehme aber geht nicht mehr mit den Boxen wenn ich udp wähle.
Bye
PetB

[petgun]

ABER auch mit den 6 (plus eine Spiel/Testbox) klappt bis auf Timeshift und das mehrfache Abspielen einer hochratigen Aufnahme alles. Also so Sachen wie 4 x aufnehmen und 2 x Abspielen geht
6 x Aufnehmen oder auch 6 x abspielen geht auch.

..von so einer Performance koennen die meisten mit mehreren Boxen doch nur von traeumen. Ich habe (leider?) nur eine Box und selbst das zu optimieren hat eine Weile gedauert...perfekt iss es imo immer noch nicht...und wird's auch nie werden koennen bei dem 10 Mbps HDX Interface der Dbox.

[petb]

ABER auch mit den 6 (plus eine Spiel/Testbox) klappt bis auf Timeshift und das mehrfache Abspielen einer hochratigen Aufnahme alles. Also so Sachen wie 4 x aufnehmen und 2 x Abspielen geht
6 x Aufnehmen oder auch 6 x abspielen geht auch.

..von so einer Performance koennen die meisten mit mehreren Boxen doch nur von traeumen. Ich habe (leider?) nur eine Box und selbst das zu optimieren hat eine Weile gedauert...perfekt iss es imo immer noch nicht...und wird's auch nie werden koennen bei dem 10 Mbps HDX Interface der Dbox.

Es hat auch eine Menge Zeit gekostet (Gut 2-3 Monate) bis alles so lief.
Irgendwo hab ich hier im Forum auch mal geschrieben was ich alles in welcher Konstellation probiert habe, Kernelwechsel, Switchwechsel, Nic Wechsel und und dund.
Wenn ich den Server und die verschiedenen Switche nicht gehabt hätte, wäre ich auch nicht so weit gekommen.
Das wäre alles viel zu teuer gewesen, um es extra für die DBoxen anzuschaffen.
So habe ich nur umkonfigurieren und umstecken müssen und zum Raid5 verbund von dem ich einen Teil nutze noch 2 Platten als Einzeldrives zusätzlich in den Server gesteckt.

Die einzigen Probleme die ich jetzt noch habe sind:
Auf den 4 Rec Boxen laufen noch JTG Images Stand Oktober 05, allerdings jetzt mit einem timerd von Chaka_Zulu (dafür nochmal danke, denn seit mehr als 10 Tagen keine kaputte timerd.conf mehr).
Denn wenn ich das alles mit aktuellen Images mache klappt es nicht.
Wenn ich auf den 2 Play Boxen Aufnahmen programmiere passiert es immer wieder mal das diese nicht sauber aufnehmen, warum auch immer.
Sie wachen auf, legen los und brechen dann ab.
manchmal steht die Box dann, manchmal geht sie aus, die witzigsten Dinge passieren da.
Selbstverständlich habe ich die auch mal hin und her getauscht mit den Rec Boxen und eben umgeflasht.
Ergebnis ist immer das gleiche.
Ab und zu spinnen die wenn ein aktuelles Image drauf ist.
Wobei sich das jetzt auf das JTG vom 26.12.05 bezieht.
Kann sein das es in Januar Images, Yadi oder ähnlich schon nicht mehr so ist.
Habe erst seit wenigen Tagen den Snap JTG vom 18.2.06 drauf und kann daher noch nichts dazu sagen.
Aber wenn Chaka_Zulu es timerd bei den alten images weiter so stabil läuft, sehe ich da auch keine Notwendigkeit auf ein neures Image zu wechseln.
Es sei denn der EPG wäre vor den Aufnahmen besser verfügbar oder er liese sich bereits bei der Timerprogrammierung in der timerd.conf speichern, wie du auch in dem anderen Beitrag gelesen hast.
Sonst bin ich sehr zufrieden mit der Lösung.
Ich bräuchte ja sonst mind. 3 Twin PVR es und könnte nicht alles aufgenommene ohne Probleme sofort nach der Aufnahmen in einem der drei Zimmer anschauen (Esszimmer ausgenommen, da nehmen manchmal halt beide Boxen gleichzeitig auf)
Bye
PetB

[wolgade]

Wir verzetteln uns hier. Ich bin nach wie vor dafür, daß ein eigener Thread aufgemacht wird, in dem das Phänomen, das PauleFoul beobachtet hat, beschrieben wird. Diesen Monsterthread liest kein Dev.
@Spooky:

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.

Das ist nicht der Punkt. Beim Start der Wiedergabe wird der Puffer erst gefüllt. Das ist gut so. Dann beginnt die Wiedergabe ohne daß Netzwerktransfer stattfindet. Dabei wird der Puffer zwangsläufig leer, zumindest leerer. Diese Sendepause im Netz liegt in der Größenordnung von einer Sekunde. Bei einer Datenrate von 8 Mbit/s wäre das 1 Mbyte. Natürlich ist nicht bewiesen, daß der Puffer tatsächlich komplett leerläuft und anschließend nicht mehr benutzt wird. Ich bin mir aber sicher, daß Gagga das Netzwerk nicht absichtlich für eine Sekunde pennen geschickt hat, während doch zeitkritische Videodaten übertragen werden sollen.

@petb:

Ich glaube gagga sagte mal der MP hätte einen Puffer. [..] Also vermuteten wir ein größere Puffer würde was bringen.

Und er sagte, daß ein größerer Puffer bei seinen Versuchen nichts gebracht hat. Wenn durch einen Bug dieser Puffer gar nicht benutzt wird, dann nützt es natürlich nichts, wenn man ihn größer macht. Gaggas Aussagen stützen im Nachhinein die Theorie, daß mit dem Puffer etwas nicht stimmt.

Ob der Puffer jetzt eventuell zu klein ist oder nicht so funktioniert wie er sollte, ist ja aus Sicht des Endusers nicht wichtig.

Aus wessen Sicht wäre es denn dann wichtig, ob der Puffer funktioniert. Wenn er gar nicht wichtig ist, dann kann man ihn auch weglassen.

Jemand der den Source lesen kann und sich an die Arbeit gemacht hätte, wäre da mit Sicherheit drüber gestolpert.

Hast du schon mal programmiert? Du überlegst dir was, codest das und dann funktioniert es nicht. Jetzt guckst du in den Code und suchst den Fehler oder überlegst wo dein Denkfehler ist. Eigentlich warst du sicher, alles richtig gemacht zu haben. Irgendwann merkst du, wo du den Bock geschossen hast.
Dieser Prozeß setzt aber nur ein, wenn etwas nicht funktioniert. Wenn man meint, daß alles so läuft wie es soll, sucht man keine Fehler. Das machen auch andere, die sich den Code angucken, nicht. Niemand sucht einen Bug, wenn er der Ansicht ist, daß alles läuft.

Vieleicht kann sich ja gagga noch erinnern wie er damals den Puffer angelegt (Programmiert) hat.
Vieleicht sollte der ja nur dafür sorgen das das File sauber anfängt zu laufen.
Vieleicht war der Puffer ja nie gedacht als Dauerpuffer ?

Erstens hat Gagga bereits gesagt, daß der MP einen Puffer hat, nämlich als man ihm vorschlug, einen einzubauen. Zweitens ist ein Puffer nur für den Dateianfang ziemlich sinnfrei.

Mir kommt noch ein anderer Gedanke: Vor einiger Zeit hat jemand geschrieben, daß ein großer Puffer für den MP den Nachteil hätte, daß nach dem Springen in der Datei dieser Puffer erst wieder gefüllt werden müßte, bevor die Wiedergabe weitergeht. Dadurch würde die Wiedergabepause beim Springen größer. Jetzt erst ist mir aufgefallen, daß ich absolut gar keine Wiedergabepause beim Springen in der Datei habe. Müßte ich doch. Pufferinhalt ist doch ungültig und muß neu aufgefüllt werden wie beim Wiedergabestart, wo es auch eine Verzögerung gibt.

Ich bleib dabei: Mit dem Puffer des MP stimmt was nicht.

[petgun]

Ich bleib dabei: Mit dem Puffer des MP stimmt was nicht.

ja, wird ja jetzt selbst von den Machern nicht mehr abgestritten und hier in diesem Thread Alternativen in Erwaegung gezogen. Warum sollte man jetzt noch einen neuen Fred aufmachen...was gibt es da noch zu diskutieren? Wir koennen die Beobachtungen von PauleFoul nur noch zerreden...es kann imo nur diese eine Schlussfolgerung geben: das Bufferhandling ist fehlerhaft...was als _Vermutung_ schon auf der ersten Seite dieses Threads steht...aber erst jetzt gibt es imo _keine_ Argumente mehr die gegen diese Vermutung sprechen.

[gmo18t]

...was dazu gefuehrt hat, dass gmo18t/???? sich den ganzen Sapsch noch mal anschaut und den _Fehler_ beseitigt oder einen anderen Weg geht (Wabbel-Queue).

das war zwar nicht der Anlass, sondern der Umstand, daß ich bisher nicht erkennen konnte (oder nicht wußte wie), ob der demux-buffer leerläuft !
Denn wenn man das erkennen kann, ist es möglich, den stream automatisch zu pausieren, so als wenn man "gelb" drücken würde.
Und sobald der Queue-Level dann wieder akzeptabel ist, geht's auch automatisch weiter ...
Das ist mal der Hauptvorteil, den ich mir erhoffe...
Deshalb würde ich auch nicht von Fehler reden, aber das macht nix ...
Viel schlimmer ist die fälschliche Bezeichnung meiner "(c) wabber-queue" als "wabbel-queue"

Aber weil grad Fasching ist, hab ich mein Konzept mal schnell zusammengeproggt und eine 1. Testversion vom neutrino-binary erstellt.

Näheres dazu in einem neuen Thread in der Rubrik "neutrino", den ich jetzt verfassen werde.

- GMo -

[petgun]

Fasching kann anscheinend sehr inspirierend sein
Danke und sorry fuer die 'wabbel-queue' ;-)

[digi_casi]

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.

[petgun]

..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.

..kannst Du den bug als Code-Versteher erkennen und evtl. fixen? Dann braeuchte man keine '©wabber-queue'.
'©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?
Ich freue mich jedenfalls auf eine _funktionierende_ ©wabber-queue.

--
Besser einen Spatz in der Hand als eine Taube auf dem Dach.
[Deutsches Sprichwort]

[petb]

Ich bleib dabei: Mit dem Puffer des MP stimmt was nicht.

Im Prinzip sind wir einer Meinung, zumindest vom Sinn her.
Ich glaube auch das da was nicht stimmt.

Bye
PetB

[gmo18t]

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 -