ruckelndes Divx

Hallo Juri,

Zitat

Vielleicht gibt es aber auch Schwierigkeiten mit der PCI-Bus-Bandbreite.

ich habe hier auch ruckelnde Videos beim MPlayer-Plugin. Allerdings keine DivX-Videos sondern noch nicht gebrannte VCD- und SVCD-bins. Sogar VDR-Files ruckeln mit dem MPLayer-Plugin. Die Wiedergabe der VDR-Files durch den VDR funktioniert hingegen reibungslos.
Ich habe hier ein i845GE-System. Probleme in der PCI-Performance, wie sie die VIA-Systeme haben, sind bei einem solchen System unbekannt. Die CPU-Auslastung liegt bei 25-40% (2GHz Celeron).
Wenn es ein PCI-Problem sein sollte, muss es m.E. in der PCI-Implementierung der DVB-Karte liegen.

Oder aber die Implementierung der mpegpes-Anbindung im MPlayer ist nicht optimal, was ich fuer am wahrscheinlichsten halte, denn dieselben gebrannten VCD- und SVCD-bins werden mit dem (S)VCD-Plugin voellig fluessig wiedergegeben.

Mirko76

Zitat

Ich habe jetzt ein Mpg2-Video encodet in 480*576, wieso scaliert es der Mplayer auf 768*921?

Tut er das? Oder meint er nur, dass die Pixel bei dieser Aufloesung quadratisch seien?

Gruesse
Markus

Hallo Mark,

hast du mal ausprobiert, die Bitrate mit VOP="lavc=5000" zu begrenzen? Denn, selbst wenn du ein VCD-Image abspielst, wird daraus ein Video in voller PAL-Auflösung (oder NTSC) generiert. Hier kann es dann wieder zu Problemen mit der Bandbreite kommen.

Gruß,
Juri

Hallo Juri,

Zitat

hast du mal ausprobiert, die Bitrate mit VOP="lavc=5000" zu begrenzen?

nein, noch nicht. Ich habe eine andere Option verwendet, um die Qualität der Ausgabe herabzusetzen. Welche Option es ist, kann ich von hier aus (Büro) nicht sagen. Je nach Video-Auflösung (384x288 (vdub-Aufnahmen), 352x288 (VCD), *x576 (VDR-Aufnahmen, SVCD)) mußte ich diese Option mehr oder weniger stark "verschlechtern" lassen (Werte zwischen 3 und 8 ).

Um zu Verifizieren, ob eine Option das Ruckeln beseitigt, habe ich mein mplayer.sh von Anfang an ohne VDR gestartet. Geht schneller als per Fernbedienung im VDR. Ich hatte früher schon mal wegen dem ruckelnden MPlayer-Plugin daran rumprobiert, aber wegen der wenigen Videos es dann gelassen.

Komisch ist nur, daß das MPlayer-Plugin auf einmal nicht mehr ruckelt, wenn ich diese qualitätsverschlechternde Option wieder weglasse (ich wollte es nochmal Ruckeln sehen, ruckelt aber nicht mehr, weder VCD, SVCD noch VDR-Aufnahmen). Jetzt kann ich zusehen, daß ich das Ruckeln wieder herbekomme, um der Ursache auf die Spur zu kommen.

Zitat

Denn, selbst wenn du ein VCD-Image abspielst, wird daraus ein Video in voller PAL-Auflösung (oder NTSC) generiert. Hier kann es dann wieder zu Problemen mit der Bandbreite kommen.

Nur daß sie mit dem (S)VCD-Plugin von CD abgespielt _nicht_ ruckeln.

Grüße
Markus

Zitat

Originally posted by mark2

Nur daß sie mit dem (S)VCD-Plugin von CD abgespielt _nicht_ ruckeln.

Dort werden die (S)VCDs ja auch nicht hochskaliert!

Gruß,
Juri

Hallo,

wenn ich das richtig sehe dann ist es die lösung bei ruckeln oft lavc anzupassen. Klappt bei mir auch

Ich habe mal ein vorschlag auf der ML gepostst wie man aus meiner sicht das recht einfach lösen kann. Damit kan man evt. auch andere ansätze ausprobieren ohne zu tastatur zu greifen

Mein vorschlag ist das man das eine art Qualitätsauswahl im mplayer plugin / mplayer.sh einbaut. siehe (leider nur in Englisch) :

http://www.linuxtv.org/mailing…003/04-2003/msg01326.html

Wenn es gewünscht wird kann ichs übersetzen.

Was hällt ihr davon ?

Gruß
Viking

Hi,

ich weiß ja nicht. Das kann man eigentlich nicht unbedingt mit einer handvoll Einträge abfeiern. Den optimalen Wert sollte jeder für sein System selber rausfinden. Ob da die Auswahlmöglichkeiten reichen/helfen...

Letztendlich ist es mir egal. Wenn Stefan diese Möglichkeit ins Plugin einbaut, dann werde ich sofort mit dem Skript nachziehen.

Gruß,
Juri

Hallo,

bin gerade über diesen thread gestolpert:

Da der PCI Bus eine Bandbreite von 132 Megabyte / s hat, sollten die Videostreams selbst bei 15000 MBit = 1,875 Megabyte Bandbreite genug haben. Ich vermute den Engpaß also nicht auf dem PCI-Bus

Ciao
Piet

Hast du einen Link?

Ich habe diese Theorie immer etwas bezweifelt, es kam aber mal so auf der mplayer-dvb ML durch und Arpi hatte es nicht angezweifelt, sondern kam mit dem lavc=x000 Workaround. Ich muß mir diese Mails nochmals vornehmen.

Die Hauptsache ist aber, daß es den meisten hilft.

Gruß,
Juri

zum thema divx auflösugen mal ein beitrag (vdr bezogen):

bei 480x360 ist eine sehr niedrige bitrate bei (dank scale und mpeg1 trascodierung) akzeptabler bildqualität möglich,
wer jetzt noch die restlichen schwarzen balken wegschneidet erhält 480x3xx (mplayer -vop crodetect)

bei 512x576 ist eigentlich bereits fast ideale qualität erreicht, und hierbei sollte man keinesfalls noch schwarze balken schneiden, ebenso wenig bei 720x576, da dann mplayer beim abspielen mehr zeit zum hochscalieren benötigt als wenn die Y-achse direkt bei 576 bleibt und transcodiert wird.

bei der X auflösung ist auf 2 dinge zu achten:
1. bei machen dvb streams (Premiere,Sat1,...) ist X eh nur 480, also nicht pauschal auf 720 scalieren lassen(oft auch 704)
2. immer eine der von der dvb karte direkt unterstützte auslösung nehmen:
352 , 384, 480, 512, 544 ,628, 704, 720 (und noch einige mehr, abwer besser ist sich auf 480,512 und 720 zu beschränken, da nicht alle mplayer versionen alle zwischenauflösungen können)

und wenn nicht mit xvid sondern ffmpeg encodiert wird, unbedingt -vop lavdeint mit benutzen, ansonsten gibt es schneller block-bildung in aktion und rot lastigen szenen

die standart verögerung von audio und video (wenn mit mplayer transcodiert) ist audiodelay=+0.1, also beim encodieren mit angeben( mencoder -audio-delay 0.1 )

genauso kann man per mplayer -identify <inputfile> das seitenverhältniss abfragen und dann per -aspect 1.7778 (16/9) mit in das mpeg4 avi codiert werden, auch wenn bisher wenige player das unterstützen (mplayer natürlich).

beim abspielen per mplayer kan man per "-autoq 100 -vop pp" ein großteil der (freien ?) cpu last für ffmpeg auto-postprocessing (kantenglättung,u.ä.) benutzt werden. alternativ kann man divx avis mit "-vc xvid," mit dem xvid codec wiedergeben, der mit divx3 und divx5 teils besser zurecht kommt und ein eigebautes postprocessing zu haben scheint...

Gruß MeMeD

P.S.
dazu mache ich demnächst ein richtiges html faq...

viking,

so etwas mit im mplayer-plugin setup einstellen und das durch mplayer.sh auswerten habe ich hier seit 4 monaten im beta betrieb, klappt sehr gut, ich suche noch beta tester.

