[ANNOUNCE] mplay.sh 0.5.3 - Alternative zu mplayer.sh

slime · 19. Mai 2007

Zitat

Original von fen
in letzter zeit fällt mir auf, dass zeitweise der ton asynchron ist und nach einer weile wieder synchron wird und dann wieder irendwann asynchron - sowas mit mplay.sh schon mal jemand aufgefallen? bei mplayer.sh hatte ich das nicht....

fen.

habe ich auch bei fast allen videos. ich hab von startrek DS9 die ganze 3tte steffal auf divx, und es ist bei allen folgen (ca. 45min lang) so, das nach 30min auch das bild stehenbleibt. drücke ich dann auf pause, kommt noch ca. 3sec ton (=asyncron), danach wieder play und es passt alles.
durch öfteres play-pause drücken lässt sich das ganze (vor allem die asyncronität) quasi umgehen. ist net hübsch, aber klappt.

zum debuggen hatte ich leider noch keine zeit. aber irgendwann werde ich mir das auch mal ansehen.

NeverWise · 20. Mai 2007

Den Effekt habe ich auch manchmal, hatte ihn aber auch schon mit dem 'mplayer.sh'. Lustigerweise nie so direkt und deutlich, wenn ich den Spaß direkt von Kommandozeile und ohne laufenden VDR starte. Hab's bisher immer auf meine Prozessorleistung geschoben (Duron 1,3GHz), obwohl der dafür theoretisch ausreichend sein sollte. Das Cpumon-Plugin meint auch tatsächlich, dass mein System nicht am Anschlag arbeitet.

Ich hatte es, glaube ich, schon erwähnt, die Wiedergabe auf meinem VDR läuft irgendwie stabiler, wenn ich vorher auf einen Kanal schalte, der kein Bild bringt.
Evt. gibt es auch einen Unterschied, ob man die Audioausgabe ebenfalls über die FF-Karte macht oder per Soundkarte, die Kontrolle der Synchronität geht dem MPlayer dann beizeiten verloren (weil er ja nur die Ausgabe synchron halten kann, nicht jedoch das, was die Treiber und die Hardware daraus machen).

Btw. läuft in bewußtem Fall eigentlich der Ton oder das Bild voraus, eigentlich das Bild, oder wie?

NeverWise · 24. Mai 2007

Ich hab' mal 'n bißchen rumprobiert... In der 'mplayrc' in den allgemeinen Optionen (MPLAY_GLOBAL) steht standardmäßig ein '-framedrop'. Ich dachte, dass wäre eine gute Idee gewesen und in der Tat führt es ganz offensichtlich zu weniger Rucklern. ABER: Die Synchronität zwischen Video und Audio scheint dabei auf der Strecke zu bleiben.

Ich vermute, dass der MPlayer bei einem Framedrop nicht nur einfach den fraglichen Frame nicht berechnet und die Zeit abwartet, sondern schnurstracks die Berechnung und Ausgabe des nächsten Frames angeht, so dass zu einem bestimmten Zeitpunkt t zwar das Audioframe für t gespielt wird, bei Video aber vielleicht der Frame von t + x.

So, ohne '-framedrop' scheint das nach meinen ersten Versuchen nicht bzw. deutliche weniger aufzutreten ... dafür ruckelt's jetzt wieder.

Der Ansatzpunkt dazu ist dann LAVC, also die Datenrate, mit der der MPEG-codierte Datenstrom an die FF-Karte geht. Dabei scheint nicht die Prozessorleistung der Flaschenhals zu sein (mein 1,3-GHz-Duron hat noch gut Luft), sondern, wie an anderer Stelle hier im Forum bereits beschrieben, die Transferrate auf dem PCI-Bus. Hier hilft dann nur, den LAVC-Wert so weit nach unten zu setzen, bis es läuft.

Werte unter 4000 fangen allerdings langsam an, unansehnlich zu werden. Auf meinem System ist 4000 - 4200 der Kompromiss, der ein vernünftiges Bild und kaum Ruckler liefert.

(Tip: Falls verfügbar zum Testen: Die ersten 2,5 Minuten von 'Matrix-Reloaded' und/oder 'Cars' in 720 x X Auflösung (wegen der sich schnell und erratisch ändernden Bildinhalte)... Wenn das ruckelfrei läuft, tun's die anderen wahrscheinlich auch.

So, wenn das jetzt noch jemand verifizieren könnte ...

slime · 24. Mai 2007

hi,
ich wollte gerade testen, allerdings habe ich framedrop schon die ganze zeit entfernt auch mein lavc wert steht auf 4600. ich drehe mal runter auf 3000 und teste mal. dann gibt es auch das feedback, in welche richtung das bei mir verschoben ist...

slime · 28. Mai 2007

hi,
folgende dinge sind mir aufgefallen: mein mplayer bringt die meldung:

Code

Compiler did not align stack variables. Libavcodec has been miscompiled
and may be very slow or crash. This is not a bug in libavcodec,
but in the compiler. Do not report crashes to FFmpeg developers.

test mit laufendem vdr; lavc=3000:
[1.play-pause] das bild bleibt stehen, ton läuft weiter. nach einem weiteren play-pause läuft das bild wieder weiter.
[2.bild bleibt stehen] nach ca. 15min bleibt das bild stehen. play-pause behebt das ganze wieder. in diesem fall reicht das ganze ein mal.
[3.bild-ton unsync] bei mir läuft das bild vor. d.h., wenn ich pause drücke, stoppt der ton sofort, vom bild kommt dann noch etwas. teilweise bis zu 3sec bild!

ich werde dies ganzen effekte mal auf den mplayer(also die compilierte version von debian-multimedia) selbst schieben.
als nächtes werde ich mal versuchen, einen eigenen mplayer an den start zu bekommen, der diese meldung nicht mehr bringt.

Darknark · 15. Juni 2007

NeverWise

wie wärs hier mit für die music.conf

MPLAY_AF="center=4,sub=120:5,channels=6:6:0:0:1:1:0:2:1:3:4:4:5:5,equalizer=0:0:0:0:0:0:0:0:0:0,volume=-12:1"

bezüglich center=4, channels....

NeverWise · 23. Juni 2007

Hm, hab grad' meinen 'mplayer' nicht dabei... Die 'center'-Option erzeugt einen Mittenkanal, nehme ich an.

Keine schlechte Idee, dann wäre der auch versorgt. Aber nicht, dass der Center dann "hervorsticht" oder so?
Ich hör' mir's zuhause mal an.

slime: Zum Thema Audio/Video-Sync hab' ich noch was in der MPlayer-Dokumentation gefunden. Die schieben die Schuld dem Soundkartentreiber in die Schuhe und meinen, man müsse mal die Option '-autosync' probieren. Das mache ich bei Gelegenheit mal und gucke, was passiert.

m0190 · 30. Juni 2007

Zitat

Original von NeverWise
mplay.sh-0.5.3

Cox and *
You don't really expect me to understand your little table?
Okay, okay, let's try it with 0.5.3. My own TV is switchable to a 16/9 simulation. In this mode, (only) the vertical resolution is reduced and the calculated values from 'mplay.sh' does (of course) not fit. With the new parameter 'MPLAY_TV' set to "7/5" (which affects the vertical resolution), it seems to be fine on my TV. I suppose, a real 16/9 TV tries to scale the horizontal resolution to it's full screen and the new parameter should scale vertical right. "7/5" is not really absolute exactly, but some pixels up or down should make no effect.

It's now up to you to check this first try at a real 16/9 TV.

Ich habe hier ein Video mit der Auflösung 640x480 ohne zusätzlich angegebenen Aspect Ratio. Das Verhältnis ist 1:1 , also 4:3.
Leider ist auf meinem 16:9 TV das "4:3" berechnete Bild zu breit.

m0190 · 1. Juli 2007

Hier nochmal die Logausgabe zu meinem Problem:

Code

AVI file format detected.
VIDEO:  [DX50]  640x480  24bpp  25.000 fps  1030.5 kbps (125.8 kbyte/s)
Clip info:
 Software: VirtualDubMod 1.5.10.2 (build 2540/release)
 Opening /dev/dvb/adapter0/video0+audio0
 Opening video filter: [lavc=4600]
 Opening video filter: [expand w=720 h=576 osd=1]
 Expand: 720 x 576, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
 Opening video filter: [scale w=548 h=576]
 ==========================================================================
 Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
 Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
 ==========================================================================
 ==========================================================================
 Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
 AUDIO: 48000 Hz, 2 ch, s16le, 128.0 kbit/8.33% (ratio: 16000->192000)
 Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
 ==========================================================================
 Opening /dev/dvb/adapter0/audio0
 AO: [mpegpes] 48000Hz 2ch s16le (2 bytes per sample)
 PLAYBACK STARTED
 mplayer: volume=100 mpVolume=100 mpMute=0
 mplayer: slave cmd: get_time_length
 mplayer: slave cmd: get_percent_pos
 VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
 VDec: using Planar YV12 as output csp (no 0)
 Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
 SwScaler: reducing / aligning filtersize 6 -> 8
 SwScaler: reducing / aligning filtersize 6 -> 8
 SwScaler: reducing / aligning filtersize 5 -> 4
 SwScaler: reducing / aligning filtersize 5 -> 4
 
 SwScaler: BICUBIC scaler, from yuv420p to yuv420p using MMX2
 SwScaler: using 8-tap MMX scaler for horizontal luminance scaling
 SwScaler: using 8-tap MMX scaler for horizontal chrominance scaling
 SwScaler: using n-tap MMX scaler for vertical scaling (YV12 like)
 SwScaler: 640x480 -> 548x576
 [mpeg1video @ 0x87ff79c]removing common factors from framerate
 VO: [mpegpes] 720x576 => 1009x576 Mpeg PES 
 mplayer: slave cmd: get_time_length
 mplayer: slave cmd: get_percent_pos
 mplayer: slave cmd: get_percent_pos
 mplayer: slave cmd: get_percent_pos

Alles anzeigen

NeverWise · 1. Juli 2007

Das ist die Ausgabe vom 'MPlayer'. Kann ich das Log vom 'mplay.sh' selbst noch sehen (wegen der Auflösungsumrechnerei)?

NeverWise · 4. Juli 2007

Darknark: Ich hab' das mit dem Center in der 'music.conf' getestet, ist soooo schlecht nicht ... wenn ich irgendwann zum Updaten komme, biete ich es mit an, danke

slime: Ich hab' in 'MPLAY_GLOBAL' in der 'mplayrc' mal ein "-autosync 30" dazugesetzt und ich meine bei meinen ersten Versuchen eine deutliche Verbesserung festgestellt zu haben (Audio-Video-Sync). Ich hab' aber auch festgestellt, dass mein 1,3GHz Duron schlicht und ergreifend zu lahm ist. Die meisten Szenen laufen flüssig, aber wenn ich alles an Auflösung rausholen will, ist er am Anschlag. (muss ich irgendwann demnächst ändern).

SurfaceCleanerZ · 29. Juli 2007

Hallo,

ich habe das Problem mit den NTSC Videos gelöst!

s. dort:
MPlayer zittert beim Abspielen

Könntest du das noch einbauen?

Nebenbei: Ein Ersetzen der /usr/share/mplayer (Ist das benutzte mplayer.sh Skript von Juri bei c't VDR) mit mplay.sh (Pfad Zeile 16 angepasst und die Dateien auch dort hin gepackt) führt zu einem nicht mehr startenden MPLayer-Plugin.

mfG,
Stefan

slime · 29. Juli 2007

hi,
also das autosync klappt ziemlich gut, zumindest im ersten test.
ich hätte noch nen vorschlag, geklaut aus dem vdr-wiki.

Code

MPLAY_VOUT="mpegpes:card=$(($(find /dev/dvb | grep video0 | cut -c17)+1))"

das sorgt dafür, das automatisch auf der korrekten dvb-karte ausgegeben wird. für audio kann man das dann gleichartig einfügen.

jha · 30. Juli 2007

Hmm, sollte eher $(($(find /dev/dvb | grep video0 | head -n 1| cut -c17)+1)) sein, denn bei mehr als einer FF-Karte schlägt das Orginal fehl. Und da komme ich auch gleich zum nächsten Problem:
Es sollte abschaltbar sein bzw. es sollte die Möglichkeit geben, diese Automatik mit einer Einstellung zu übergehen, denn bei Systemen mit mehr als einer FF-Karte, bei der eine andere als die erste Karte zur Ausgabe benutzt wird, hätte man keine Freude an der Automatik.

Gruß,
Juri

viking · 30. Juli 2007

Hallo,

in der setup.conf von vdr ist doch eingestellt welche karte die erste ist. Kann man das nicht nutzen ?

Gruß
Viking

SurfaceCleanerZ · 30. Juli 2007

Hallo,

wie mir am Sa. gesagt wurde interessiert die neuen VDR-Versionen die in der setup.conf Angabe nur noch als Anfangswert, wenn das keine FF ist, ändert er das Device mittlerweile automatisch beim Start in die FF um. Diese Automatik könnte man wahrscheinlich aber schon irgendwie nutzen. Dies Problem trat am Sa. auf mindestens 3 VDRs auf (also dass die FF verschiedene Nr. bei jedem Boot hat...). Da müsste man mal Klaus fragen, würde ich sagen! Der kann sicher eine Möglichkeit sagen oder zur Not schaffen, wie man an die herausgefundene Nr. herankommt.

Viele neue Ideen, wenn ich etwas testen soll, oder Videoschnipsel bereitstellen soll für das23,976fps Problem, oder irgendetwas anderes sagt es mir!

Mit Skripten komm ich noch nicht klar, sonst hätte ich schon was versucht...

Gibt es irgendwo eine gute Anleitung für Shellskripte? Ich kenn mich nur etwas mit Dos .bat aus.

mfG,
Stefan

slime · 30. Juli 2007

Zitat

Original von viking
in der setup.conf von vdr ist doch eingestellt welche karte die erste ist. Kann man das nicht nutzen ?

jein. wird wahrscheinlich schon gehen, aber was ist z.B. mit leuten, die softdevice oder ähnliches installiert haben. dann klappt das mit der device-nummer von vdr wohl nicht mehr. das ganze ist aber nicht wirklich problematisch, da solche user gewöhnlich auch nicht auf einer FF das video ausgeben.

NeverWise · 30. Juli 2007

Hallo Leutz,

viele gute Anregungen ... ich guck' mir alles an ... irgendwann ...

Nein, sorry, wirklich, ich tu's, es wird aber leider nichts in der ganz nahen Zukunft.

Thema NTSC: interessant, muss ich mich nochmal reindenken

Thema autosync Option: Bringt leider nicht den letzten Rest an Feude, ich hab' letztens erst was geguckt, was wieder den Effekt hatte, wenn auch nicht so stark. Lustigerweise mußte ich den ganzen Rechner nochmal neu starten und gucke, danach lief der Krempel.
(hatte ich bereits erwähnt, dass mir der MPlayer zunehmend suspekt wird)

Danke nochmal für eure Testerei...

thorsten.gehrig · 31. Juli 2007

Hi,
...ohne dass ich diesen thread komplett durchgelesen habe...
Kann man mit diesem Script auch Internetradiostreams abspielen - und funktionieren damit die Streams aus diesem Thread:
Problem mit Radio-Streams bem MP3/Mplayer-plugin

Danke im vorraus,
Thorsten

NeverWise · 3. August 2007

Da habe ich schwere Zeifel.

Nee, damit kann das Ding nix anfangen, ist irgendwie gar nicht dafür eingerichtet.

[ANNOUNCE] mplay.sh 0.5.3 - Alternative zu mplayer.sh

Jetzt mitmachen!

Teilen