progressive-telecined-interlaced

Oh, ja, genau! Das Original-Script war sehr durcheinander ... das habe ich übersehen! - Ist jetzt korrigiert.

Ausserdem ist das "nur" das Denoising. Vorher muss noch das TFM() gesetzt werden.

Ziel war, das Rauschen/Grain zu reduzieren, ohne das Ergebnis "zu künstlich"/"zu glatt" zu machen. Gleichzeitig wird noch die allgemeine "Schärfe" verbessert. Problematisch war auch, dass das Material viele Artefakte an den Detail-Kanten hat ... das Script reduziert diese Artefakte nur ein wenig -- wichtiger war, dass diese Artefakte durch die Schärfung nicht noch weiter verstärkt werden.

Vielleicht ist es besser, diese Parameter zu ändern:
(truemotion=true) => (truemotion=false)
(blksize=16) => (blksize=8)

Es war zu wenig Material von den "Real"-Sequenzen, um das zu testen. (Das darfst Du machen.)

Nein. Ich habe die Post 2x in einer Minute geändert. Du warst zu schnell.

Die Quelle hat anamorphes Seitenverhältnis.

Quelle: 720x576 ===> Darstellung: 1024x576

Im MKV-Container kann man festlegen, mit welchem Seitenverhältnis (bzw. mit welchem Aspekt-Ratio) das Video abgespielt werden soll.

---

Zufalls-Schnipsel: links-gefiltert / rechts-Original
[Blockierte Grafik: http://img246.imageshack.us/img246/2607/vorhernachher.th.jpg] -- und -- [Blockierte Grafik: http://img411.imageshack.us/img411/9102/vorhernachher2.th.jpg]

Die Ränder sind ein kleines Problem, weil die schwarzen Ränder zusätzliche Artefakte verursachen ("Ringing"). Das Problem ist ganz schnell mit "Crop(8,8,-8,-8)" zu lösen, aber ... na ja. :hm:

Verflixt, in dem Script habe ich noch etwas vergessen!

[etwas später]

Ich wollte noch eine Kombination machen:

[color='SlateGray']rg11  = o1.removegrain(11)sbrr  = o2.sbr()rg4   = sbrr.removegrain(4)s0    = o1.mt_adddiff(mt_makediff(sbrr,rg4),U=2,V=2)[/color]#s00   = s0.sharpen(0.49)s00   = s0.limitedsharpenfaster(ss_x=1.0,ss_y=1.0,strength=76,soft=26)[color='SlateGray']s0    = s00.mt_makediff(mt_makediff(s00,s0).blur(1),U=2,V=2)s0    = mt_lutxy(o1,s0,"x x y - abs 1 2 / ^ 2 * x y - x y - abs 0.001 + / * -",U=2,V=2)[/color]

Ich habe gesehen, dass LSF besser in Bereichen ist, wo die Quelle bereits kleine Halos hat. Aber: sharpen() ist besser in den anderen Bereichen.
Diese beiden Sachen miteinander zu kombinieren - das hatte ich noch vergessen ...

Die richtige Kombination:

[color='SlateGray']rg11  = o1.removegrain(11)
sbrr  = o2.sbr()
rg4   = sbrr.removegrain(4)
s0    = o1.mt_adddiff(mt_makediff(sbrr,rg4),U=2,V=2)[/color]
s00   = s0.sharpen(0.49)
s00a  = s0.limitedsharpenfaster(ss_x=1.0,ss_y=1.0,strength=76,soft=26) 
s00   = s00.mt_merge(s00a,e2,U=2,V=2)
[color='SlateGray']s0    = s00.mt_makediff(mt_makediff(s00,s0).blur(1),U=2,V=2)
s0    = mt_lutxy(o1,s0,"x x y - abs 1 2 / ^ 2 * x y - x y - abs 0.001 + / * -",U=2,V=2)[/color]

Habe die Post mit dem Script also nochmal geupdatet ...

720x576 - some bitrate

720x404 - less bitrate

640x360 - lesser bitrate

512x288 - even lesser bitrate

320x180 - little bitrate

Weniger Auflösung => weniger Bitrate. Mehr Auflösung => mehr Bitrate.

Was für eine Antwort erwartest Du ... ?

Wie rechnest du denn, Terka?! - Trivial ist im Videobereich oft nicht korrekt.

Lass mal lieber die Auflösung, wie sie ist. Vor allem die Höhe zu erhalten ist vorteilhaft, denn vielleicht willst du das Video irgendwann mal auf dem Fernseher ausgeben, und dann sind 576 Zeilen genau richtig für PAL. Dann bleiben dir alle Details der vertikalen Auflösung erhalten, die ein Resizen sonst weichgezeichnet hätte (und das wäre Qualitätsverschwendung statt Bitratenverschwendung).

Und "anamorphe" Speicherung (gestauchter, aber originalgetreuer Inhalt mit einer Markierung, wie bei der Wiedergabe zu entzerren sei) ist für den Matroska-Kontainer kein Problem.

Weiterhin sind Höhenänderung bei "eventuell interlacetem Video" ein erheblicher Risikofaktor, denn die führen zu stark auffälligen Wellen im Bild, wenn doch noch was übrig war (also eigentlich prima zum Suchen von Combing...).

Außerdem ist eine Höhe von 405 Zeilen auch technisch eine ganz schlechte Idee - die ist ja noch nicht mal geradzahlig (also nicht symmetrisch auf zwei Halbbilder verteilbar), geschweige denn durch 8 oder gar 16 teilbar (wichtige Faktoren für MPEG-Blöcke oder gar DXVA-Videobeschleunigung).

Qualität braucht Platz. Und wem kann denn heute im Zeitalter von Terabyte-USB-Festplatten noch wichtig sein, auf die Größe einer CD zu kommen?

Nun, es kommt vor allem darauf an, womit man es am Ende abspielen will.

Dem PC ist es relativ egal, der vergrößert alles, bis es an den Rand des Player-Fensters oder des Bildschirms stößt, wenn man das nicht anders einstellt. Aber je kleiner die ursprüngliche Auflösung war, umso matschiger wird das Ergebnis.

Beim Abspielen auf einem Consumer-Player am Fernseher dagegen ist es schon wichtig. Gestauchte Breite bei anamorpher Speicherung ist wahrscheinlich kein Problem, der Fernseher selbst wird das wieder entzerren. Aber gestauchte Höhe ist ein erheblicher Qualitätsverlust. Vor allem bei Röhrenfernsehern, die ja nun mal das Bild zeilenweise aufbauen.

Sicher braucht eine etwas größere Bildfläche etwas mehr Speicherplatz. Aber ein geschärft verkleinertes Bild braucht auch mehr durch die Schärfung. Und ein ohne Schärfung verkleinertes Bild verliert viele Details.

Ja:

Nicht croppen, nicht resizen; die vorhandenen 720x576 so in der Breite gestaucht einfach encodieren - aber in der x264-Kommandozeile zusätzlich noch die Option mit angeben: "--sar 64:45". Dann wird der Player beim Abspielen das Bild von 720x576 Pixeln auf ein Seitenverhältnis von 16:9 vergrößern und entzerren (720 * 64 : 45 = 1024; 1024:576 = 16:9).