ich schick dir meinen patch für das mplayer plugin + ne eigene mplayer.sh die das bereits nutzt, für:
lavc, tv-out-aspect, frames/sec, mplayer-synconisierungs-algo, set-speed (für slo-mo :=} ) und so was wie playlisten klappen auch ganz gut

schick ne pm oder email wenn intresse besteht.

gruß MeMeD

p.s.
ich bastele auch an so etwas um vdr zu divx zu konvertieren (nur aus dem osd heraus,mit allen möglichen optionen) da sollte man aber ein bisschen scripten können, am besten auch nen bisschen C

P.P.S.
bei wem klappt das mit dem image plugin, ich will das ohne imagemagic (X11) machen, und die mpg stills die ich mit dem mpegtools erstelle klappen mit der test app vom DVB treiber, aber nicht mit dem image plugin...
(ich schaue z.zt. jpgs per selbst gefrikeltem mplayer.sh slideshow krams, das geht nicht wirklich gut ...)

Hallo Piet,

Zitat

Da der PCI Bus eine Bandbreite von 132 Megabyte / s hat, sollten die Videostreams selbst bei 15000 MBit = 1,875 Megabyte Bandbreite genug haben.

eigendlich schon, aber zwischen der theoretischen Bandbreite und der tatsaechlich erreichbaren Uebertragungsrate liegen einige Huerden, wie die diversen Einstellmoeglichkeiten im Bios (z.B. Latency) und die PCI-Implementierung sowohl im Chipsatz als auch auf der jeweiligen PCI-Karte.
Einige Via-Chipsaetze haben z.B. ein Problem bei sehr schnellen PCI-Geraeten wie UDMA-133-Controllern und USCSI-160-Hostadaptern. Bei diesen kann die Datenrate auf 60MB/s und weniger einbrechen, weil der PCI-Burst aufgrund eines Via-Bugs vorzeitig abgebrochen wird. Die Reinitialisierung des Transfers benoetigt Zeit, was den Overhead erhoeht und damit die tatsaechlich erreichbare Uebertragungsrate senkt.
Ein anderes Beispiel ist das Problem mit einigen Soundblaster-Karten (SB Live 5.1?) in Motherboards mit u.a. Via-Chipsaetzen. Dort kommt es haeufig zu Knacksern im Sound, obwohl der PCI-Bus die Datenrate locker schaffen muesste. Erst durch diverse Bios-Einstellungen ist das Knacksen manchmal zu beseitigen.
Dann kommen noch Chipsatz- und CPU-Treiber fuer das ACPI dazu. Auf meinem Athlon-System (KT7A-Raid) z.B. brach unter Windows XP die Transferrate von und zu Festplatten auf bis zu 3MB/s ein, egal ob SCSI oder IDE. Die Platten sollten bis ueber 70MB/s (Striping) schaffen. Schuld war ein Treiber von Microsoft fuer die CPU (processr.sys), der wohl fuer das Power-Saving der CPU zustaendig ist. Er schaltet m.W. die CPU in einen bestimmten Stromsparmodus, wenn sie idle ist. Zum Aufwachen aus diesem Modus benoetigt die CPU aber mehrere 100 Zyklen. Bei zig-maligem Einschlafen und Aufwecken pro Sekunde sinkt die Leistung des Systems auf das Niveau eines 10 Jahre alten Rechners. Ich habe processr.sys deaktiviert, und die I/O-Leistung der Platten ist nun wieder ok. Als Nebeneffekt liegt die CPU-Temperatur um durchschnittlich 5 Grad hoeher.

Gruesse
Markus

Hallo mark2 !

Wenn wir uns auf den Terminus einigen, daß nicht der PCI-Bus, sondern die schlechte Implementierung
bei einigen Chipsätzen / Steckkarten den Engpaß darstellt, dann gut

IMHO liegen die Probleme bei den Soundkarten allerdings nicht an der Transferrate, sondern an anderen Timingproblemen. Unter Windows ist zum großen Teil die schlampige Programmierung der Treiber (eben wie processr.sys) verantwortlich, wobei ich der Meinung bin, das dieses unter linux durch die vielen eingebauten Workarounds (gerade auch für Chipsatzfehler) deutlich besser gelöst ist.

