HD 720p 60fps nach 576P 25fps

Ganz blöd dahingeplappert, ohne viel Ahnung zu haben, einfach nur, weil ich es selbst gerade benutze:

mrestore

Kleiner Auszug:

Zitat

You don't need to set the decimation parameters for the norm conversions restoring Pal_to_NTSC (50->23.976 or 25->11.988)
and NTSC_to_Pal (59.94->25 or 29.97->12.5), but for some seldom other blend conversion restoring
(for example 29.97 back to 23.976 or 50 to 25 - DEFT).
Mrestore use the numerator and denominator instead of an output framerate parameter, because this is more accurate.
If you know the output framerate you can use these three conditions to calculate the best values for numr and denm:
1) numr and denm are integers
2) input framerate * numr = output framerate * denm
3) (output framerate * x) / (input framerate * x) = numr / denm = smallest possible proper fraction

Alles anzeigen

Ich mache damit gerade eine Umwandlung 50i -> 23,976p, und bin eigentlich zufrieden mit den Ergebnissen.

Edit: Achja, interpolieren tut mrestore wohl nicht, es lässt nur den Frame weg, der am vernachlässigbarstem ist. Vielleicht willst du es trotzdem versuchen.

videoslave:
1) lass das assumefps(60) weg. das sorgt nur für A/V ASync!
2) ist das video von einem Camcorder?
oder ist es ein Film/Doku oder ähnliches? wenn es nicht von (D)einem Camcorder kommt, ist es möglciherweise 30 oder 24 fps im 60 fps Video.
Dann muss man es erst auf diese Framerate mittels IVTC runterziehen und kann erst danach interpolieren.
quince: mrestore() ist nur geeignet, wenn das originalvideo im verblendetem Bideo schon die gewünschte Framerate hatte.

okay, Du hast also echte 59.94 fps (nicht 60fps! deswegen das assumefps weglassen!).

generell ist die reduktion der Framerate IMMER mit stärker werdendem Ruckeln verbunden.
Die Kunst liegt darin, dieses Ruckeln einigermaßen gleichmäßig zu verteilen.

was ist Dein Ziel? eine DVD für die Wiedergabe am TV? Oder ausschließlich wiedergabe am PC?

für die Wiedergabe am TV solltest Du unbedingt auf 50i INTERLACED konvertieren, damit die flüssigkeit der bewegung erhalten bleibt:

resize(704,576)convertfps([b]50[/b]) #mischt die Bilder linear gewichtetassumetff().separatefields().selectevery(4,0,3).weave() #reinterlace

bessere Bewegungsflüssigkeit, ABER auch ber ganz heftigen bewegungen schlimme Artfekate bringt

source=resize(704,576).converttoyv12()
backward_vec = source.MVAnalyse(isb = true, truemotion=true, pel=2, idx=1)
forward_vec = source.MVAnalyse(isb = false, truemotion=true, pel=2, idx=1)
source.MVFlowFps(backward_vec, forward_vec, num=[b]50[/b], den=1, ml=100, idx=1)
assumetff().separatefields().selectevery(4,0,3).weave() #reinterlace

für PC-Wiedergabe würde ich es entweder bei 59.94fps belassen, oder einfach jedes 2. Bild mit selecteven() rausschmeissen, umd dann 29.97fps zu erhalten.

Zitat

Progressiv benutzen wir nur, damit es nicht so übel auf den LCD Fernsehern und PC´s aussieht - 25P wäre also wünschenswert, da man beides benutzen soll.

Die meisten LCD-TVs können ja garkein 2:2 Pulldown bei PAL 25p, deinterlacen also genauso, wie bei 50i. Und die neueren DVD-Software-Pler sowie grafikkarten haben auch ganz vernünftige Deinterlacer verbaut.
25p sieht meiner meinung nach für SPiele zu ruckelig aus. Zumal, wenn es noch von 59.94p konvertiert wurde... 50fps 50i kann da schon einiges kaschieren)

Zitat

MVFlowFps checke ich mal aus, aber ich denke aber mal das gerade bei Schriften alles zittert, oder ?

