ruckelndes Divx

Original von LinTV-Fan

Zitat

1. Ist es nur bei Divx ?? oder auch bei XviD ??
2. wie sieht es bei vob Files aus
3. und mpeg2 Files ..

Soweit ich das sehe, ist dieses Problem nur bei Divx vorhanden, aber auch längst nicht bei allen, die ich habe.

Zitat

Wäre es denkbar den mplayer auf eine zusätzliche Hollywood Karte
zu leiten , oder ist das Problem bei diesen Karten ebenfalls vorhanden?
[...]
Es scheint ja ein Problem beim Transfer der mpeg2 Daten in die DVB Karte zu sein .

Meines Erachtens ist es ein internes MPlayer-Problem und kein Transferproblem, denn dieses Problem tritt genauso auf, wenn du den MPlayer ohne DVB-Treiber kompiliert hast - er also in eine Datei schreibt und nicht auf die Karte. Eine auf diese Art erzeugte MPEG-Datei hat an den gleichen Stellen Ruckler, obwohl die DVB-Karte garnicht ins Spiel kommt. Daher würde eine DXR3 keinen Unterschied machen.

Zitat

Gibt es vielleicht eine spezielle Auflösung , bei der die DivX besser läuft ?

Gute Frage. Ich habe leider bisher noch keine Regel ausmachen können, anhand derer man ohne Test sagen könnte: "der Film ruckelt, dieser hier nicht".

Gruß,
Juri

jha
Kann ich absolut bestätigen. Filme die dieses Phänomen aufweisen laufen bei mir mit Xine ohne Probleme (Desktop PC mit Fedora Core). mplayer macht auf meinem Desktop PC die gleichen Probleme wie der VDR.
Es gab hier mal die Idee, Xine als alternativen Player zu mplayer an den Start zubringen. Keine Ahnung ob sich da irgendwas getan hat.

Viele Grüsse,
Obelix

Original von obelix

Zitat

mplayer macht auf meinem Desktop PC die gleichen Probleme wie der VDR.

Kann ich nicht bestätigen. Die problematischen Filme laufen auf meinem Laptop (P3 850MHz) einwandfrei, wenn mit mplayer abgespielt. Kann es sein, daß dein mplayer ohne XV-Unterstützung läuft, während dein Xine XV unterstützt?

Zitat

Es gab hier mal die Idee, Xine als alternativen Player zu mplayer an den Start zubringen. Keine Ahnung ob sich da irgendwas getan hat.

Dazu müßte xine erstens über die DVB-Karte ausgeben können, was er m.E. nach nicht kann (nur davon lesen) und zweitens müßte xine ähnlich wie der Mplayer eine Echtzeitkonvertierung von was-auch-immer in mpeg unterstützen, was er m.W. nach auch nicht kann.

Gruß,
Juri

Zitat

Original von nikolanwebde
Das heißt dazu wäre ein zweiter Rechner nötig, der den Film Encodiert?

Nein, man kann den Stream ja auch von 127.0.0.1 lesen
Ein weiteres Problem wäre noch die Bedienung des Ganzen, denn SOLLTE es irgendwann mal so funktionieren, wie ich mir das vorstelle, dann will sicher keiner den vlc per Hand auf der Kommandozeile starten

Dieses Prinzip hätte sogar noch zwei weitere Vorteile:
1. Das (scheinbar nicht so gut laufende) mplayer-cluster Plugin wäre hinfällig, da diese Lösung mit VLC natürlich vollkommen Netzwerktransparent arbeitet
2. Auch die Windows User könnten einen langsamen VDR als Client verwenden und ihren schnellen Win-PC als VLC-Server verwenden (scheinbar ist die Nachfrage nach Win. Serverlösungen ja da -> http://www.vdr-portal.de/board/thread.php?threadid=15254&sid= und http://www.vdr-portal.de/board/thread.php?threadid=11193&sid=)

Evtl. könnte man sich wegen der Bedienung was vom Linux auf der dBox2 Projekt abschauen, die haben das wohl über das Web-Interface vom VLC gelöst...
Aber ich hänge mich schon wieder an Details auf, erst mal sollte das überhaupt funktionieren

Zitat

2. wie sieht es bei vob Files aus

Bei DVDs mit MPlayer über die DVB Karte hatte ich noch kein Problem. Habe aber auch noch nicht SO viele DVDs getestet.

Zitat

3. und mpeg2 Files ..

Ich habe es bisher nur mal mit VCDs und SVCDs getestet und die hatten auch keine Probleme. Aber auch hier habe ich noch nicht direkt viel getestet. Ich habe (fast) alles als MPEG4 (DivX oder XviD) vorliegen.

Es ist wohl wirklich "nur" alles davon betroffen, das in Echtzeit transcodiert werden muss.
Aber ob jetzt DivX und XviD einen Unterschied macht, habe ich noch nie probiert...

Zitat

Meines Erachtens ist es ein internes MPlayer-Problem und kein Transferproblem, denn dieses Problem tritt genauso auf, wenn du den MPlayer ohne DVB-Treiber kompiliert hast - er also in eine Datei schreibt und nicht auf die Karte. Eine auf diese Art erzeugte MPEG-Datei hat an den gleichen Stellen Ruckler, obwohl die DVB-Karte garnicht ins Spiel kommt.

Das ist interessant... Also liegt es doch (wie ich mir schon gedacht hatte) irgendwo am MPEG1 Encoder...

Könntest du bitte mal versuchen, ob die Ruckler auch auftreten, wenn man den MPlayer mit einem reinen MPEG2 Stream füttert und den auf die Platte schreiben lässt? Wenn ja, könnten wir VLC wohl gleich vergessen...

Zitat

Original von jha
Kann ich nicht bestätigen. Die problematischen Filme laufen auf meinem Laptop (P3 850MHz) einwandfrei, wenn mit mplayer abgespielt. Kann es sein, daß dein mplayer ohne XV-Unterstützung läuft, während dein Xine XV unterstützt?

Ist beides def. mit XV - Unterstützung

Zitat

Dazu müßte xine erstens über die DVB-Karte ausgeben können, was er m.E. nach nicht kann (nur davon lesen) und zweitens müßte xine ähnlich wie der Mplayer eine Echtzeitkonvertierung von was-auch-immer in mpeg unterstützen, was er m.W. nach auch nicht kann.
Gruß,
Juri

Wie gesagt, es war eine Idee von jemanden. Das Xine das im Moment noch nicht kann ist mir bewusst, aber vielleicht wird es ja noch was.
Gruss,
Obelix

Original von schMA

Zitat

Könntest du bitte mal versuchen, ob die Ruckler auch auftreten, wenn man den MPlayer mit einem reinen MPEG2 Stream füttert und den auf die Platte schreiben lässt? Wenn ja, könnten wir VLC wohl gleich vergessen...

Sollte besser mal jeder für sich selber testen: LAVC auf 9000 setzen, MPEG_DIRECT auf false und dann alle MPEGs, die man so hat - vorzugsweise VOBs und SVCD-Images -, abspielen.
Je mehr Leute das probieren, desto aussagekräftiger ist es.

Gruß,
Juri

Ich bring mich jetzt auch mal ein weil ich bei manchen DivX die gleichen Probleme habe.

Bitrate bis auf 500 (!) runtergeschraubt, hat nix gebracht.

Dann die Debugausgabe von Plugin angeschaut, die Zeile wie mplayer aufgerufen wird genommen und per Hand ausgeführt, ohne dass VDR im Hintergrund gelaufen ist, und siehe da: es geht SUPERGUT, sogar mit sehr hohen Bitraten (9000).

Jetzt versteh ich gar nix mehr, kann sich da einer nen Reim drauf machen?

Edit:

Ich hab spasseshalber auch mal slave abgeschaltet und den VDR mit "nice -19 vdr" gestartet - keine Änderung...
Woran kann's noch liegen?

Zitat

Original von jha
LAVC auf 9000 setzen, MPEG_DIRECT auf false

Aber dann benütze ich ja wieder den libavcodec mpeg1 encoder, den möchte ich eigentlich durch VLC genau umgehen...
Ich könnte das vielleicht mit einer VDR-Aufnahme versuchen, die ich vorher durch PVAStrumento gejagt habe, wäre dann ja quasi ein MPEG2 Stream mit der richtigen Auflösung usw, oder?

Zitat

Original von Thomas
Dann die Debugausgabe von Plugin angeschaut, die Zeile wie mplayer aufgerufen wird genommen und per Hand ausgeführt, ohne dass VDR im Hintergrund gelaufen ist, und siehe da: es geht SUPERGUT, sogar mit sehr hohen Bitraten (9000).

Jetzt versteh ich gar nix mehr, kann sich da einer nen Reim drauf machen?

Nein aber ich werde das wohl auch mal versuchen, ich bin mir aber relativ sicher, dass ich das (wenn auch schon vor etwas längerer Zeit) schon mal versucht hätte... (leider) ohne Erfolg... aber Versuch macht bekanntlich ja klug (hoffentlich)

Original von schMA

Zitat

Original von jha

Aber dann benütze ich ja wieder den libavcodec mpeg1 encoder, [...]

Genau darum ging's.

[ ] Du hast die vorangegangenen Postings gelesen und verstanden
[x] Du hast die vorangegangenen Postings nicht gelesen oder nicht verstanden

SCNR

Zitat

Ich könnte das vielleicht mit einer VDR-Aufnahme versuchen, die ich vorher durch PVAStrumento gejagt habe, wäre dann ja quasi ein MPEG2 Stream mit der richtigen Auflösung usw, oder?

Die *.vdr-Dateien sind auch ohne Konvertierung MPEG2 Streams. Damit kann man auch testen, ob der libavcodec auch mit anderen decodierten Videos Probleme hat.

Zitat

Original von Thomas
Dann die Debugausgabe von Plugin angeschaut, die Zeile wie mplayer aufgerufen wird genommen und per Hand ausgeführt, ohne dass VDR im Hintergrund gelaufen ist, und siehe da: es geht SUPERGUT, sogar mit sehr hohen Bitraten (9000).

Jetzt versteh ich gar nix mehr, kann sich da einer nen Reim drauf machen?

Nein, und ich bin auch zu einem anderem Ergebnis gekommen - genau auf diese Weise bin ich zu 5000 gekommen.
Vielleicht sollten wir mal edk2-Links tauschen, damit wir über die gleichen Videos reden...

Gruß,
Juri

Zitat

Original von jha
Vielleicht sollten wir mal edk2-Links tauschen, damit wir über die gleichen Videos reden...

Du hast PN

Zitat

Original von Thomas
Jetzt versteh ich gar nix mehr, kann sich da einer nen Reim drauf machen?

dito

Hallo,

da ich das selbe Problem habe mische ich mich einfach mal in die Diskussion ein.
Auf meinen System (Celeron 1.7GHz) liegt die Ursache scheinbar nicht an dem mplayer oder lavc. Wenn ich ein AVI hier im Slave-Modus abspiele verbraucht der VDR die meiste Rechenzeit.

>top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command
9732 root 25 0 9900 9896 2524 R 60.7 2.1 0:05.09 vdr
9725 root 16 0 11584 11m 6536 R 38.3 2.4 0:03.12 mplayer

Im Traditionell-Modus

>top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command
10107 root 15 0 11388 11m 6336 R 42.1 2.4 0:02.09 mplayer
9156 root 15 0 9964 9960 2556 R 0.7 2.1 0:21.92 vdr

läuft aber alles ohne Ruckler.

Erst wenn der VDR den Mplayer steuert zieht er über die Hälfte der Rechenzeit ab und für die Codierung/Decodierung bleibt nicht mehr genug. Außerdem wird die meiste Rechenzeit im Sys- und nicht im User-Modus verbraucht.

Und zum Schluß die Preisfrage: Sieht das bei euch auch so aus oder habe ich einen besonderst vermurksten Rechner?

mfg. Nibbana

Zitat

Original von nibbana
Und zum Schluß die Preisfrage: Sieht das bei euch auch so aus oder habe ich einen besonderst vermurksten Rechner?

Ohne Slavemode hab ich das auch schon versucht, daran hats aber nicht gelegen.
Aber Du hast schon Recht, der einzige Unterschied ist tatsächlich, dass der MPlayer vom VDR gestartet wurde und ggfs Pipes aufgemacht werden oder was weiss ich. Ich hab zwar schon mal in die Sourcen geschaut, konnte aber so auf Anhieb nix verdächtiges finden....

Ich habe jetzt auch mal einen Blick in die Quellen riskiert. In der Datei player-mplayer.c gibt es eine Funtion cMPlayerPlayer::Action. Darin befindet sich eine Schleife

bool force=true, slavePatch=false, trustedTotal=false, playBack=false;
while(run) {
// sleep(1);
if(playMode==pmPlay && playBack) {

und hier wird die Rechenzeit verbraten. Mit dem sleep-Befehl kann man die Abarbeitung kurz unterbrechen. Habe ich mal kurz angetestet. Jetzt läuft das AVI flüssig. Die Schleife müßte man mal genauer untersuchen. Aber nicht mehr heute Abend.

mfg. Nibbana

Ich wäre überglücklich wenn es gelingt avi's flüssig in guter Quali abzuspielen (ca. 9000) .
Bisher musste ich dauernd einen WinPC anschliessen .

Super , die Sonne scheint endlich aufzugehen .

Gruss und viel Erfolg

Also bei mir ist es mit diesem sleep(1) noch viel viel schlimmer!

Es muss also wohl irgendwie in dieser Schleife sein.

Ich hatte eigentlich gedacht, der mplayer spielt und VDR wertet nur die Ausgabe des Slavemodus aus - aber das da so viel Rechenzeit dabei verbraten wird?

*wunder*

Tja, was auch immer ihr da macht, ich kann das hier auf meinem Gentoo-System auf 'nem 2.4er P4 nicht nachvollziehen. Egal ob ich den Slavemode oder den traditionellen Mode benutze, mein MPlayer bleibt (bei dem gewählten Video) bei ca. 40 % CPU-Last während der VDR bei beiden Modi zu vernachlässigen ist.

Auch daß das direkte Abspielen auf der Kommandozeile plötzlich mit LAVC-Werten bis zu 9000 problemlos gehen soll, kann ich hier nicht nachvollziehen.

Gruß,
Juri

Habe das selbe Problem mit einem DivX Film. Wenn ich ihn mit dem Vdr aufrufe(Traditionel, Slave: egal) ruckelt es schon stark am Anfang, rufe ich ihn jedoch aus der Shell über die mplayer.sh auf läuft alles perfekt!
Würde gerne weiter testen, wenn mehr Infos benötigt werden, einfach bescheid geben!

Wie es scheint gibt es verschiedene Ursachen für des selbe Symptom.

Mit dem sleep läuft jetzt fast alles perfekt. Nur an einigen Stellen gibt es noch kurze Hänger. Das scheint an der hohen Bitrate im Video zu liegen. Ich codiere meist in xvid+ogg+mkv mit Spitzenwerten von bis 15 MBit/s. Von diesen Stellen abgesehen habe ich auch bei lavc=9000 keine Probleme mehr.

Das eigentliche Problem ist hier der poll-Befehl. Der Aufruf sollte erst dann zurückkehren wenn Daten in der Pipe liegen oder der Timeout überschritten wird. Der Befehl wird aber sofort beendet und das anschließende read liefert 0 Bytes. Damit ist poll aber wirkungslos und der VDR gibt nie die CPU ab. Durch die Einführung von sleep oder usleep simuliere ich deshalb den Timeout.

Warum sich poll so merkwürdig verhält ist mir aber ein Rätsel. Auch eine Austausch gegen select bringt keine Änderung.

Hier mal meine Programmversionen falls noch jemand eine Idee hat:
SuSE 8.2, vdr-1.2.6+Komplettpatch F, vdr-mp3-0.8.3, mplayer CVS vom 10.2.2004

mfg. Nibbana

Zitat

Original von jha
Original von schMA

Genau darum ging's.

[ ] Du hast die vorangegangenen Postings gelesen und verstanden
[x] Du hast die vorangegangenen Postings nicht gelesen oder nicht verstanden

Sowohl als auch
Aber ich glaube, wir beide haben unterschiedliche Dinge vor: du willst aus dem libavcodec das Maximum rausholen bzw. den Fehler suchen. Ich habe mich damit abgefunden, dass das Problem einfach an der Implementierung des libavcodec im mplayer liegt und suche deshalb eine Alternative.

Zitat

Original von jha
Auch daß das direkte Abspielen auf der Kommandozeile plötzlich mit LAVC-Werten bis zu 9000 problemlos gehen soll, kann ich hier nicht nachvollziehen.

Ich muss dir zustimmen, auch bei mir macht es überhaupt keinen Unterschied, ob das mplayer.sh Script nun per Hand oder vom mplayer Plugin gestartet wird. CPU Belastung des mplayer Prozesses liegt so und so immer bei rund 40%.

Mir ist aber eine Sache aufgefallen:
Durch Klaus' experimentellen UPT Patch (welcher scheinbar auch seinen Weg in den KomplettPatch gefunden hat (korrigiert mich, wenn ich falsch liege)) wartet VDR, bis das Frontend beim Tunen einen Lock zurückmeldet. Allerdings hat das auf meinem 2-Karten-System die Auswirkung, dass während ich einen Film über mplayer ansehen möche, auf der zweiten Karte der EPG Scan einsetzt und scheinbar das Warten auf den Lock des Frontends irgendwie auch seinen Einfluss auf den mplayer hat -> das abgespielte Video stockt jede Minute mal für die eine oder andere Sekunde.
Aber da der Patch laut Klaus auch nur ein quick&dirty hack ist, schalte ich zum Ansehen eines Films einfach den EPG Scan ab und gut ist