MfG

Piet

Hallo.
Ich muss das noch mal aufrollen. Ich habe mir einen VDR gebaut 1Ghz Athlon, 256 MB RAM, ASUS A7N266-VM, SuSE 8.2. Den Prozessor hatte ich vorher in meiner Workstation drin. Dort lief er mit 512 MB, GForce 4, Red Hat 7.3 / W2k.

Das ruckeln hatte und habe ich auch auf meiner Workstation. Mittlerweile ein Athlon XP 2400+. Ich habe eben gerade einen älteren DivX Film mit dem VDR angeschaut und der hat hier und da geruckelt - Bild wie auch Ton. Manchmal auch getrennt. Ich habe den Film nun auf meiner Workstation (Red Hat 7.3) angeschaut und er hat mit dem mplayer auch geruckelt (10 bis 20 % Auslastung).

Spiele ich den Film nun mit xine ab, funktioniert alles tadellos. Ich denke es ist ein mplayer problem. Oder ?

Gruß, Obelix

Habt ihr es mal mit einem preemptive low latency kernelpatch von Con Kolivas [1] probiert?

Angeblich bringt es ein richtig flüssiges Bild, wenn man 1000Hz einstellt - Standard sind glaub ich nur 100Hz.
Ich kannte allerdings auch vorher bei meinem 14000Athlon noch kein Bildruckeln...

[1] http://members.optushome.com.au/ckolivas/kernel/

obelix:

Ja, zu dem Ergebnis bin ich mittlerweile auch gekommen:
Es ist ein MPlayer-Problem. Auf meinem neuen VDR-System (P4 2.4GHz) ruckeln manche Videos bei bestimmten Sequenzen gar fürchterlich, obwohl die CPU noch reichlich Luft hat. Andere dagegen, die laut Mplayer eigentlich eine viel höhere Bitrate und Auflösung haben, laufen flüssig.

Es scheint zwei Grenzen zu geben:
Die erste liegt irgendwo bei 8000-10000 (lavc-Wert) und hat offensichtlich mit der DVB-Karte/PCI-Bus zu tun. Diese Grenze erreiche ich z.B. mit nur einem Video.
Die zweite hat vermutlich irgendwas mit Mplayers mpeg1-Encoder oder der Mplayer-internen Verarbeitung zu tun. Wird der lavc-Wert auf gerade noch erträgliche 5000 gesetzt, kommt Mplayer mit dem Encodieren mit und die Sequenzen laufen flüssig.

Vielleicht sollte man die Xine-Geschichte wirklich mehr forcieren.

Thorsten:
Ich glaube nicht, das es mit dem Preemptive Patch besser wird. Ein Versuch wäre es aber trotzdem mal wert...
Wenn ich mal Zeit finde...

Gruß,
Juri

memed: Lont es sich "-autoq 100 -vop pp" mit dem VDR mplayer plugin zu benutzen? Wenn ja wie kann man es in die mplayer.sh.conf eintragen? Mit VOP="lavc=5500 pp" und USERDEF="-quiet -osdlevel 0 -autoq 100" startet mplayer nicht.

Gruß

micmac

Probier's erstmal in der Shell, um den Fehler zu finden.
Ob sich -autoq lohnt, weiß ich auch nicht - käme auf einen Versuch an.

Gruß,
Juri

Zitat

Vielleicht sollte man die Xine-Geschichte wirklich mehr forcieren.

Mit dem lavc Wert werde ich mal experimentieren.
Gruß, Obelix

Hallo.
Ich hatte nun endlich mal Zeit mich wieder mit meinem VDR zu beschäftigen :). Ich habe den lavc auf 5000 gesetzt und es läuft jetzt soweit. Probleme bereiten aber immer noch Filme die mit divX 5.05 codiert wurden. Ich habe mal gelesen, dass die API bei divX 5.05 geändert wurde. mplayer läßt sich bei mir nicht übersetzen, wenn die neuste Version von divX drauf ist.
Gruß, Obelix