Größerer Buffer beim Movieplayer
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Größerer Buffer beim Movieplayer
Hallo allerseits,
in irgendeinem Thread hatte ich das Thema schonmal erblickt, aber da ich es auf die Schnelle nicht wiederfinde, wollte ich es auf diesem Wege nochmal aufwärmen. Es geht um den Movieplayer, genau genommen um die direkte Wiedergabe von .TS-Dateien von einem Netzlaufwerk.
Wäre es vielleicht möglich, im Movieplayer einen größeren Buffer zu implementieren als den jetzigen?
Bei der Aufnahme wurde ja nach ausgiebiger Diskussion eine Möglichkeit geschaffen, den Ringbuffer zu vergrößern. Das hat - zumindest bei mir - einige Probleme gelöst. Leider fehlt mir diese Möglichkeit etwas bei der Wiedergabe...
Mein NAS ist noch etwas schwach auf der Brust, und so habe ich mit sporadischen Hängern zu kämpfen, die oft zu Synchronisationsproblemen führen. Da es meistens nur 1-2 Aussetzer pro Stunde sind kann ich mir gut vorstellen, daß in den Szenen vorher ausreichend Bandbreite vorhanden ist, um einen großzügig bemessenen Speicher zu füllen.
Richtig anwenderfreundlich wäre es, wenn man nichts einstellen müßte, sondern der Player einfach alles an sich reißt, was frei ist - abzüglich einer Sicherheitsreserve. Er müßte sich "zurückziehen", wenn andere Prozesse diese Reserve angreifen. Ich weiß nicht, inwieweit sich so ein dynamischer Buffer in der Tuxbox realisieren läßt. Ansonsten wäre eine Einstellmöglichkeit wie bei der Aufnahme auch schon sehr hilfreich. Bis zum IDE-Interface wird es ja noch ein wenig dauern, fürchte ich.
Ich würde ja auch selbst dran drehen, aber meine Programmierkenntnisse beschränken sich auf Hard- und Software, die noch etwas älter ist als die d-box.
Bye,
Christian
in irgendeinem Thread hatte ich das Thema schonmal erblickt, aber da ich es auf die Schnelle nicht wiederfinde, wollte ich es auf diesem Wege nochmal aufwärmen. Es geht um den Movieplayer, genau genommen um die direkte Wiedergabe von .TS-Dateien von einem Netzlaufwerk.
Wäre es vielleicht möglich, im Movieplayer einen größeren Buffer zu implementieren als den jetzigen?
Bei der Aufnahme wurde ja nach ausgiebiger Diskussion eine Möglichkeit geschaffen, den Ringbuffer zu vergrößern. Das hat - zumindest bei mir - einige Probleme gelöst. Leider fehlt mir diese Möglichkeit etwas bei der Wiedergabe...
Mein NAS ist noch etwas schwach auf der Brust, und so habe ich mit sporadischen Hängern zu kämpfen, die oft zu Synchronisationsproblemen führen. Da es meistens nur 1-2 Aussetzer pro Stunde sind kann ich mir gut vorstellen, daß in den Szenen vorher ausreichend Bandbreite vorhanden ist, um einen großzügig bemessenen Speicher zu füllen.
Richtig anwenderfreundlich wäre es, wenn man nichts einstellen müßte, sondern der Player einfach alles an sich reißt, was frei ist - abzüglich einer Sicherheitsreserve. Er müßte sich "zurückziehen", wenn andere Prozesse diese Reserve angreifen. Ich weiß nicht, inwieweit sich so ein dynamischer Buffer in der Tuxbox realisieren läßt. Ansonsten wäre eine Einstellmöglichkeit wie bei der Aufnahme auch schon sehr hilfreich. Bis zum IDE-Interface wird es ja noch ein wenig dauern, fürchte ich.
Ich würde ja auch selbst dran drehen, aber meine Programmierkenntnisse beschränken sich auf Hard- und Software, die noch etwas älter ist als die d-box.
Bye,
Christian
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
Hier ging es schon mal kurz um den Puffer.
http://forum.tuxbox-cvs.sourceforge.net ... 442#287442
Da hat sich auch der Dev der den Player gemacht hat gemeldet.
Ich würde es gerne getestet wissen, bzw. würde ich gerne wissen ob es jemand für möglich hält an der Performance des Movieplayers was zu machen.
Bye
PetB
http://forum.tuxbox-cvs.sourceforge.net ... 442#287442
Da hat sich auch der Dev der den Player gemacht hat gemeldet.
Ich würde es gerne getestet wissen, bzw. würde ich gerne wissen ob es jemand für möglich hält an der Performance des Movieplayers was zu machen.
Bye
PetB
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
...es ist so wie digi_casi schreibt. Bei relativ kurzen Spitzen hilft ein groessere Buffer natuerlich...aber viel duerft Ihr davon nicht erwarten. Von vielleicht jetzt 1MByte auf 8MByte erhoehen hoert sich viel an..bringt in der Praxis vermutlich aber nicht allzu viel....ein Versuch ist es natuerlich Wert.
Ich habe hier ein 'Testfile' (fehlerfreie Aufnahme von 3Sat) an dem ich mir die Zaehne ausbeisse...da gibt es 20-30 Sekunden lange Plateaus mit ueber 8Mbps....imo Mission Impossible und grenzwertig fuer das 10Mbps HDX Nadeloehr der Dbox...soviel Ram als vergroesserter Buffer der dafuer notwaendig waere, steht in der Dbox einfach nicht zur Verfuegung...
Aber der Movieplayer hat imo sehr grosse Probleme nach Retransmits/Buffer underrun/???? wieder vernuenftig abzuspielen...wenn der einmal richtig aus dem Tritt ist, gibt das meist keinen mehr bzw. dauert zu lang bis alles wieder in Ordnung ist. Ich schicke dem Movieplayer-Entwickler sehr gerne mal einen Streamschnipsel von vieleicht 1 min Laenge (ca 45 MB) mit dem er diesen Effekt testen/ueberpruefen kann um evt. das Bufferhandling/resync nach underrun mal zu ueberpruefen....das ist imo nicht in Ordnung....das koennte man vielleicht aendern/fixen damit es nach einem underrun schneller 'normal' weitergeht.
Ich habe hier ein 'Testfile' (fehlerfreie Aufnahme von 3Sat) an dem ich mir die Zaehne ausbeisse...da gibt es 20-30 Sekunden lange Plateaus mit ueber 8Mbps....imo Mission Impossible und grenzwertig fuer das 10Mbps HDX Nadeloehr der Dbox...soviel Ram als vergroesserter Buffer der dafuer notwaendig waere, steht in der Dbox einfach nicht zur Verfuegung...
Aber der Movieplayer hat imo sehr grosse Probleme nach Retransmits/Buffer underrun/???? wieder vernuenftig abzuspielen...wenn der einmal richtig aus dem Tritt ist, gibt das meist keinen mehr bzw. dauert zu lang bis alles wieder in Ordnung ist. Ich schicke dem Movieplayer-Entwickler sehr gerne mal einen Streamschnipsel von vieleicht 1 min Laenge (ca 45 MB) mit dem er diesen Effekt testen/ueberpruefen kann um evt. das Bufferhandling/resync nach underrun mal zu ueberpruefen....das ist imo nicht in Ordnung....das koennte man vielleicht aendern/fixen damit es nach einem underrun schneller 'normal' weitergeht.
Zuletzt geändert von petgun am Sonntag 12. Februar 2006, 20:54, insgesamt 1-mal geändert.
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
Vieleicht kannst du mir den schnipsel auch mal schicken ?
Dann würde ich bei mir auch mal gerne schauen ob er geht oder nicht.
Wobei email tut da nicht, glaub 20mb sind da als max eingestellt.
Bye
PetB
Dann würde ich bei mir auch mal gerne schauen ob er geht oder nicht.
Wobei email tut da nicht, glaub 20mb sind da als max eingestellt.
Bye
PetB
1 x DBOX2 Phillips, 1 x DBOX2 Nokia, 1 x DBOX2 Sagem, 100er Gibertini (Astra / Hotbird), NFS Server
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..vielleicht hat ja einer Web/FTP-Space wo ich den Schnipsel uploaden kann?
PS:..vielleicht waere es sogar besser nur fuer das abspielen mit dem Movieplayer _keinen_ Buffer zu verwenden....wenn das 'resyncen' perfekt funktionieren wuerde....mit den kurzen Aussetzern kann man vielleicht besser leben...
PS:..vielleicht waere es sogar besser nur fuer das abspielen mit dem Movieplayer _keinen_ Buffer zu verwenden....wenn das 'resyncen' perfekt funktionieren wuerde....mit den kurzen Aussetzern kann man vielleicht besser leben...
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo,
die Argumentation erinnert mich entfernt an das, was damals beim Aufnahmebuffer geschrieben wurde. Und auch da hat die Vergrößerung letzlich bei vielen Problemen geholfen.
Daß ein größerer Buffer nichts bringt, wenn man Aufnahmen von 3sat nachts mit allen Audiospuren verarbeiten will, ist klar. Aber mir geht es wie gesagt um 1-2 Aussetzer pro Stunde, und das bei einer Aufnahme von Premiere Film. Da würde ich erstmal nicht davon ausgehen, daß die Datenrate insgesamt einfach zu hoch ist.
Meine Philosophe wäre diese: Der Movieplayer sollte so schnell wie möglich so viel wie möglich vom Netzwerk in den internen Puffer schieben. Wenn dann eine anspruchsvolle Szene kommt, hat er bei einem großen Buffer mehr Chancen noch was rauszureißen, als wenn der Buffer sofort leer ist. Wenn's trotz des großen Buffers nicht reicht, sei es wegen der CPU oder weil einfach noch mehr Daten gebraucht würden, dann ist das halt nicht zu ändern. Aber für Sendungen, bei denen es nur sporadisch eng wird, wäre das meiner Ansicht nach die Lösung.
Also im Sinne von: Prozeß 1 füllt permanent den Speicher nach, bis er voll ist. Prozeß 2 schaufelt die Daten aus dem Speicher zum was-weiß-ich-was-fürs-Abspielen-zuständig-ist und gibt den Speicher wieder frei. Das gibt eine Latenz von einem Speicherblock, die das Ruckeln am Ende des Buffers verschlechtert (weil Prozeß 2 erst auf Prozeß 1 warten muß), aber dafür ist das Ende eben später erreicht, so daß der Fall seltener auftritt.
Bei der Aufnahme reicht der Ringbuffer anscheinend für mehrere Sekunden Film aus. Ich wüßte so direkt nicht, warum da beim Movieplayer weniger reinpassen sollte - und welchen Grund es geben soll, den vorhandenen Speicher nicht zu nutzen. Es gibt ja schon einen Buffer. Macht ihn größer! Schaden kann es doch nicht, oder sehe ich das falsch?
Bye,
Christian
die Argumentation erinnert mich entfernt an das, was damals beim Aufnahmebuffer geschrieben wurde. Und auch da hat die Vergrößerung letzlich bei vielen Problemen geholfen.
Daß ein größerer Buffer nichts bringt, wenn man Aufnahmen von 3sat nachts mit allen Audiospuren verarbeiten will, ist klar. Aber mir geht es wie gesagt um 1-2 Aussetzer pro Stunde, und das bei einer Aufnahme von Premiere Film. Da würde ich erstmal nicht davon ausgehen, daß die Datenrate insgesamt einfach zu hoch ist.
Meine Philosophe wäre diese: Der Movieplayer sollte so schnell wie möglich so viel wie möglich vom Netzwerk in den internen Puffer schieben. Wenn dann eine anspruchsvolle Szene kommt, hat er bei einem großen Buffer mehr Chancen noch was rauszureißen, als wenn der Buffer sofort leer ist. Wenn's trotz des großen Buffers nicht reicht, sei es wegen der CPU oder weil einfach noch mehr Daten gebraucht würden, dann ist das halt nicht zu ändern. Aber für Sendungen, bei denen es nur sporadisch eng wird, wäre das meiner Ansicht nach die Lösung.
Also im Sinne von: Prozeß 1 füllt permanent den Speicher nach, bis er voll ist. Prozeß 2 schaufelt die Daten aus dem Speicher zum was-weiß-ich-was-fürs-Abspielen-zuständig-ist und gibt den Speicher wieder frei. Das gibt eine Latenz von einem Speicherblock, die das Ruckeln am Ende des Buffers verschlechtert (weil Prozeß 2 erst auf Prozeß 1 warten muß), aber dafür ist das Ende eben später erreicht, so daß der Fall seltener auftritt.
Bei der Aufnahme reicht der Ringbuffer anscheinend für mehrere Sekunden Film aus. Ich wüßte so direkt nicht, warum da beim Movieplayer weniger reinpassen sollte - und welchen Grund es geben soll, den vorhandenen Speicher nicht zu nutzen. Es gibt ja schon einen Buffer. Macht ihn größer! Schaden kann es doch nicht, oder sehe ich das falsch?
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..hier mal etwas zum Nachdenken...
..das Bild zeigt die Datenuebertragung eines realen *.ts files von 45 MB Groesse. Links das Geraffel bis einschliesslich '3' ist waehrend realem abspielen mit dem Movieplayer und rechts zeigt das Lesen des gleichen Files nach /dev/null mit der maximalen bei mir moeglichen Datenuebertragungsrate.
Vom Anfang des Geraffels bis Punkt '1' spielt der Movieplayer normal...zwischen '1' und '2' gibt es massive Tonstoerungen und zwischen '2' und '3' nur noch ein Standbild bis zum Ende (3)
Ich kann mir das nur mit Fehlern beim Movieplayer erklaeren aber nicht mit der Ueberschreitung der maximalen Datenrate. Dieses File wird ohne Fehler in PX verarbeitet bzw. wird einwandfrei mit geeigneten Playern abgespielt.
..das Bild zeigt die Datenuebertragung eines realen *.ts files von 45 MB Groesse. Links das Geraffel bis einschliesslich '3' ist waehrend realem abspielen mit dem Movieplayer und rechts zeigt das Lesen des gleichen Files nach /dev/null mit der maximalen bei mir moeglichen Datenuebertragungsrate.
Vom Anfang des Geraffels bis Punkt '1' spielt der Movieplayer normal...zwischen '1' und '2' gibt es massive Tonstoerungen und zwischen '2' und '3' nur noch ein Standbild bis zum Ende (3)
Ich kann mir das nur mit Fehlern beim Movieplayer erklaeren aber nicht mit der Ueberschreitung der maximalen Datenrate. Dieses File wird ohne Fehler in PX verarbeitet bzw. wird einwandfrei mit geeigneten Playern abgespielt.
-
- Tuxboxer
- Beiträge: 4332
- Registriert: Dienstag 7. Mai 2002, 17:04
... evtl. müßte man die cpu last der box und den mem auf der gleichen zeitskala sehen. Nicht das da irgendein prozess sich cpu auslastung greift, die dann dem MP einfach nicht mehr zur verfügung steht. Hast du den test mit deaktiviertem sectionsd gemacht?
---------------------------
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
Alle weiteren Infos findest Du im WIKI
Bitte vor dem posten Boardregeln lesen und verstehen!
Wie erstelle ich ein Bootlog? Wo finde ich die FAQ?
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
100%ig kein Problem fuer die Box-CPU!Tommy hat geschrieben:... evtl. müßte man die cpu last der box und den mem auf der gleichen zeitskala sehen. Nicht das da irgendein prozess sich cpu auslastung greift, die dann dem MP einfach nicht mehr zur verfügung steht.
siehe oben...es gibt da kein Problem mit der Belastung...versuch bitte mal das Diagramm mit Logik zu interpretieren. Zur weiteren 'Verwirrung' hier ein Diagramm von besagtem Testfile...Hast du den test mit deaktiviertem sectionsd gemacht?
..stoerungsfrei ueber Netz abgespielt mit MediaplayerClassic und dem VLC. Nach weiteren Ueberlegungen/Experimenten tendiere ich zu einer extremen Empfindlichkeit des Movieplayers bei AudioStream-Besonderheiten/bei kleinen Fehlern im Audiostream klappt irgendwas mit der Synchronitaet nicht die zu Resync-Versuchen mit Standbild/Abbruch fuehrt.
Zuletzt geändert von petgun am Sonntag 12. Februar 2006, 23:13, insgesamt 1-mal geändert.
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo,
mal andersrum gefragt: Was macht die CPU eigentlich, wenn sie ein .TS abspielt bzw. aufnimmt? Nach meiner DAU-Vorstellung muß sie da nicht viel mehr tun, als dieselben Daten durch die Gegend zu schieben, die auch bei normalem Betrieb durch die dbox rauschen. Und das müßte sie doch in ausreichender Geschwindigkeit schaffen... oder?
Bye,
Christian
mal andersrum gefragt: Was macht die CPU eigentlich, wenn sie ein .TS abspielt bzw. aufnimmt? Nach meiner DAU-Vorstellung muß sie da nicht viel mehr tun, als dieselben Daten durch die Gegend zu schieben, die auch bei normalem Betrieb durch die dbox rauschen. Und das müßte sie doch in ausreichender Geschwindigkeit schaffen... oder?
Bye,
Christian
-
- Erleuchteter
- Beiträge: 785
- Registriert: Samstag 6. August 2005, 03:39
Laut dem Dev vom MP ist das füllen des Demuxxers aufwändiger als das lesen des kompletten Datenstroms vom Transponder und das schicken übers nfs.teddy278 hat geschrieben:Hallo,
mal andersrum gefragt: Was macht die CPU eigentlich, wenn sie ein .TS abspielt bzw. aufnimmt? Nach meiner DAU-Vorstellung muß sie da nicht viel mehr tun, als dieselben Daten durch die Gegend zu schieben, die auch bei normalem Betrieb durch die dbox rauschen. Und das müßte sie doch in ausreichender Geschwindigkeit schaffen... oder?
Bye,
Christian
Bye
PetB
1 x DBOX2 Phillips, 1 x DBOX2 Nokia, 1 x DBOX2 Sagem, 100er Gibertini (Astra / Hotbird), NFS Server
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
Wie schon mal erwaehnt wird die gesamte Aufnahme (woraus der Testschnipsel stammt) fehlerfrei mit dem Movieplayer abgespielt wenn ich den orginal-Ton (256Kbps) auf 192kbs transkodiere wobei die Datenrate natuerlich geringfuegig abnimmt...ist grafisch nicht darzustellen.
@gagga
bitte schau Dir das mit dem Audiohandling noch mal an.
@gagga
bitte schau Dir das mit dem Audiohandling noch mal an.
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo.
Laut petgun ist die Auslastung der CPU beim Movieplayer ja eher mäßig. Worauf wartet die CPU, wo ist der Flaschenhals, das ist die Frage... Gibt der Demuxxer die Geschwindigkeit vor, mit dem Daten gefüttert werden? Hat der noch einen eigenen (kleinen) Buffer, den man geschickter ausnützen könnte?
Oder - wieder zurück zum Ausgangspunkt - ist vielleicht das Lesen vom Netz einfach nicht effizient genug? Die Grafik zeigt ja, daß da netzwerktechnisch noch Luft wäre. Die CPU hat auch nichts weiter zu tun. Warum nutzt sie ihre Zeit nicht dafür, schon mal einen Puffer zu füllen?
Ich hoffe, ich nerve Euch nicht zu sehr mit meinen dummen Fragen...
Bye,
Christian
Technische Verständnisfrage: Werden die Daten bei normalem TV-Betrieb komplett an der CPU vorbeigeleitet, oder bekommt der Demuxxer die Daten immer über die CPU?petb hat geschrieben:Laut dem Dev vom MP ist das füllen des Demuxxers aufwändiger als das lesen des kompletten Datenstroms vom Transponder und das schicken übers nfs.
Laut petgun ist die Auslastung der CPU beim Movieplayer ja eher mäßig. Worauf wartet die CPU, wo ist der Flaschenhals, das ist die Frage... Gibt der Demuxxer die Geschwindigkeit vor, mit dem Daten gefüttert werden? Hat der noch einen eigenen (kleinen) Buffer, den man geschickter ausnützen könnte?
Oder - wieder zurück zum Ausgangspunkt - ist vielleicht das Lesen vom Netz einfach nicht effizient genug? Die Grafik zeigt ja, daß da netzwerktechnisch noch Luft wäre. Die CPU hat auch nichts weiter zu tun. Warum nutzt sie ihre Zeit nicht dafür, schon mal einen Puffer zu füllen?
Ich hoffe, ich nerve Euch nicht zu sehr mit meinen dummen Fragen...
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..genau so ist das in _meinem_ Beispiel. Bei diesen grenzwertigen files, koennte es natuerlich bei einigen wegen der Bandbreite _zusaetzlich_ zu Netzwerk-Problemen kommen. Das trifft imo bei mir in diesem Beispiel _nicht_ zu!teddy278 hat geschrieben:..Die Grafik zeigt ja, daß da netzwerktechnisch noch Luft wäre. Die CPU hat auch nichts weiter zu tun...
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo.
Bye,
Christian
Wie gesagt, ich klammere ausdrücklich die Fälle aus, bei denen definitiv zu viele Daten anfallen, um durch's Netz zu passen. Da ist es klar, wo das Nadelöhr liegt. Mein Beispiel bleibt: 120 Minuten Film, 2 Aussetzer, Premiere-Film-Datenmenge.petgun hat geschrieben:..genau so ist das in _meinem_ Beispiel. Bei diesen grenzwertigen files, koennte es natuerlich bei einigen wegen der Bandbreite _zusaetzlich_ zu Netzwerk-Problemen kommen. Das trifft imo bei mir in diesem Beispiel _nicht_ zu!
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..das ist ein sehr kleiner Fehler und bei den ueblichen Datenraten von Premiere kannst Du imo mit einiger Gewissheit davon ausgehen dass es _nicht_ an der Datenrate liegt sondern eben an so einem Audio-Resync Fehler. Versuch mal _nur_ den Audiostream zu transkodieren....dann koennten/sollten imo die beiden Fehler verschwinden. Der requestete groessere Buffer hilft mit Sicherheit nicht bei diesen Resync-Fehlern.teddy278 hat geschrieben:Mein Beispiel bleibt: 120 Minuten Film, 2 Aussetzer, Premiere-Film-Datenmenge.
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo.
Bye,
Christian
Was meinst Du mit "_nur_ den Audiostream transkodieren"? Die Aussetzer (-> Bildhänger, teilweise Ton, teilweise anschließend fehlerhafte Synchronisation) treten exakt an den Stellen auf, an denen gerade viel Bewegung im Bild ist (lies: sein sollte). Und das nicht nur bei einem, sondern bei mehreren Filmen. Bei ruhigen Szenen keine Probleme. Das sieht mir schon sehr nach "Buffer underrun" aus, wobei die Frage offenbleibt, welcher Buffer leerläuft und wie man ihn schneller auffüllen könnte.petgun hat geschrieben:..das ist ein sehr kleiner Fehler und bei den ueblichen Datenraten von Premiere kannst Du imo mit einiger Gewissheit davon ausgehen dass es _nicht_ an der Datenrate liegt sondern eben an so einem Audio-Resync Fehler. Versuch mal _nur_ den Audiostream zu transkodieren....dann koennten/sollten imo die beiden Fehler verschwinden. Der requestete groessere Buffer hilft mit Sicherheit nicht bei diesen Resync-Fehlern.teddy278 hat geschrieben:Mein Beispiel bleibt: 120 Minuten Film, 2 Aussetzer, Premiere-Film-Datenmenge.
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..fischen im Trueben mit Vermutungen helfen nicht viel weiter. Ich hatte auch mal ein Premiere Abo und _nie_ (trotz vieler Aufnahmen) dermassen hohe Datenraten wie zB. beim ZDF/3Sat gesehen.
Analysiere die besagten Stellen an denen es ruckelt...dann wissen wir mehr....ich bin mir fast sicher dass es nicht an der Datenrate liegt....es sei denn Du hast ein grottenschlechtes Netzwerk....wie hoch ist denn Deine maximale Datenrate fuer lesen?
Analysiere die besagten Stellen an denen es ruckelt...dann wissen wir mehr....ich bin mir fast sicher dass es nicht an der Datenrate liegt....es sei denn Du hast ein grottenschlechtes Netzwerk....wie hoch ist denn Deine maximale Datenrate fuer lesen?
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo.
Ich glaube nicht, daß es an der durchschnittlichen Datenrate liegt, die ist ja eher mäßig. Irgendwo fehlen offenbar Daten zum richtigen Zeitpunkt, und die Frage ist wo und warum. Wenn es tatsächlich an der Verbindung zwischen CPU und Demuxxer liegt... dann kann man sich - da gebe ich Dir recht - das IDE-Interface eigentlich wirklich sparen, denn dieses Problem würde es wohl nicht lösen können.
Nochmal gefragt: Laufen die Daten bei normalem TV-Betrieb auch durch die CPU zum Demuxxer?
Bye,
Christian
Wie ich schon schrieb: Mein NAS lahmt noch etwas, rsize ist maximal 8192. Soll mit dem nächsten Firmware-Update vielleicht größer werden... ob's stimmt? Datenrate liegt irgendwo bei 7 Mbit/s, wenn ich das richtig im Kopf habe. NAS und dbox sind über einen Hub verbunden, an dem während der Wiedergabe kein weiteres Gerät hängt (ausgeschaltet). Der NAS stellt sich brav auf 10/half ein.petgun hat geschrieben:Analysiere die besagten Stellen an denen es ruckelt...dann wissen wir mehr....ich bin mir fast sicher dass es nicht an der Datenrate liegt....es sei denn Du hast ein grottenschlechtes Netzwerk....wie hoch ist denn Deine maximale Datenrate fuer lesen?
Ich glaube nicht, daß es an der durchschnittlichen Datenrate liegt, die ist ja eher mäßig. Irgendwo fehlen offenbar Daten zum richtigen Zeitpunkt, und die Frage ist wo und warum. Wenn es tatsächlich an der Verbindung zwischen CPU und Demuxxer liegt... dann kann man sich - da gebe ich Dir recht - das IDE-Interface eigentlich wirklich sparen, denn dieses Problem würde es wohl nicht lösen können.
Nochmal gefragt: Laufen die Daten bei normalem TV-Betrieb auch durch die CPU zum Demuxxer?
Bye,
Christian
-
- Tuxboxer
- Beiträge: 4654
- Registriert: Samstag 27. April 2002, 13:19
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo,
danke für die Antwort. Das macht die Erklärung des Devs zumindest plausibel, auch wenn mir weiterhin etwas der Glaube fehlt. Damit begrabe ich dann mal die Hoffnung auf eine wirklich funktionierende Movieplayer-Lösung.
Kann jemand einen premierefähigen DVB-C-Receiver mit Festplatte empfehlen...?
Bye,
Christian
danke für die Antwort. Das macht die Erklärung des Devs zumindest plausibel, auch wenn mir weiterhin etwas der Glaube fehlt. Damit begrabe ich dann mal die Hoffnung auf eine wirklich funktionierende Movieplayer-Lösung.
Kann jemand einen premierefähigen DVB-C-Receiver mit Festplatte empfehlen...?
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
..das habe ich so nicht gesagt..es gibt es bei vielen das Problem mit der zu hohen Datenrate und dagegen hilft _nur_ das kommende IDE-Interface...ansonsten bin ich pers. nur davon ueberzeugt, dass es einige Fehler beim Movieplayer gibt die zu fixen sind.teddy278 hat geschrieben:Wenn es tatsächlich an der Verbindung zwischen CPU und Demuxxer liegt... dann kann man sich - da gebe ich Dir recht - das IDE-Interface eigentlich wirklich sparen, denn dieses Problem würde es wohl nicht lösen können.
Du haelts den Movieplayer also fuer fehlerfrei/optimal programmiert und konzipiert/durch nichts anderes zu ersetzen?Damit begrabe ich dann mal die Hoffnung auf eine wirklich funktionierende Movieplayer-Lösung.
-
- Interessierter
- Beiträge: 45
- Registriert: Samstag 18. Dezember 2004, 16:03
Hallo.
Bye,
Christian
Seh' ich so aus? Nein, ich sehe durchaus noch eine Menge Optimierungspotential nicht nur beim Movieplayer. Aber ich werde mich nicht in die Materie einarbeiten, um es zu ändern, und ich werde auch nicht meine Zeit damit verbringen, die "Macht" von ihrem Standpunkt abbringen zu wollen. Da programmiere ich doch lieber mein eigenes Projekt weiter - nicht öffentlich und nur für mich und ich muß mir keine technischen Gründe ausdenken, um Feature Requests abzuwimmeln.petgun hat geschrieben:Du haelts den Movieplayer also fuer fehlerfrei/optimal programmiert/durch nichts anderes zu ersetzen?Damit begrabe ich dann mal die Hoffnung auf eine wirklich funktionierende Movieplayer-Lösung.
Bye,
Christian
-
- Tuxboxer
- Beiträge: 5001
- Registriert: Montag 11. November 2002, 15:26
...na dann iss ja alles klar...viel Erfolg fuer dein eigenes Kaemmerleinprojekt...hoeher/schneller/weiter/geheim/vaporware/closet-source©...Du bist mein Held!teddy278 hat geschrieben:..ich sehe durchaus noch eine Menge Optimierungspotential nicht nur beim Movieplayer. Aber ich werde mich nicht in die Materie einarbeiten, um es zu ändern, und ich werde auch nicht meine Zeit damit verbringen, die "Macht" von ihrem Standpunkt abbringen zu wollen. Da programmiere ich doch lieber mein eigenes Projekt weiter - nicht öffentlich und nur für mich und ich muß mir keine technischen Gründe ausdenken, um Feature Requests abzuwimmeln.