Größerer Buffer beim Movieplayer

[petgun]

Hi,
@teddy278
danke, das war schon eine sehr ueberzeugende Argumentation...ich denke Du hast _zusaetzlich_ zu dem Audiosync-Problem (das mir im Moment keiner wegdiskutieren kann) und dem Bufferhandling ein 'schlechtes', nicht auf die 10 Mbps HDX DboxNadeloehr Spezialdisziplin optimiertes Netzwerk. Ein ganz kleiner Lesetest wuerde Dir/uns einen Beweis liefern...um den ich Dich hiermit recht herzlich bitte, auch wenn Dein Schatz von den Faehigkeiten Deines neuen Festplatten-Reveivers begeistert ist.

cu,
peter

<edit>
...ich habe nach Deinen Bufferhandlingausfuehrungen weiter darueber nachgedacht...koennte wirklich ausschliesslich am subobtimalen/feherhaften Bufferhandling liegen was sich zuerst bei Szenen mit hoher Datenrate in Audiofehlern bemerkbar macht...ja, hat was..
Ich werde das aber mal testen mit einem file mit geringer Videobandbreite, aber auf 256kbs hochtranskodierten Audiorate...
</edit>

[petb]

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

Wie mein Kumpel ganz stolz mit seinem über 400 Euro teuren Technisat S2 zu mir sagte.
"Du, ich kann jetzt zwei Filme aufnehmen und ein drittes Programm schauen."

Ich sagte toll, ich kann für die Hälfte des Geldes fünf Programme aufnehmen und ein sechstes schauen ????
Oder ich kann meine Frau in einem der drei Zimmer das schauen lassen was sie wil und ich schaue im anderen Zimmer das was ich will.
Oder ich kann wenn eine Box spinnt immer noch mit den anderen schauen.

Da lachte mein Kumpel nur.

Aber wer zuletzt lacht.....lacht am besten.
Und das war ich.
Mein erster Lacher war als sein Receiver das erste mal die fast volle Platte absemmeln lies und neu formatieren angesagt war.
Der zweite Lacher war als er doch nicht das dritte Programm live schauen konnte sondern nur zwei mal aufnehmen und ein drittes bereits aufgenommenenes laufen lassen konnte. (Komisch, die DBox kann aufnehmen und ein anders vom Transponder anzeigen)
Und der vierte Lacher war als der PVR wieder die ganze Platte absemmeln lies.
Und jetzt, lach ich immer noch weil seit 6 Wochen ist das Teil in Reparatur und die sagen sie finden nichts.

Anmerkung:
Selbstverständlich habe ich nicht wirklich gelacht, sondern mit ihm gefühlt, weil es echt Mist ist wenn alle Aufnahmen auf einen Schlag weg sind.
Und eine Box habich ihm auch für die Zeit in der er garnichts hat geliehen.

Was ich sagen will, es ist nicht alles Gold was glänzt.
Und so wünsche ich dir einen einwandfrei funktionierenden PVR !

Da kommen mir die Probleme bei der DBox nicht mehr so wild vor.
Bye
PetB

[petb]

Ok, habe das 45 mb Schnipsel von petgun auch versucht....

Das gleiche.
Auf dem PC läuft es einwandfrei und auf der Box wie folgt.

Nokia JTG vom 26.12.05 Ruckler/Ton Problem an den gleichen Stellenwie bei petgun.
Sagem JTG vom 04.10.05
Kurzes Problem sofort beim Start, dann einwandfrei bsi zur ersten Rucklerstelle, dann 0 gedrückt und läuft fast bis Schluss.

Das Netzwerk kann dafür definitiv nicht zuständig sein.

Ich vermute mal folgendes:
Der Puffer cachte ja byteweise den Stream.
Was ist nun wenn er im cahe sagen wir mal Bilddaten bis 13:00 hat und audio aber nur bis 12:50.
Dann muss er bei einem sehr stark schwankendem Videostream und auch noch einen Audiostream den er konvertieren muss ja zwangsläufig ins Stocken kommen.
Vom Transponder her hat er das Problem vieleicht nicht ?
vieleicht wird da der Audioteil und der Videoteil separat gefüllt ?
(Ist nur ne Idee {Oder hat das so schon jemand gesagt ?})

@petgun
Wie machst du den resampling kram ?
hab eben im ProjectX geschaut und nichts passendes gefunden ?
Erst alles trennen oder ...?
bye
PetB

[teddy278]

Hallo.

danke, das war schon eine sehr ueberzeugende Argumentation...ich denke Du hast _zusaetzlich_ zu dem Audiosync-Problem (das mir im Moment keiner wegdiskutieren kann) und dem Bufferhandling ein 'schlechtes', nicht auf die 10 Mbps HDX DboxNadeloehr Spezialdisziplin optimiertes Netzwerk. Ein ganz kleiner Lesetest wuerde Dir/uns einen Beweis liefern...um den ich Dich hiermit recht herzlich bitte, auch wenn Dein Schatz von den Faehigkeiten Deines neuen Festplatten-Reveivers begeistert ist.

Aaalso... Erinnerst Du Dich an meinen ersten Beitrag in diesem Thread? Der sozusagen diesen Thread aus der Taufe gehoben hat? Da schrieb ich was von einem schwachbrüstigen NAS. Das Ding ist einfach lahm, empfehlt bloß nie wieder jemandem ein Claxan. Bei CIFS ist es halb so schnell wie meine Linkstation, per FTP sogar noch langsamer als das. NFS kann ich so direkt nicht messen, erwarte aber bei rsize=wsize=8192 auch keine Wunder. Das Ding geht zurück, so oder so.

Anschluß erfolgt über einen 10baseT-Hub, an dem zum Wiedergabezeitpunkt nichts weiter hängt. Aufnahmen laufen sauber durch (3sat / ZDF habe ich zuletzt freilich nicht mehr intensiv getestet), Wiedergabe klappt im Normalfall auch problemlos... bis auf die schnellen Stellen. Qualitativ konnte ich keinen Unterschied feststellen zwischen dbox=x=NAS und dbox===Hub===NAS.

Leserate habe ich nicht mehr im Kopf, weil ich eh keine Optimierungsmöglichkeiten mehr gesehen habe. Waren wohl so 7 MBit, ohne jede Garantie. Bedenke bitte, daß ich keine "Beuys und Beuys"-Kulturzeit sehen möchte, sondern Datenmüll aus dem Pay-TV.

EDIT: Bittebittebitte schiebt doch nicht immer alles auf das "nichtoptimierte Netzwerk". Schaut Euch den Quelltext des Movieplayers an - ich kann da keine Optimierung für das 10/Half-Nadelöhr erkennen. Jede Verbesserung der Software wirkt sich auf alle Anwender aus, nur das Niveau ist unterschiedlich.

Petgun: Vielleicht solltest Du einen neuen Feature Request öffnen, der sich mit der Signalverarbeitung im Demuxxer befaßt... Denn soweit ich gesehen habe, würde ich Deine Probleme eher dort vermuten als im Movieplayer.

Ich sagte toll, ich kann für die Hälfte des Geldes fünf Programme aufnehmen und ein sechstes schauen ????

Und wieviel Arbeitszeit mußt Du investieren bis es läuft?

Auf meiner dbox läuft seit einem guten Jahr Jahr Neutrino... so richtig stabil übrigens nicht, aber das kann auch an der Hardware liegen. Eine neue dbox sollte ich vielleicht einplanen. Seit zwei Wochen bin ich mal wieder dabei, mich mit HD-Recording zu befassen. Das sind zwei Wochen intensive Beschäftigung ohne wirklich zufriedenstellendes Ergebnis.

Wenn ich mich hier so im Forum umsehe, dann zeichnet sich eindeutig ab, daß der Weg über die 10/Half-Schnittstelle mittelfristig eine Sackgasse ist. Nein, ich mache mir keine Illusion darüber, daß ein größerer Buffer keine Heilung bringt, sondern nur Linderung. Die Kosten für IDE-Interface und 2,5"-Platte kann ich also schonmal einplanen. Zusammen mit den 200 Euro für's NAS läge ich dann schon bei - wieviel? 300? 350?

Dann noch eine dbox dazu, um gleichzeitig zwei Sender aufzeichnen zu können, dann noch ein Switch... halt: geht ja nicht stabil, also IDE-Interface - sagen wir: 200 Euro für zweite dbox mit IDE-Festplatte? Und die beiden dboxen sind immer noch keine integrierte Lösung: Ich muß mir selbst überlegen, welche was wann aufzeichnen soll und auf welcher ich dann fernsehen kann. Und bei welcher ich dazu die Fernbedienung deaktivieren muß - wir haben nur einen Fernseher, die zwei Boxen stünden direkt beieinander. Und wie sieht es mit Timeshift aus? Die Kosten für das zweite Premiere-Abo darf ich dann vermutlich auch nochmal draufschlagen.

Überschlägig bin ich also bei mindestens 500 Euro, davon 200 Euro Lehrgeld , einem Haufen Arbeit und einem fraglichen Ergebnis. Das ist in etwa der Preis eines Topfield 5200 PVRc mit 80 GB Platte.

Keine Frage: Die Tuxbox hat ihren ganz eigenen Charme und bietet Möglichkeiten, von denen andere nur träumen können. Aber sie ist halt durch die Hardware und durch den Charakter des Hobby-Projektes doch etwas limitiert... Manchmal möchte man auch einfach nicht mehr basteln, sondern nur noch die Füße hochlegen und sich berieseln lassen.


Bye,
Christian

[petgun]

Ich werde das aber mal testen mit einem file mit geringer Videobandbreite, aber auf 256kbs hochtranskodierten Audiorate...

..habe ich gerade gemacht (ca. max 5Mbps)...absolut keine Chance das File mit dem Movieplayer abzuspielen...verhaelt sich aehnlich wie mein Testschnipsel.
Dh. fuer mich, das es absolut _nix_ mit der Datenrate zu tun hat...was es mir wieder schwer macht an Buffer over/underrun zu glauben.

[teddy278]

Hallo.

Dh. fuer mich, das es absolut _nix_ mit der Datenrate zu tun hat...was es mir wieder schwer macht an Buffer over/underrun zu glauben.

Ich kaufe mir einen Topfield.


Bye,
Christian

[petgun]

..Ich kaufe mir einen Topfield.

ich nicht...ich hoffe auf einen guten Abschluss dieses Threads hier ;-)

[Torsten73]

@PetB:
Resampeln oder Recoden geht sehr gut mit TMPGENC.

Danke Petgun für Deine Bemühungen. Ich hoffe nur das wir noch des Rätzels Lösung finden und nicht nur die Ursache Aber das ist ja schließlich immer der erste Schritt...

Wer könnte denn da patent genug sein um daran zu arbeiten?

Cu
Torsten

[petb]

@teddy278
hab hier meine Antwort auf deine Frage, wie lange hab ich gebraucht bis alles lief geschrieben, wollte hier im Thread nicht soo ausführlich ein anderes Thema breittreten.
Hab das schon so oft gemacht
http://forum.tuxbox-cvs.sourceforge.net ... 438#289438

@Torsten73
Achso, dachte petgun hätte das nur mit projectX gemacht.

Aber zum eigentlichen:
Wie steht es jetzt mit dem Puffer ?
Wissen wir jetzt was es mit den Werten auf sich hat ?
hat schon mal jemand getestet ?
Oder hängen wir immer noch an dem "blocking Kram" ?
bye
PetB

[teddy278]

Hallo.

Aber zum eigentlichen:
Wie steht es jetzt mit dem Puffer ?
Wissen wir jetzt was es mit den Werten auf sich hat ?
hat schon mal jemand getestet ?
Oder hängen wir immer noch an dem "blocking Kram" ?

So wie ich das sehe, würde ich folgendes machen, wenn ich echte C-Kenntnisse hätte:

- Ringpuffer einrichten
- Lesen in einen zusätzlichen Thread auslagern
- ev. Skip-Funktionen mit 1/3, 4/6, 7/9 auf den Buffer anpassen (habe mir noch nicht angeschaut, wie das genau funktioniert)


Bye,
Christian

[petgun]

Wie steht es jetzt mit dem Puffer ?

da gibt es ja kontroverse Meinungen/Unsicherheiten bei den Experten ob/wie/was das bringt...einfach ausprobieren..mit einem File dessen Bandbreite ueber _laengere_ Zeit die maximale Uebertragungsrate des Netzwerks uebersteigt...siehe 'Streambuffer vergroessern'.
BTW hatten wir hier schon eine sehr gute Diskussion um das gleiche Thema 'Underrun beim Befuellen des Demux erkennen'...zieht Euch das nochmal rein, damit sich die Experten hier nicht erneut die Finger wund schreiben muessen...ging nicht weiter 'damals'...kann sein das es nicht geht/nix bringt...100%ig eine ziemlich harte Nuss.

[digi_casi]

Keine Frage: Die Tuxbox hat ihren ganz eigenen Charme und bietet Möglichkeiten, von denen andere nur träumen können. Aber sie ist halt durch die Hardware und durch den Charakter des Hobby-Projektes doch etwas limitiert... Manchmal möchte man auch einfach nicht mehr basteln, sondern nur noch die Füße hochlegen und sich berieseln lassen.

jo, genau... irgendwann hat man mal die schnauze voll... und kauft sich wieder einen richtigen receiver... wobei ich hier nicht von dem reel/dream/etc kram rede

[digi_casi]

Wie steht es jetzt mit dem Puffer ?

da gibt es ja kontroverse Meinungen/Unsicherheiten bei den Experten ob/wie/was das bringt...einfach ausprobieren..mit einem File dessen Bandbreite ueber _laengere_ Zeit die maximale Uebertragungsrate des Netzwerks uebersteigt...siehe 'Streambuffer vergroessern'.
BTW hatten wir hier schon eine sehr gute Diskussion um das gleiche Thema 'Underrun beim Befuellen des Demux erkennen'...zieht Euch das nochmal rein, damit sich die Experten hier nicht erneut die Finger wund schreiben muessen...ging nicht weiter 'damals'...kann sein das es nicht geht/nix bringt...100%ig eine ziemlich harte Nuss.

also nach meinen beobachtungen bringt ein groesserer buffer nur was, wenn der buffer im verhaeltnis zur netzwerk speed zu klein ist.
ich kann auf der dream mit 54 mbit wlan normal aufgenommene dvds abspielen, aber bei kauf-dvds (nicht transcodet) ruckelts irgendwann, egal wie gross der buffer ist.

[teddy278]

Hallo.

BTW hatten wir hier schon eine sehr gute Diskussion um das gleiche Thema 'Underrun beim Befuellen des Demux erkennen'...zieht Euch das nochmal rein, damit sich die Experten hier nicht erneut die Finger wund schreiben muessen...ging nicht weiter 'damals'...kann sein das es nicht geht/nix bringt...100%ig eine ziemlich harte Nuss.

Daß es keine Lösung gibt, glaube ich nicht (da haben wir wieder den Glaube, der die Berge versetzt...)

Aber die Diskussion ist in der Tat sehr interessant, auch wenn es da ja eigentlich um ein "umgekehrtes" Problem geht (Stream-Wiedergabe). Besonders treffend sei nochmal folgendes Zitat hierher kopiert:

Bei der Wiedergabe ueber NFS sieht es aehnlich aus: Der Empfangspuffer kann mit 10MBps gefuellt werden, auch wenn die Datenrate des Streams deutlich geringer ist. Wenn also die Bitrate steigt, dann ist der Puffer normalerweise voll und kommt bei einer Spitze voll zum Tragen. Sobald die Bitrate wieder sinkt, kann er in kuerzester Zeit wieder gefuellt werden. Auch hier kann man einfach durch Vergroesserung des Puffers laengere Bitratenspitzen ueberbruecken.

Schön, die eigenen Gedanken von anderen formuliert zu lesen.

Ich würde einen großen Ringspeicher (sagen wir: 2 MB?) einrichten, die Größe der Lesehäppchen (sagen wie: 1024 Byte?) von der Größe der Schreibhäppchen (sagen wir: 188 Byte?) abkoppeln, Lesen und Schreiben in zwei Threads auslagern und dann einfach mal gucken, was passiert.

Im nächsten Schritt dann die Größe des Ringspeichers über die GUI konfigurierbar machen und vielleicht alles unnötige (sectionsd...) beim Start runterfahren und alles an Speicher greifen, was es gibt.

Und im übernächsten Schritt könnte man sich mit dem Buffer des Demuxers beschäftigen - meine unkanalisierte Vermutung ist, daß dort die Lösung des Audioproblems begraben liegen könnte.

wobei ich hier nicht von dem reel/dream/etc kram rede

Sondern...? Ich bin immer noch auf der Suche und nichts ist entschieden.

also nach meinen beobachtungen bringt ein groesserer buffer nur was, wenn der buffer im verhaeltnis zur netzwerk speed zu klein ist.
ich kann auf der dream mit 54 mbit wlan normal aufgenommene dvds abspielen, aber bei kauf-dvds (nicht transcodet) ruckelts irgendwann, egal wie gross der buffer ist.

Der Buffer muß angemessen sein für die Geschwindigkeitsschwankungen des Netzwerks und für die Bitrate des wiederzugebenden Films. Die Durchschnittsrate des Films muß unter der Durchschnittsrate des Netzwerks liegen. Je weiter die beiden auseinanderklaffen, desto kleiner kann der Buffer sein.