Was meinst Du damit?

Nimm bitte Adobe-Produkt nicht als referenz für video-konvertierungen.
Da geht nämlich oftmals so einiges Schief!

Lade die 720p60 video direkt in AVISynth und wandle sie dort nach 576i50 um!

da wird nix anfangen zu zittern...
Adobe kann halt nicht richtig mit interlace umgehen.

kannst Du mal ein UNBEARBEITETES Sample Video (also 720p 59.94fps) bei http://rapdishare.com oder so hochladen? je mehr, desto besser...

Das würde ich mal unter "erschwerte Bedingungen" verbuchen:
- Registrierung bei Adobe, nur um einen Demo-Codec herunterzuladen ...
- 5 einzelfiles bei Rapidshare, mit ca. 1.5 Stunden Wartezeit bis zum nächsten Download (IP-Reset ist nicht jederzeit für jedermann machbar...)

... das kann dauern, ich melde mich irgendwann im Verlaufe diesen Jahres nochmal. :zunge:

Schneller Blick auf's AfterEffects-Video:
Na toll. Hin und wieder scheint AE tatsächlich Bewegungskompensation zu produzieren. Das meiste ist aber simple Blend-Interpolation.
Da kommt Avisynth mit 'nem ganz dummen "ConvertFPS(25.000)" dem professionellen Produkt bereits ziemlich nahe ... :schmunzel:

edit:

Zitat von Adobe

You must have Premiere Pro CS3 (still Beta), 2 or 1.5.1 installed prior to installing Aspect HD. If you don't have Premiere Pro installed you can use the 30-day trial version available from the Adobe website.

So, jetzt hab ich kein' Bock mehr. Wenn's die Quelle in einem vernünftigen, frei zugänglichen Format gibt, dann schau' ich mir das gerne mal an. Ansonsten wünsche ich weiterhin viel Spaß.

Der Cineform-CoDec geht nicht auf meinem AthlonXP. (hat kein SSE2)

konvertiere das Video mit Virtuadub mit einem der CoDecs:
HuffYUV oder MJPEG (mind. Q19)

Äh, bitte kein WMV. Wenn schon stark komprimiert, dann XVid (in voller Auflösung) im AVI.

Und der CineForm-Decoder geht auch nicht...
Ich habe den damals an der Setup-Routine vorbei manuell installiert, und auch da ging nix, weil der Decoder mangels SSE2 einfach abgesürzt ist...

So, da simmer wieder.

@ Scharfi

Mit ffdshow's FFV1 wird das File ~320MB (YV12) bzw. 350MB (YUY2). Soll ich das auf MegaUpload hochladen?

-----

Zitat von videoslave

Bei Cineform muß man sich anmelden, nicht bei Adobe.

Oha. Ja, natürlich. Mein Fehler.

Zitat

aber ich hätte eigentlich diesen Link schicken sollen..das ist jetzt nur der Decoder ohne Anmeldung..

Yupp, das funktioniert. Danke.

Zitat

Ich glaube du hast das Problem nicht erkannt, um das es hier geht. Es geht um Unschärfe vs. Ruckeln.

Wenn Du das sagst, dann wird's wohl so sein. Bitte mein fehlendes Verständnis der Problematik zu entschuldigen.

Zitat

Zur Größe der Datei: Was erwartest du bei der Rohdatei eines HD Videos?

Ich habe mich in keiner Weise über die Dateigröße beschwert. Meine Bemerkung ging nur dahin, das es schade ist, eine ~220MB Datei zu splitten und anderen Normalbenutzern die stundenlangen Wartezeiten zuzumuten, wenn es auch andere Filehoster gibt, die bis zu 300MB (oder noch mehr) zulassen. Es bringt wenig, wenn ich ein Teilarchiv in 2 Minuten runterladen kann, und dann anderthalb Stunden warten muss bis es weitergeht ... aber is' auch egal jetzt, was soll das.

Zitat

