[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: StillImage -> DV ( war: ffmpeg: libavformat-cvs.so: cannot open ...)



Am Freitag, 12. August 2005 14:13 schrieb Christian Bodenstedt:

> Wenn ich schreibe "nimm die Pakete aus unstable statt denen von
> Marillat", dann meine ich mit "unstable" das offizielle unstable, also
> Pakete von ftp.debian.org bzw. von einem Mirror. Nicht jedoch meine ich
> Pakete, die Herr Marillat für unstable bereit stellt. Nebenbei bemerkt
> heißt unstable (manchmal) nicht umsonst so ;-)

Ok, da haben meine preferences dazwischen gefunkt. Ich habe mittlerweile 
wieder ein funktionierendes transcode und bin noch am Überlegen, ob ich 
wieder mit  unstable mischen und probieren will.

> Du hast (hattest) also die Marillat-Version von ffmpeg installiert,
> nicht die aus dem offiziellen unstable (?).

Mir war nicht klar, dass es unterschiedliche "transcode unstable" gibt.

> Versions-Mischmasch?

Ja, aber wieder hingebogen. Bis jetzt habe ich noch nichts entdeckt, dass 
nicht funktioniert.

> Um etwas klarzustellen: mit "Übergänge" meinte ich nicht
> Szenenwechsel, sondern die Kanten an denen zwei Photos innerhalb eines
> Videoframes aufeinandertreffen. Also z.B. ab der dritten Sekunde zu
> sehen, wenn die zwei Hälften des Photos von der Blume aufeinander zu
> fahren. Die einzelnen Schritte in der Bewegung sind einfach zu groß
> bzw. der Kontrast am Übergang ist zu hoch. Desshalb wirkt die Bewegung
> ruckelig, die Darstellung _springt_ von einem Bild zum nächsten.

Ok, die Stelle wo die 2 Hälften aufeinander zufahren, sind auch nicht mein 
Hauptproblem.

> > Schau dir den "Schwenk" im Foto an.
>
> Welchen? Ich will hier nicht unnötig mutmaßen und raten, also sei
> bitte etwas präziser. Z.B. indem du mir die Nummer der betroffenen
> Einzelbilder / des ersten Einzelbildes nennst.

Nimm zB den Anfang, da bewegt sich der Delphin rechts unten diagonal nach 
links oben, und diese Bewegung finde ich zB, ruckelt leicht.

> Ja, bei mir ruckelt es auch etwas. Das sieht allerdings so aus, als ob hin
> und wieder ein einzelner Videoframe zu lange angezeigt würde (Könntest du
> bitte "dein" Ruckeln genauer beschreiben?).

Würde ich gerne tun, aber ich weis nicht wie ich beschreiben soll.

> Diese Art von Ruckeln erkläre ich mir durch die recht hohe Auflösung

Gefühlsmäßig habe ich auch schon gedacht, dass mein XP 2700 dafür zu langsam 
sein könnte.

> (Rechenaufwand) und die dadurch resultierende Datenrate. 1024*786 sind
> immerhin fast das Doppelte von 720*576. Da kommt ein Prozess dazwischen,
> der auch noch rechnen möchte (in meinem Fall der Browser, der eine Seite
> nachladen will) und es ruckelt. Ansonsten wirken die "Schwenks" recht
> flüssig in meinen Augen.

Mittlerweile achte ich nur mehr darauf und da sehe ich immer ein Ruckeln.

> Also hab ich mir das Video mal auf "mickrige" DVD-Auflösung
> runterrechnen lassen und siehe da -- die vorher beschriebenen "groben
> Ruckler" sind verschwunden. Vielleicht sind meine Sinne aber auch nicht
> empfindlich genug.