Also bei WLAN müßte der Buffer größer sein als bei fester Verdrahtung, bei ARD größer als bei Sat1, und beim ZDF funktioniert es u.U. gar nicht, weil die Durchschnittsrate zu hoch ist. Das schöne ist: Es gibt keinen zu großen Buffer, also auch wenn man nur Sat1 verarbeitet schadet ein Buffer nicht, der auf's ZDF ausgelegt ist (nicht, daß so ein Buffer ins dbox-Ram passen würde).

Denkt an meine Worte: Ein vorgelagerter Ringbuffer wird viele Probleme lösen.


Bye,
Christian

[petgun]

hi,

Aber die Diskussion ist in der Tat sehr interessant, auch wenn es da ja eigentlich um ein "umgekehrtes" Problem geht (Stream-Wiedergabe). Besonders treffend sei nochmal folgendes Zitat hierher kopiert:

Bei der Wiedergabe ueber NFS..
.
Auch hier kann man einfach durch Vergroesserung des Puffers laengere Bitratenspitzen ueberbruecken.

Schön, die eigenen Gedanken von anderen formuliert zu lesen.

ja, sowas ist immer wieder schoen. Auch wenn's da um ein "umgekehrtes" Problem geht, zeigen die Statements der Experten, dass es keinegswegs mit der hier vorgeschlagenen Vergrosserung des Buffers getan ist...kann imo 'schlimme' Auswirkungen haben....nix geht mehr. Aber ganz klar, Versuch macht klug!!

Die zu erwartenden Nachteile so eines fetten Buffer hat hier noch keiner betrachtet...das nervt zB. schon ganz schoen wenn man viele Sekunden auf den Filmstart warten muss..und es gibt weitere Nachteile...

Mir ist in diesem Thread (und in dem mit dem "umgekehrten" Problem) nur wieder klar geworden, dass ich viel zu wenig ueber die tatsaechlichen Zusammenhaenge weiss bzw. vergessen/verdraengt habe. In diesem Sinne entschuldige ich mich hiermit bei gagga fuer die angedichteten Movieplayer-Fehler/Disadvantages die nicht auf sein Konto gehen.

Ganz_leicht_aus_dem_Fenster_lehn:Es sollte aber allen hier klar sein, dass das kommende IDE-Interface keine Abhilfe bei dem 'Audiosync-Problem' bringen wird/kann...diese Streams werden genauso ruckeln und abbrechen...wenn da nix gefixt wird!

cu,
peter

--
Ich hasse diesen Römer namens Status Quo!
[Ray Bradbury: Fahrenheit 451]

[teddy278]

Hallo.

ja, sowas ist immer wieder schoen. Auch wenn's da um ein "umgekehrtes" Problem geht, zeigen die Statements der Experten, dass es keinegswegs mit der hier vorgeschlagenen Vergrosserung des Buffers getan ist...kann imo 'schlimme' Auswirkungen haben....nix geht mehr. Aber ganz klar, Versuch macht klug!!

Wenn die Auswirkungen durch den Buffer schlimmer werden, dann ist das ein Grund mehr, an die Ursache des jeweiligen Problems zu gehen. Einen sauberen Datenstrom am Demuxxer sehe ich persönlich eher als Vorteil denn als Nachteil.

Die zu erwartenden Nachteile so eines fetten Buffer hat hier noch keiner betrachtet...das nervt zB. schon ganz schoen wenn man viele Sekunden auf den Filmstart warten muss..und es gibt weitere Nachteile...

Du hast also den von jw beschriebenen Unterschied zwischen einem Buffer beim Streaming und einem Buffer bei Direktwiedergabe auch noch nicht so ganz verstanden? Bei Direktwiedergabe kann man auf "Prebuffering" (tolles Wort) verzichten. Schlimmstenfalls stockt es am Anfang, wenn zu früh die erste Spitze kommt. Bestenfalls wird der Buffer gemütlich während des Vorspanns gefüllt und es sind bei der ersten Explosion dann genug Reserven vorhanden.

Ganz_leicht_aus_dem_Fenster_lehn:Es sollte aber allen hier klar sein, dass das kommende IDE-Interface keine Abhilfe bei dem 'Audiosync-Problem' bringen wird/kann...diese Streams werden genauso ruckeln und abbrechen...wenn da nix gefixt wird!

Das hatte ich ja auch schon mal angemerkt. Aber sieh es mal so rum: Wenn man jetzt den Buffer angeht hat man eine gute Grundlage, die weiteren Probleme zu beheben, bevor das IDE-Interface produktiv wird.


Bye,
Christian

[digi_casi]

Du hast also den von jw beschriebenen Unterschied zwischen einem Buffer beim Streaming und einem Buffer bei Direktwiedergabe auch noch nicht so ganz verstanden? Bei Direktwiedergabe kann man auf "Prebuffering" (tolles Wort) verzichten. Schlimmstenfalls stockt es am Anfang, wenn zu früh die erste Spitze kommt. Bestenfalls wird der Buffer gemütlich während des Vorspanns gefüllt und es sind bei der ersten Explosion dann genug Reserven vorhanden.

so weit zur theroie...
ich schlage vor, dass du ganz schnell das programmieren lernst... um deine weisheiten auch ausprobieren zu koennen
dann wirst du auch merken, dass die realitaet oft nicht so ist, wie man sie gerne haette

[teddy278]

Hallo.

so weit zur theroie...
ich schlage vor, dass du ganz schnell das programmieren lernst... um deine weisheiten auch ausprobieren zu koennen
dann wirst du auch merken, dass die realitaet oft nicht so ist, wie man sie gerne haette

Oh, endlich mal wieder jemand der "kann kein C" mit "ist doof" übersetzt. Ich habe meine "Weisheiten" durchaus schon ausprobiert, das kann ich Dir versichern.


Bye,
Christian

[petgun]

Hi,
..ich will Deinen Bufferrequest fuer den Movieplayer nicht schlecht reden und bin 100% dafuer das mal zu probieren, deshalb ja schon mehrmals der Spruch 'Versuch macht klug'...ich teste gerne mit, wenn's was zu testen gibt!

Wenn man jetzt den Buffer angeht hat man eine gute Grundlage, die weiteren Probleme zu beheben, bevor das IDE-Interface produktiv wird.

;-) auf die Reihenfolge/Prioritaet habe ich keinen Einfluss...das kommende Geschrei und die Entaeuschung kann ich aber jetzt schon prophezeien wenn der Hoffnungstraeger in Bezug auf den Movieplayer nicht das haelt was ihm angedichtet wird...und dem Geschrei will ich gerne vorbeugen. Ausserdem wollte ich nur noch mal klarstellen dass selbst ein absolut perfektes IDE-Interface nichts gegen den Fehler ausrichten kann. Die Ruckelproblematik mit dem Movieplayer wir fast ausschliesslich (selbst von den 'Experten') mit den mangelnden Resourcen (CPU/10Mbit NIC) der DBox begruendet...und das halte ich fuer ein sehr grosses Geruecht.

cu,
peter

--

Die dbox ist hardwaretechnisch einfach Schrott..

[digi_casi]

wo ist eigentlich dieses problematische movie clip... wuerde es gerne mal mit dem enigma movieplayer probieren...

[petgun]

wo ist eigentlich dieses problematische movie clip... wuerde es gerne mal mit dem enigma movieplayer probieren...

ist ein Schnipsel von 45MB. Ich habe das Teil petb auf einen/seinen? ftp-Server gesendet...vielleicht gibt er Dir ja die Adresse. Aber Du kannst das mit der Audiosync-Problematik mit jeder Aufnahme selbst testen...einfach die Audiospur auf 256kbps transkodieren. Finde ich gut, das mal unter Enigma zu testen und ich bin gespannt, was dabei raus kommt.

[Tommy]

zumal da ja das LAN ganz außen vor sein sollte

[digi_casi]

dann transcode ich mal eine dvd auf 256 kbit/s...
ist allerdings auf dreambox 7000... habe keine dbox mehr... die ist hardwaremaessig schrott *fgggg*

[petgun]

dann transcode ich mal eine dvd auf 256 kbit/s...
ist allerdings auf dreambox 7000... habe keine dbox mehr... die ist hardwaremaessig schrott *fgggg*

...ok, ich gespannt ob Deine dreambox auch Schrott ist

[petb]

dann transcode ich mal eine dvd auf 256 kbit/s...
ist allerdings auf dreambox 7000... habe keine dbox mehr... die ist hardwaremaessig schrott *fgggg*

...ok, ich gespannt ob Deine dreambox auch Schrott ist

Der Kommentar hat mir gefallen.
digi_casi kann ja jetzt nicht zugeben das die Dream das auch nicht sauber abspielt (auch wenn ich befürchte, das sie es kann)
PetB