Ein Frameblending in Kauf zu nehmen um die Geschwindigkeit und die Bewegung zu erhalten ist keine Schande. After Effects ist eigentlich ein Compositing Programm und kein Videoconverter, jedoch kann es sehr unstressig diese Wandlung mit annehmbarer Qualität erledigen.

Avisynth auch. Ich verweise nochmal auf "ConvertFPS(25.000)".
Oh, halt: ConvertFPS schafft 60->25 nicht, glaube ich. Da müsste man ersatzweise BlendFPS aus der motion.dll benutzen.

Zitat

Ich kann dir einen Vorschlag machen. Poste ein Script, das eine bessere Wandlung macht und ich codiere es dir mit dem selben Sample und stelle es Online.

So einfach geht das nicht. Eigentlich geht es in diesem Fall hier gar nicht. Du wirst gleich sehen, warum.

Gegenvorschlag: Wenn's recht ist, klären wir jetzt mal, was hier *wirklich* das Problem ist.

Zitat

Es geht um Unschärfe vs. Ruckeln.

Das ist bereits ziemlich verquer. Unschärfen sind weder in der AE noch in der AS Konvertierung drin. Die Konvertierung von AE *scheint* in schnellen Bewegungen weniger scharf zu sein, aber das ist ein Trugschluss. Vielmehr ist es so, dass durch das Frameblending lokaler Kontrast verloren geht.
Beispiel: Sequenz "10 10 10 20 10" - "10 20 10 10 10". Lokaler Kontrast ist +10.
Echte Bewegungsinterpolation erstellt dazwischen: "10 10 20 10 10". Lokaler Kontrast ist +10.
Einfaches Frameblending erstellt dazwischen: "10 15 10 15 10". Lokaler Kontrast ist nur noch +5.

Dieser Kontrastverlust wirkt zwar in Bewegung so ähnlich wie Unschärfe, hat aber tatsächlich mit "Schärfe" ziemlich wenig zu tun.

Dann, "Ruckeln":

Echtes "Ruckeln" tritt dann auf, wenn ein Bewegungsfluss, der gleichförmig sein sollte, nicht gleichförmig ist. z.B. weil einzelne Frames weggelassen oder verdoppelt wurden.
Ein anderer Effekt ist "Strobing", der mitunter (fälschlicherweise) auch als "Ruckeln" betitelt wird. Strobing tritt bei niedrigen Frameraten (wie z.B. 25fps progressiv) auf, wenn kein Motion-Blur vorhanden ist. Etwa bei Kameras mit zu kurzer Verschlusszeit, oder bei CGI-Renderings wie z.B. Konsolenspielen.
Soll ich jetzt noch mit Retina-Persistenz anfangen ... nein, lassen wir das.

Also ... über welche Art von "Ruckeln" hattest Du Dich nun eigentlich geäußert?

Antwort ist überflüssig, es geht nämlich weiter.

Nachdem ich jetzt alle Puzzlesteinchen zusammen habe, konnte ich einen Blick auf das Quellvideo werfen.

Allein die ersten 100 Frames sehen folgendermaßen aus:
(Notation: "c" = "echter" Frame, unterschiedlich zum Vorgänger / "-" = "drop Frame", ein Duplikat des Vorgängerframes)

cc-c-cc-c-cc-c-c-cc-c-cc-c-cc-c-c-cc-c-c-cc-c-c-c-c-c-c-c-c-c-c-c-c-c-c-c-c-c-c--cc-c-c-c-c-c-c-c--c

Und in diesem Stil geht es die ganze Zeit über. Nicht gut. Gar nicht gut.

Des Rätsels Lösung ist also:

Deine Quelle ist viel zu schlecht für eine gute Framerate-Wandlung.

Tatsächlich ist das Ruckeln nämlich bereits im Quellmaterial drin. Und wenn in der Quelle bereits dermaßen viele Drop-Frames drin sind, dann muss das Ergebnis von *echter* Bewegungsinterpolation zwangsläufig schlecht werden. Es ist ja bei durchschnittlich jedem zweiten Frame NULL BEWEGUNG zum Vorgängerframe vorhanden, deswegen kann das nichts werden.
In dem Fall ist "dummes" Frameblending tatsächlich von Vorteil, weil dadurch die Unregelmäßigkeiten besser in der geringeren Ziel-Framerate versteckt werden.

Wenn's wenigstens ein klares c-c-c-c-c-c-... - Pattern wäre, dann könnte man einfach über SelectEven/Odd() auf 29.97 reduzieren, und das dann zur Bewegungsinterpolation übergeben.
Aber da die Dup's ja ziemlich zufällig verstreut sind, kann man das so nicht machen. Spätestens bei den doppel-Dup's (-c--c-) bleibt dann nämlich ein Dup übrig, und dann ruckelt's am Ende erst wieder.
Man könnte noch probieren, ob man mittels TDecimate() eine saubere Framefolge erreichen kann, aber irgendwie drängt es mich schon gar nicht mehr ausdrücklich, daran rumzuknobeln ...

Mein Fazit ist somit:
Schuld sind nicht die Tools. Schuld ist Dein Quellmaterial, das auf eine Art und Weise verbogen ist, das eine *wirklich* gute Normwandlung leider fast unmöglich macht.
Ob es jetzt so ist, dass die PS3 tatsächlich so eine unregelmäßige Framefolge produziert (zu viele Effekte), oder ob der Codec zu viel Leistung frisst, deswegen nicht alle Frames codieren kann und (un-) regelmäßig Frames doppeln muss ... weiss ich nicht, kann ich nicht sagen.
Sicher ist nur: das, was letztlich als Quelle vorliegt, ist für ein hochqualitatives Ergebnis reichlich ungeeignet. Punkt.

... aber wie gesagt, ich hab' ja keine Ahnung von der Materie. Also nicht so ernst nehmen, und noch andere Meinungen einholen.

Ich habe jetzt mal das ganze gedöhns auf einem P4-Rechner nach HuffYUV umgewandelt,
damit ich es mir hier angucken kann.

Also das Quellvideo ist keineswegs 59.94fps.
Die Spielkonsole hat nur 29.97 fps (Hälfte, 2:2 Pulldown)
respektive 44.955 fps (Dreiviertel, 1:1:2 Pulldown) geschafft.
Das ganze ist also variable Framerate.
Dir bleiben zwei Möglichkeiten:
1) Blending auf 25 oder 50 fps mit convertfps()
2) Decimation auf 25 oder 50fps mit TDecimate,
damit die verdoppelten einzelbilder adaptiv rasugeschmissen werden.

Motion-Interpolation bringt hierbei KEINE vernünftigen Resultate.
Es sei denn jemand wartet mit einer Lösung auf, die
- das video automatisch adaptiv auf seine variierende Grundframerate dezimiert
- und dann automatisch auf die Zielframerate interpoliert

EDIT: Dideé war schneller...

Wenn man in VirtualDub das CineForm-AVI anguckt,
dann sieht man, dass der CoDec Frame nicht kodiert hat
(in der Statusleiste steht dann hinter dem Timecode [] anstatt [K]).

Nun ist die Frage:
War CineForm so schlau, die Duplikates einfach nur als Dropframe durchgehen zu lassen,
oder war der encodierende Rechner schlichtweg zu langsam?

Das Pattern kann man 'Einsehen' indem man das video frame für frame wiedergibt.
z.B. in Virtualdub. Dann sieht man ganz schnell, welche Bilder doppelt sind.

Du kannst mal zum Vergleich ein spiel capturen, welches garantiert butterweich läuft.
Und dann ein 100 MB schnipsel mit gleichmäßiger Bewegung hochladen.
(das sample was Du zur verfügung gestellt hast, ist nicht so günstig, weil man schlecht abschätzen kann, ob das wirklich drop-frames sind, oder ob die konsole wirklich nur duplikate produziert hat)

Zitat

Meinst du mit Butterweich was man sieht, oder die Anordnung der aufgenommenen und gedropten Frames. (Hoffe ich hab das richtig verstanden).

Butterweich = saubere Bewegung OHNE jegliches Ruckeln = KEINE gedroppten Frames oder Framduplikate!