Wie groß ist die Datei? Könnte ich mir die irgendwo runterladen und 
vergleichen? Ich habe keine Ahnung ab welcher Größe Mails geblockt werden, 
aber um die 30MB habe ich zur Zeit in der Mailbox frei. Dein Mail ist also 
willkommen, aber bitte nicht hauen, wenn es bounct, da habe ich wenig 
Einfluss darauf. Ich habe kürzlich 18MB _an_ GMail versandt und das ist nie 
angekommen. An die Exim-Konfiguration meines Providers komme ich 
verständlicherweise nicht ran und dort könnte ähnlich restriktiv konfiguriert 
sein.

> Ja. Und nach dem direkten Vergleich muß ich sagen, dass dein Video bei
> den "Schwenks" ehr flüssiger wirkt als das von deniscarl.com. Aber das
> sind nur Nuancen.

So sehe ich es auch, und ich will ja noch besser werden :-)

> Das empfinde ich aber als "gleichmäßiges Ruckeln", also wird das Video
> anscheinend zumindest richtig dargestellt. Dass Problem ist dann
> warscheinlich ein zu großer Unterschied zwischen den Einzelbildern, weil
> diese einfach zu scharf sind (Szene mit dem Baum oder was das für ein
> Gewächs ist).

Das finde ich eine gute Erklärung, ich empfinde das auch so. Ich dachte schon, 
wenn ich 50fps statt 25fps verwenden würde, müsste es besser werden, aber dann 
bin ich weg von der Norm und somit bringt das nichts. Es könnte aber was 
bringen, wenn die Schwenks kürzer bzw. langsamer werden. Andererseits habe 
ich bei den Übergängen festgestellt, dass es flüssiger aussieht, wenn die 
Veränderungen schneller sind. Ich denke, hier spielt die 
Wahrnehmungspsychologie auch eine Rolle.

> Diese Tatsache sollte man auch nicht unterschätzen. Bei 20cm Abstand vom
> Monitor/Fernseher sieht man einfach viel mehr "Störungen" als ein paar
> Meter entfernt in bequemer Sitzposition auf dem Sofa. Und letztendlich
> will man Videos nicht am Schreibtisch gucken. Also sollte man am
> Schreibtisch auch nicht immer zu kritisch hingucken.

Es geht hier auch um einen theoretischen Ansatz, was man tun muss um es 
grundsätzlich möglichst gut zu machen. Abstriche kann man noch immer 
akzeptieren.

> Auch hier kann ich wieder nur mutmaßen. Desshalb ist es wahrscheinlich
> die einfachste Lösung, du stellst mal einen Teil deiner Ein- und
> Ausgabedateien online und nennst die verwendeten Befehle (evtl. mit
> Ausgaben).

Das ist ein Mischprojekt. Die Originaldateien findest du hier:

http://pinguin.uni.cc/001_test.png
http://pinguin.uni.cc/002_test.png
http://pinguin.uni.cc/003_test.png

Das avi-file wurde unter Win erstellt und da habe ich nur insofern Einfluss, 
dass ich um andere Parameter, Formate, etc. beim Rendern bitte. IMHO sind 
xvid-avi und wmv die interessantesten Formate.

> Wenn du einfach nur 25 Ganzbilder pro Sekunde nimmst und als interlaced
> kodieren lässt, musst du dich natürlich nicht wundern wenn das hinterher
> genauso aussieht, wie wenn es progressive kodiert ist. Dann hättest du
> nämlich nur eine suboptimale Kodierungsform gewählt. Also wenn du nur
> irgendwie sowas machst: ...
>
> | transcode -i jerking_flickering_xvid.avi \
> |           -y ffmpeg -F mpeg 2 \
> |           -Z 720x576 --export_asr 2 \
> |           --encode_fields t \
> |           -o unsinn.mpeg2
>
> ... dann macht es bestimmt kaum Unterschied, ob du hinter
> "--encode_fields" "t", "b" oder "p" schreibst.

Für mpeg2enc dürfte das wohl genau so zu sehen sein. Ich habe aber keine 
Ahnung, was ich da besser machen könnte.

Al



Reply to: