Re: StillImage -> DV ( war: ffmpeg: libavformat-cvs.so: cannot open ...)
On Thu, 11 Aug 2005 12:41:35 +0200
Al Bogner <debian@ml05a.pinguin.uni.cc> wrote:
> ~$ ffmpeg -i %03d_alga.png -target pal-dvd alga.dv
> ffmpeg version CVS, build 3211265, Copyright (c) 2000-2004 Fabrice
> [..]
> %03d_alga.png: could not find codec parameters
>
> Ah, jetzt kommt eine andere Fehlermeldung.
Ja, die selbe wie in deinem letzen Posting ;-)
> Ich verwende bereits die Pakete aus unstable:
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 ;-)
> w32codecs is already the newest version.
> libavcodec-dev is already the newest version.
> libavcodec1 is already the newest version.
> libavcodec2 is already the newest version.
> libavcodeccvs is already the newest version.
Das sagt wenig darüber aus, um welche Versionen es sich handelt und
woher diese kommen. Das Paket "ffmpeg" gibts sowohl bei Marillat als
auch im offiziellen unstable. "libavcodec-dev" kommt nur aus
unstable (und wird bestimmt nicht für den Marillat-ffmpeg benötigt).
"libavcodec{1,2,cvs}" sowie "w32codecs" kommen nur von Marillat. Sieh dir
die Ausgaben von "apt-cache policy" genau an!
Aus einem anderen Posting von dir (den interessanten Teil, der zeigt woher
das Päckchen kommt, warum es gewählt wurde und welche Alternativen es gab,
hast du weggeschnippelt):
| apt-cache policy ffmpeg
| ffmpeg:
| Installiert:3:20050806-0.1
Bei mir sieht das so aus (mit pinnings):
| $ apt-cache policy ffmpeg
| ffmpeg:
| Installed: (none)
| Candidate: 3:20050427-0sarge0.1
| Version Table:
| 3:20050427-0sarge0.1 0
| 500 ftp://ftp.nerim.net sarge/main Packages
| 0.cvs20050626-2 0
| 300 ftp://ftp.de.debian.org sid/main Packages
| 0.cvs20050313-2 0
| 500 ftp://ftp.de.debian.org sarge/main Packages
Du hast (hattest) also die Marillat-Version von ffmpeg installiert,
nicht die aus dem offiziellen unstable (?).
> Nach den Unstable-Updates mag transcode auch nicht mehr:
>
> [transcode] warning : libavcodec-CVS.so: cannot open shared object file:
> No such file or directory
Versions-Mischmasch? Überreste von selbst kompilierter Software? Noch
andere (evtl. nicht richtig entfernte) Quellen als debian.org und
Marillat? Pinnings? apt-cache policy?
> > > http://pinguin.uni.cc/jerking_flickering_xvid.avi
> >
> > Das habe ich mir schon vor einigen Tagen angesehen, aber ich war zu
> > faul bei transcode-users auf englisch zu antworten... Ich denke, das
> > Problem damit ist, dass die Übergänge zu "hart"/kontrastreich
> > sind. Dabei meine ich vor allem die Szene bei der zwei Bildhälften
> > aufeinander zu fahren. Bei "nur" 25fps kann man sowas merken, wenn man
> > sich darauf konzentriert und direkt am Monitor sitzt. Vom Sofa aus
> > sieht das dann evtl. schon anders aus. Außerdem ist die Auflösung so
> > riesig, dass unter Umständen auch relativ neue Hardware Problemchen
> > bekommen könnte, das Video also garnicht ruckelfrei abgespielt werden
> > kann.
>
> Es geht mir nicht um die _Übergänge_.
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.
> 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.
> Das ruckelt hier etwas, wenn man genau schaut.
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?).
Diese Art von Ruckeln erkläre ich mir durch die recht hohe Auflösung
(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.
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.
> > Der Vergleich mit dem MPEG, welches du noch genannt hattest, ist
> > unfair.
>
> Du meinst http://www.deniscarl.com/stills2dv/mpeg1.mpg?
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.
> > Die Auflösung erinnert ehr an eine Briefmarke und die Bitrate
> > ist so gering, dass alles verwaschen bzw. blockig ist. Da ist's Essig
> > mit kontrastreichen Übergängen. Abgesehen davon sind die Bewegungen
> > viel langsamer und es gibt keine unnatürlichen Übergänge im Bild (die
> > sich in deinem Beispiel auch noch bewegen). Außerdem, wenn ich mir das
> > als Vollbild ansehe und ganz streng bin, auch hier kann ich ein
> > leichtes Ruckeln sehen.
>
> Und um genau dieses Ruckeln geht es.
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).
Andererseits gibts hier Kompressionsartefakte ohne Ende. Diese machen
das Bild zum einen unscharf, was den Bewegungen teils zu gute kommt,
da es sie natürlicher und flüssiger wirken lässt. Auf der anderen
Seite fügt es eine gewisse Unruhe ein, ein Hintergrundrauschen was
störend wirkt. Aus ein paar Metern Entfernung sieht man das aber
u.U. nicht mehr.
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.
> > Eine andere Möglichkeit wäre es, das Video im Halbbildverfahren
> > ("interlaced") zu kodieren. So kannst du die vollen 50Hz
> > Bildwiederholrate von Fernsehern nutzen. Wie du dafür jedoch die
> > Einzelbilder ohne Programmierarbeit erzeugen kannst, weiß ich
> > nicht. Außerdem ist eine Vorschau am PC dann schwierig.
>
> Das ist eines meiner Probleme. Ich habe das Gefühl, dass transcode
> kein interlaced-Video erzeugt, auch wenn die Option --encode_fields
> verwendet wird. Prüfe ich danach mit "transcode -i your_file.avi -J
> fieldanalysis=verbose=1 -c 100-300" dann hat transcode
> Schwierigkeiten interlaced zu erkennen.
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).
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.
> Hast du schon mal gimp-gap verwendet? Der Tip kam aus der Kino-ML.
Nö. Selbst gemachte Animationen faszinieren mich nicht soo sehr. Ich bin
für sowas auch nicht künstlerisch kreativ genug. Mit Einzelbildern hab ich
ehr zu tun, wenn ich Videos zurechtschneide.
Gruß,
Christian Bodenstedt
Reply to: