Beiträge von SagaraS

Da ich großer LucasArts Fan bin und mich die älteren Games durchs Leben begleitet haben, bin ich jetzt als Hobby Informatiker an dem Punkt wo ich gerne die Videos auslesen würde.

Die Rede ist von Smush Animation oder auch kurz SAN bzw. SNM. Wenn sie verzippt sind werden sie von LucasArts auch ZNM genannt.

Ich habe das Internet auch schon durchforstet und die brauchbare Links gefunden:
https://wiki.multimedia.cx/index.php?title=SAN
https://github.com/clone2727/smushplay
https://www.ffmpeg.org/doxygen/2.3/smush_8c.html
https://www.ffmpeg.org/doxygen/2.3/smush_8c_source.html

Auch eine DLL Variation die es eventuell auslesen lassen kann habe ich gefunden:
http://jsg.id.au/scumm/smush.txt

Jetzt kommt aber das Problem was ich habe. Einige Lucas Arts Smush Files werden nicht richtig dekodiert. Audio sei jetzt mal dahingestellt, weil mir geht es erst mal nur um die Frames an sich.

Als nächstes habe ich solch eine SAN Datei zerlegt mit HxD
Was auch ganz einfach ist bei einer Big-Endian Speicherung.

Erst kommt die nötige Header Bezeichnung 4 Byte, dann die Größe dessen mit 4 Byte. Legt man auf der ausgelesenen Größe die 8 Byte drauf für Header und Dateigröße, hat man die Größe der einzelnen Elemente. Also ganz Easy.

Nur ist mir die Dekodierung nicht ganz klar wie ich das umsetzen soll.

Die Bilder scheinen aus 256 Farben zu bestehen und am Anfang steht die Palette.

Sprich der AHDR Header und das was unter ihm läuft beherbergt die Paletten Definition für die optimale 256 Farbpalette.

Und dann geht es los mit FRME

FRME = Frame

1 FRME beinhaltet sowohl ein Frame Object FOBJ (Sprich die Bilder) und ein IACT (iMUSE Audio)

Den Audio Part kann ich mit Scumm Revisited dekodieren.
Der spielt dann auch mehrere Samples unter diesem 1 FRME ab.

Also gehe ich davon aus das dieses Frame Object FOBJ auch mehrere Bilder haben müsste.

Jetzt dekodiert das aber FFmpeg total komisch, was halt die Vermutung aufbringt das die Pixel an sich nicht refresht werden dürften, sondern weiter bestehen müssten um das Video korrekt anzeigen zu können.
Ich glaube nämlich das das FOBJ nur einige Frames an bestimmten Positionen ändert und nur über das vorherige Bild zeichnet, denn das Anfangsbild was FFmpeg mit dem Video macht und auch jeder Frame der eine komplett neue Szene zeigt dessen Farben sich komplett voneinander unterscheiden sind perfekt. Erst danach wird das mit schwarzen Pixeln übertönt, weil FFmpeg ja jeden Frame refreshen tut.

Das heißt im Endeffekt A) ich müsste es bei FFmpeg anbringen das die das Fixen, wovon ich aber nie ausgehen werden kann oder B) einen eigenen Dekoder zusammenbauen der dies macht.

Da ich die SAN zwars auslesen kann und Dumpen kann, versetzt mich leider noch nicht in die Lage es dekodieren zu können.

Und genau da bräuchte ich Hilfe bei. Ich möchte im Endeffekt ein Tool haben (was eventuell auch noch erweitert werden kann) das Speziell für Smush Videos vorgesehen ist.
Total Genial wäre wenn jemand ein AVISynth Tool dafür schreiben könnte. Das wäre denk ich auch viel Nützlicher.

Und Anfangen wollte ich mit Star Wars - Shadow of the Empire

Hier auch mal eine Testdatei, damit ihr das selbst ausprobieren könnt:
http://www.mediafire.com/download/td5r9…ya/L01INTRO.SAN

Und hier die Files die ich herausgerippt habe:
http://www.mediafire.com/download/hpz29…_and_Palette.7z

Spezifikation des Videos:

Video:
Smush Animated
Auflösung: 640x332
FPS: 15
Farbraum: PAL8 (256 Farben) RGB?
Frames: 1239

Ton:
iMUSE
Audio Kanäle: 2
Samplingrate: 22050 Hz

Ich hoffe das sich jemand findet der mir bei dem Vorhaben helfen kann. Bzw. vllt auch eine andere Möglichkeit kennt.

Das ist natürlich mies

Ja, keine Ahnung was die da gemacht haben bei der BluRay Erstellung. Aber schön ist das nicht.

Bei DVDs bekomme ich Interlacing in den Griff und habe da selbst bei Anime keine Probleme mit. Aber diese BluRay hier hat mich schon Nervern gekostet.

Ich bin ja nun nicht so blöd was AVISynth und Filter angeht. Immerhin habe ich den SSM entwickelt der AVISynth Skripte erstellt und für Let's Player gedacht ist. Aber Interlacing dieser Art wie es auf dieser BluRay ist echt abnormal. Und genau da setzt dann auch mein Wissen aus was man dagegen tun könnte.

Ich meine... was Interlacing ist weiß ich, aber selbst solch ein exotisches Teil zu haben überfordert mich dann doch schon xD

Bis jetzt war auch jede BluRay die ich hatte was Anime anging immer in Progressiv. Sieht auch viel schöner aus, macht keine Arbeit und ist Zufrieden am Ende. Aber Interlacing ist so dermaßen Sch...e. Wieso nutzt man das, wenn sogar Filme wie Herr der Ringe auf BluRay in Progressiv vorliegen oder gar andere Anime.

Aber ich denke... bevor ich daran ganz Verzweifle, werde ich noch mal schauen ob man den Anime als andere Auflage bekommt die vllt. dann sogar in Progressiv vorliegt.

Und das Problem hier... ich werde das Video auf Mediafire belassen. Eventuell wurstet da vllt. jemand noch mal was zusammen bei Interesse.

Wäre ja nicht schlecht wenn es dafür eine Lösung dann geben würde. Weil ich bin da nicht so der Typ für mit den ganzen Filtern wie MVTools, etc. was brauchbares zusammenzustellen was dagegen helfen könnte. Weil wie gesagt, in der Regel habe ich es eigentlich nur mit Progressiv Material zu tun und wenn Interlaced, dann nur DVDs und selbst da haben bis jetzt die normalen Deinterlacer ausgereicht das man das nicht mehr so sieht. Nur bei dieser BluRay sieht man das ja im Nachhinein und das ist nix für mich dann. Das sieht dann halt Mistig aus xD

Hier ist mal das File: http://www.mediafire.com/download/tac6994nbeoawqx/00006.mkv

Ich hab ein Stück mit MKVmerge via einem Zeitstempel herausgemuxt aus dem GANZ großen File. Ist sozusagen das vergebliche Rohmaterial wie ich es von der BluRay habe.

Ich kann mit SeperateField das aufspalten, damit die Halbbilder von einander getrennt sind.

Aber auch da gibt es vereinzelte Frames die wieder ein Interlaced Muster aufweisen. Und das will mir nicht in den Kopf. Für mich ist dieses ganze Interlaced Gewusel irgendwie zu hoch. Weil ich gar nicht weiß woran ich da was erkennen soll und was man dagegen tun kann. xD

Und wie geht man am besten vor wenn das Deinterlacing Verfahren Ghosting erzeugt, weil jede zweite Zeile bei Bewegungen stark nach rechts oder links abweicht und somit Ghosting vorprogrammiert ist?

Ich habe hier eine BluRay Quelle vorzuliegen die auf 1080i 30/1001 FPS vorliegt.

Der DGAVCIndexer sagt mir das es sich um MBAFF handelt. Im Film selbst sehe ich auch diese feinen Interlaced Streifen.

Die Frage die sich mir halt stellt ist wie ich das nun gescheit und am besten raus bekomme? Halt so gut wie möglich.

Weil ich bin nicht grad ein Interlaced Freund und hasse die Bearbeitung von Zeilensprung Videos.

Gibt es da spezielle Filter für?

Und wenn es jemanden Hilft, hier eine erweiterte Mediainfo dieses Videos:

VideoAnzahl                              : 335
Anzahl der Streams dieser Art            : 1
Art des Streams                          : Video
Art des Streams                          : Video
ID des Stream-Identifiers                : 0
StreamOrder                              : 0-0
ID                                       : 4113
ID                                       : 4113 (0x1011)
Menü-ID                                  : 1
Menü-ID                                  : 1 (0x1)
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format/URL                               : http://developers.videolan.org/x264.html
Format_Commercial                        : AVC
Format-Profil                            : High@L4.1
Format-Einstellungen                     : CABAC / 4 Ref Frames
Format-Einstellungen für CABAC           : Yes
Format-Einstellungen für CABAC           : Ja
Format-Einstellungen für ReFrames        : 4
Format-Einstellungen für ReFrames        : 4 frames
InternetMediaType                        : video/H264
Codec-ID                                 : 27
Codec                                    : AVC
Codec                                    : AVC
Codec/Familie                            : AVC
Codec/Info                               : Advanced Video Codec
Codec/URL                                : http://developers.videolan.org/x264.html
Codec-Profile                            : High@L4.1
Codec-Einstellungen                      : CABAC / 4 Ref Frames
Codec-Einstellungen für CABAC            : Yes
Codec_Settings_RefFrames                 : 4
Dauer                                    : 1390556
Dauer                                    : 23min
Dauer                                    : 23min 10s 556ms
Dauer                                    : 23min
Dauer                                    : 00:23:10.556
Dauer                                    : 00:23:10;17
Dauer                                    : 00:23:10.556 (00:23:10;17)
Bitraten-Modus                           : CBR
Bitraten-Modus                           : konstant
nominale Bitrate                         : 34999296
nominale Bitrate                         : 35,0 Mbps
Breite                                   : 1920
Breite                                   : 1 920 Pixel
Höhe                                     : 1080
Höhe                                     : 1 080 Pixel
Stored_Height                            : 1088
Sampled_Width                            : 1920
Sampled_Height                           : 1080
Pixelverhältnis                          : 1.000
Bildseitenverhältnis                     : 1.778
Bildseitenverhältnis                     : 16:9
Bildwiederholungsrate                    : 29.970
Bildwiederholungsrate                    : 29,970 (30000/1001) FPS
FrameRate_Num                            : 30000
FrameRate_Den                            : 1001
Anzahl der Frames                        : 41675
Standard                                 : NTSC
Auflösung                                : 8
Auflösung                                : 8 bits
Colorimetrie                             : 4:2:0
ColorSpace                               : YUV
ChromaSubsampling                        : 4:2:0
ChromaSubsampling/String                 : 4:2:0
BitDepth                                 : 8
BitDepth/String                          : 8 bits
Scantyp                                  : MBAFF
Scantyp                                  : MBAFF
ScanType_StoreMethod                     : InterleavedFields
Scanreihenfolge                          : TFF
Scanreihenfolge                          : oberes Feld zuerst
Interlace                                : MBAFF
Interlace                                : MBAFF
Bits/(Pixel*Frame)                       : 0.563
Verzögerung                              : 600000.000
Verzögerung                              : 10min
Verzögerung                              : 10min 0s 0ms
Verzögerung                              : 10min
Verzögerung                              : 00:10:00.000
Delay_Source                             : Container
BufferSize                               : 29999616 / 29999616
colour_range                             : Limited
colour_description_present               : Yes
colour_primaries                         : BT.709
transfer_characteristics                 : BT.709
matrix_coefficients                      : BT.709
format_identifier                        : HDMV

Das Muster hab ich doch im Video auch schon gesehen.

Und halt genau aus dem Grund wird das mit DeFreq sehr schwer das Gegenmuster heraus zu bekommen, damit es aufgelöst werden kann.
Da es Geradlinig müssten alle fx bei 0 beginnen. Du wirst mehrere Frequenzen benutzen müssen.

Ich teste ja auch schon mit Avspmod rum, weil ich mir das via den Slidern besser bedienen lässt:

DeFreq(fx=[<'fx', 0.00, 100.00, 0.0>], fy=[<'fy', -100.00, 100.00, 100.0>], dx=[<'dx', 0.00, 50.00, 0.3>], dy=[<'dy', 0.00, 50.00, 16.67>],sharp=[<'sharp', 0, 100, 80>], fx2=[<'fx2', 0.00, 100.00, 0.0>], fy2=[<'fy2', -100.00, 100.00, 100.0>], dx2=[<'dx2', 0.00, 50.00, 1.96>], dy2=[<'dy2', 0.00, 50.00, 2.94>],sharp2=[<'sharp2', 0, 100, 55>], plane=[<'plane', 0, 2, 0>], show=[<'show', 0, 2, 1>], info=true)

An sich muss nur die Gegenfrequenz gefunden werden. Sprich das Muster im Oberen Feld bei der Show = 1 bzw. 2 Ansicht müssen dem Muster entsprechen den du versuchst aufzulösen.

Und dazu kann man mehrere Frequenzen angeben. max. 4.

Und das Muster muss auf Plane 0 dann getilgt werden. Aber ich finde das es eine Sisyphusarbeit ist. Wenn das Plugin dann auch so arbeitet wie es beschrieben ist.

Ich denke aber das man dieses "Brightness Interlacing" wie man es ja eigentlich nennt, nicht zu 100% entfernen kann. Das zeigt ja schon dein Beispiel mit dem erzeigten Muster. Reduzieren... ja, durch Verwischen oder oder oder... aber das eigentliche Problem ist da eher die Quelle.

Wenn du es aber mit DeFreq hinbekommen solltest, was ich eher nicht so recht glaube das du da das Muster triffst, wäre das auf jedenfall gut, aber ist dann auch nur auf dieses Video dann bezogen nur. Das nächste Video kann schon wieder ein anderes Muster haben.

Also als ich das analysiert habe, hat eher der Y Kanal dieses Muster enthalten.

[Blockierte Grafik: http://fs5.directupload.net/images/160613/zolsvteb.png]

clip0 = DGDecode_mpeg2source("test lines dvd quality.d2v", info=3)#DeFreq(fx=[<'fx', 0.00, 100.00, 6.02>], fy=[<'fy', -100.00, 100.00, 84.32>], dx=[<'dx', 0.00, 50.00, 5.56>], dy=[<'dy', 0.00, 50.00, 13.07>],sharp=[<'sharp', 0, 100, 100>], fx2=[<'fx2', 0.00, 100.00, 8.5>], fy2=[<'fy2', -100.00, 100.00, -85.62>], dx2=[<'dx2', 0.00, 50.00, 9.48>], dy2=[<'dy2', 0.00, 50.00, 9.8>],sharp2=[<'sharp2', 0, 100, 100>], plane=[<'plane', 0, 2, 2>], show=[<'show', 0, 2, 1>], info=true)
Y=ColorYUV(clip0,off_u=-256, off_v=-256).ColorYUV(off_u=128, off_v=128)
U=UtoY(clip0)
V=VtoY(clip0)




UVmerge = YtoUV(U, V, BlankClip(u, color=$000000))
blackbox = BlankClip(u, pixel_type="YV24")
U2 = YtoUV(U, BlankClip(U, color=$000000), BlankClip(u, color=$000000))
V2 = YtoUV(BlankClip(v, color=$000000), v, BlankClip(u, color=$000000))
y2 = y.ConvertToYV24()




blackbox2 = BlankClip(y2)




U3 = YtoUV(U, BlankClip(U, color=$000000), y).ConvertToYV24()
V3 = YtoUV(BlankClip(v, color=$000000), v, y).ConvertToYV24()




UVcom = StackVertical(u2.Subtitle("U Channel (4:4:4)") ,v2.Subtitle("V Channel (4:4:4)"))
UVcom2 = StackVertical(blackbox, UVmerge.Subtitle("UV Channel (4:4:4)"))
line1 = StackHorizontal(y2.Subtitle("Y Channel (4:4:4)"), UVcom, UVcom2)




uvcom3 = StackHorizontal(u3.Subtitle("YU Channel (4:2:0)"), v3.Subtitle("YV Channel (4:2:0)"))
StackVertical(line1, uvcom3)

Und da das Muster Hauptsächlich im Y Kanal liegt und eine Art von Kinescope zu sein scheint das dazu auch noch ein sehr detailliertes Muster aufweisen tut, wird es recht schwer da mit DeFreq beizukommen.

Den U und V Kanal kannste ausschließen an sich, da du diese Kanäle so massiv Bluren und Denoisen kannst wie du willst, bzw. sogar andere Farben geben mit BlankClip, das du trotzdem noch das Muster drin hast. Und das kommt definitiv massiv vom Y Kanal.

Siehe: http://what-when-how.com/digital-imagin…imaging-part-1/

Figur 11.4

Würde sagen das das schon dem entsprechen würde. Nur das es bei dem jetzigen Video hier nur geradliniger ist. Weil es ist ja nun keine Wellenform ist, sondern bei genauerem Betrachten eher schnurgerade Linien von links nach rechts.

Edit:
An sich sieht das Video halt aus wie eine Mischung aus normalen Rauschen (Kann man im DeFreq beobachten) und diesen Linien die sich Spalte für Spalte ändern und so eine Art kurioses Interlacing bilden. Eventuell kann es eine Flächenform vom Regenbogeneffekt sein. Denn wenn man mit Selectodd bzw. Selecteven da ran geht nach SeparateFields, dann sieht man eigentlich das die Linien konstant sind und sich nicht bewegen. Einzig und allein das Rauschen (Noise) ist dann noch vorhanden.

Und mehr erkenne ich da nicht.

Vllt. hilft das ja schon mal zur Problemfindung.

fx und fy sind die Positionen im Frequenzspektrum, während dx und dy den Frequenzbereich darstellen.

Sprich man hat z.B. ein Frequenzbereich von dx = 1.5 und dy von 2. Macht ein Rechteck Bereich von 1.5 und 2 im Gesamtspektrum auf der Position fx, fy.

Mit show 1 oder 2 kannst du dir das entsprechend anschauen. Du kannst auch noch weitere Bereiche hinzufügen. Glaube 4 Stück an der Zahl.

Der Bereich und Position ergeben letztendlich ein Muster, was ebenfalls mit Show=1 und 2 angezeigt wird. Dieses Muster ist dann selektiert und wird entfernt.
Unter show= 1 bzw. auch 2, musst du nach bestimmten Mustern dann suchen. Wie diese aussehen, hängt von der Quelle immer ab und auch vom Typ der Frequenz die man sucht.

Mit Plane sagst du an welchen Kanal er nehmen soll dafür. 0 = Y, 1 = U, 2 = V. Also auf welchen Kanal diese Frequenzmuster sind, die gelöscht werden sollen.

Ich habe mir mal das Video angeschaut und den YUV Farbraum mal zerlegt. Ich denke der Fokus sollte auf den Y Kanal gelegt werden. Denn dieser gibt das Muster aus, was ihr bei Videohelp gesucht habt. Während der U und V Kanal absolut ok wirken.

Wenn ich mir die Quelle direkt anschaue bemerke ich eher die Horizontalen Linien darin. Und die sind im Luma Kanal enthalten. Würde da eher sagen das man da nicht sonderlich viel mehr machen kann. Höstens mit nem starken Denoiser das Bild etwas stabilisieren. Ansonsten... kA... ich würde da eher ein ein Interlaced <-> Deinterlaced Verfahren anwenden mit Augenmerk auf den Y Kanal.

Daher mein Vorschlag was das Video auch für mich annehmbar gemacht hat mit etwas Bluring und Schärfen des Y Kanals:

clip0 = DGDecode_mpeg2source("G:\FFmpeg\Neuer Ordner (2)\test lines dvd quality.d2v", info=3)


Y=ColorYUV(clip0,off_u=-256, off_v=-256).ColorYUV(off_u=128, off_v=128)
U=UtoY(clip0)
V=VtoY(clip0)
y=y.blur(1.3).Sharpen(0.5)


YtoUV(U, V, Y)

Der Chroma blieb dabei unangetastet. Der muss ja nicht extra darunter leiden, weil der war ja ok meiner Meinung nach.

Kannst es dir ja mal anschauen.

Mit AVISource ging es bei mir mit YV12 gleich.

Bei FFMS2 musst du den Farbraum erst konvertieren lassen für YV12. Ich denke da wird irgendwas falsch ausgelesen vom Plugin.
Weil wenn du eingibst: ConvertToYV24().ConvertToYV12() oder ConvertToYUY2().ConvertToYV12() oder oder oder... halt nach diesem Muster, und dann geht das auch.

Ist halt ein Bug vermute ich mal ganz stark.

Das hier funktioniert aber Wunderbar:

LoadCPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\Waifu2xAvisynth.dll")
# loading source: F:\TestClips&Co\Test-AC3-5.1.avi, resolution 640x480, Xvid
clip0 = FFVideoSource("F:\TESTCL~1\TEST-A~1.AVI",cachefile="H:\Temp\avi_54a4199c1a3d3b1476ea1d15dc267332_4827_1_0.ffindex",fpsnum=25)
# to be sure


# YUV Aufspalten in Einzel Kanäle und wieder zusammensetzen lassen
Y=ColorYUV(clip0,off_u=-256, off_v=-256).ColorYUV(off_u=128, off_v=128)
U=UtoY(clip0)
V=VtoY(clip0)
[FONT=Verdana]YToUV(U, V, Y)[/FONT]




# scaling
Waifu2x(scale=4).Spline16Resize(1920,1440)
return last

Da ließt er das YV12 richtig ein wieder.

Ich denke mal einfach das es sich in Bezug zu FFMS2 um einen Speicheradressen Problem handelt.

Zitat von LigH

Tut es:

Code

--colorprim <string>    Specify color primaries ['undef']                                  - undef, bt709, bt470m, bt470bg, smpte170m,                                    smpte240m, film, bt2020      --transfer <string>     Specify transfer characteristics ['undef']                                  - undef, bt709, bt470m, bt470bg, smpte170m,                                    smpte240m, linear, log100, log316,                                    iec61966-2-4, bt1361e, iec61966-2-1,                                    bt2020-10, bt2020-12      --colormatrix <string>  Specify color matrix setting ['???']                                  - undef, bt709, fcc, bt470bg, smpte170m,                                    smpte240m, GBR, YCgCo, bt2020nc, bt2020c

Jetzt brauch ich nur noch eine Anleitung, wie man die drei Parameter von ihrem Sinn und Zweck her unterscheidet...

Also bezüglich der Farbmatrix kann man sich zur Kontrolle FFMS2 sich zu Rate ziehen.

Und zwars läd man da die FFMS2.avsi wo man dann im Skript die FFInfo() aufrufen tut. Das encodierte x264 Video muss dann natürlich auch via FFMS2 geladen werden. Sonst geht es nicht.

Und dann kann man sich schon mal den Farbraum bezüglich der Matrix anschauen. Diese werden aus dem Parameter --colormatrix entnommen das man vorher beim x264 Encoder angegeben hat.

Dabei ist z.B. smpte170m das gleiche wie BT.601, bt470bg (Ist ein Update von BT.601) und smpte240m entspricht fast BT.709. BT.2020 gibt es einmal in einer Nicht Konstanten und einmal in einer Konstanten Form.

Das sind erst mal die wichtigsten die häufig genutzt werden denk ich.

Wenn man ohne der Angabe von --colormatrix das Video encodieren tut, steht der Wert auf undef - Undefiniert. x264 encodiert dann in BT.709, nach der Analyse mit FFMS2.

Also ist das schon mal die wichtigste Angabe in Bezug der Farbmatrix.

Mit dieser Angabe sorgt der Encoder dafür das die entsprechenden Koeffizienten der angegeben Farbmatrix nutzen.

--transfer sorgt dafür das die Charakteristika einer Farbmatrix mit dem der angegeben Farbmatrix korrigiert wird. Meist wird da der Luma Bereich gerichtet, wärend der UV Bereich unangetastet bleibt.

Beispiel: Y entsprich nach dem Transfer BT.709 und UV entspricht den der Farbmatrix BT.601
Dann steht da sowas wie:

Transfer characteristics                 : BT.709Matrix coefficients                      : BT.601

Und --colorprim sorgt dafür das die Konvertierung von den Primärfarben in RGB gemacht werden können. Meist wird dann der Wert vom Transfer genommen, da der Helligkeitsanteil (Y) auch der Schlüssel den UV Bereich ist. Sprich damit es im Endeffekt nach der Konvertierung wieder eine PC Range hat, obwohl das Video selbst eine TV Range besitzt.

Wenn alle Werte für diese 3 Angaben auf einen Nenner sind, dann wäre alles korrekt.

Ich denke mal das ich das so richtig aus dem Netz entnehmen konnte. Weiß jetzt aber nicht 100% ob das so stimmt. Auf jedenfall kann ich den Parameter --colormatrix eindeutig belegen mit FFMS2.

Edit:
Habe für das ManualColorMatrix Plugin eine Funktion für AVISynth geschrieben.
Wer es nutzen möchte, nur zu

LoadPlugin(".\Plugins\PlanarTools.dll")
LoadPlugin(".\Plugins\ManualColorMatrix_26.dll")


AVISource("G:\RGB_Video.avi").AssumeFPS(30, 1)


RGBtoYUV(4, "BT.709", false) # Output as YV12 with BT.709 colormatrix and limited (TV) range


# RGBtoYUV
# ---------------------
# mode: 0 - YV24, 1 - RGB24, 2 - RGB32, 3 - YUY2, 4 - YV12
# matrix: "BT.601", "BT.709", "BT.2020", "GBR", "FCC", "YCGCO", "OPP"
# range: false = TV range, true = PC range
# planer: true = YUY2 -> YV16, false = YUY2
# info: true = show info text
# fontsize: font size of info text




Function RGBtoYUV(clip clip0, int "mode", string "matrix", bool "range", bool "planer", bool "info", int "fontsize") {
    mode = Default(mode, 4)
    matrix = Default(matrix, "BT.709")
    range = Default(range, false)
    planer = Default(planer, false)
    info = Default(info, false)
    fontsize = Default(fontsize, 18)

    #BT.2020 , BT.709, BT.601, GBR, FCC, YCgCo and OPP base coefficients
    Kr = (ucase(matrix) == "BT.2020") ? 0.2627 : (ucase(matrix) == "BT.709") ? 0.2126 : (ucase(matrix) == "BT.601") ? 0.299 : (ucase(matrix) == "GBR") ? 0 : (ucase(matrix) == "FCC") ? 0.30 : (ucase(matrix) == "YCGCO") ? 0.25 : (ucase(matrix) == "OPP") ? 1. / 3. : 9
    Kg = (ucase(matrix) == "BT.2020") ? 0.6780 : (ucase(matrix) == "BT.709") ? 0.7152 : (ucase(matrix) == "BT.601") ? 0.587 : (ucase(matrix) == "GBR") ? 1 : (ucase(matrix) == "FCC") ? 0.59 : (ucase(matrix) == "YCGCO") ? 0.50 : (ucase(matrix) == "OPP") ? 1. / 3. : 9
    Kb = (ucase(matrix) == "BT.2020") ? 0.0593 : (ucase(matrix) == "BT.709") ? 0.0722 : (ucase(matrix) == "BT.601") ? 0.114 : (ucase(matrix) == "GBR") ? 0 : (ucase(matrix) == "FCC") ? 0.11 : (ucase(matrix) == "YCGCO") ? 0.25 : (ucase(matrix) == "OPP") ? 1. / 3. : 9

    #Standard coefficients for output
    matrix = (Kr == 9 && Kg == 9 && Kb ==9) ? "BT.709" : matrix
    Kr = (Kr == 9) ? 0.2126 : Kr
    Kg = (Kg == 9) ? 0.7152 : Kg
    Kb = (Kb ==9) ? 0.0722 : Kb

    # Color range
    Rmin = (range == false) ? 16. : 0.
    Rmax = (range == false) ? 235. : 255.
    cRange = (Rmax - Rmin) / 255.
    URange = 256 / 2.
    VRange = 256 / 2.

    UaRange = URange / 256.
    VaRange = Vrange / 256.




    # Colormetry
    # Luma
    # Y channel
    yy = Kr * cRange
    yu = Kg * cRange
    yv = Kb * cRange

    # Chroma
    # Change the value from 0 <-> 1 to -0.5 <-> 0.5
    Pb = UaRange / (1. - Kb)
    Pr = VaRange / (1. - Kr)

    # U channel
    uy = -Kr * Pb * cRange
    uu = -Kg * Pb * cRange
    uv = UaRange * cRange

    # V channel
    vy = VaRange * cRange
    vu = -Kg * Pr * cRange
    vv = -Kb * Pr * cRange

    # Convert video in the colorspace with manual colormatrix from the colormetry
    clip0 = clip0.ManualColorMatrix(mode, yy, yu, yv, uy, uu, uv, vy, vu, vv, Rmin, URange, VRange)

    # Colorspace info for info text output
    co = (mode == 0) ? "YV24" : (mode == 1) ? "RGB24" : (mode == 2) ? "RGB32" : (mode == 3) ? "YUY2" : "YV12"
    co = (mode == 3) ? (planer == true) ? "YV16" : co : co

    # Convert packed format to planar format without changing the pixel values. (YUY2 -> YV16 for avs4x264mod pipeline)
    clip0 = (mode == 3) ? (planer == true) ? clip0.PackedToPlanar() : clip0 : clip0

    range = (range == true) ? "Full (0 - 255) | PC Range" : "Limited (16 - 235) | TV Range"

    matrix = (ucase(matrix) == "GBR") ? "GBR (RGB Matrix)" : matrix

    # Return clip or clip with info text for user
    return (info == true) ? clip0.Subtitle("Colorspace: " + co + "\nMatrix: " + ucase(matrix) + "\nRange: " + string(range) + "\n\nMatrix" \ 
      + "\nY | yy: " + string(yy) + ", yu:  " + string(yu) + ", yv: " + string(yv) + ", yadd = " + string(Rmin)  + ", (" + string(int(Rmin)) + " - " + string(int(Rmax)) + ")" \
      + "\nU | uy: " + string(uy) + ", uu: " + string(uu) + ", uv: " + string(uv) + ", uadd = " + string(URange) + ", (" + string(int(Rmin)) + " - " + string(int(Rmax)) + ")" \
      + "\nV | vy: " + string(vy) + ", vu: " + string(vu) + ", vv: " + string(vv) + ", vadd = " + string(VRange) + ", (" + string(int(Rmin)) + " - " + string(int(Rmax)) + ")", lsp = 1, size = fontsize) : clip0 
}

Aber ich habe es herausbekommen xD

So doof hab ich gar nicht erst gedacht. Aber wenn man das erst mal weiß ist das gut

Die Quelle wie ich dazu gekommen bin habe ich aus einer Leseprobe aus einem E-Book entnommen: https://books.google.de/books?id=MUQ31…epage&q&f=false

Auf Seite 301 (Link führt auf die entsprechende Seite) wird erklärt wie das funktioniert.

Joa. Und die Zuweisungen sind halt die Kern-Koeffizienten für den Luma. Das andere errechnet sich daraus.

Sprich man gibt min. 2 Koeffizienten der jeweiligen Farbmatrix an + den Farbbereich.

Ist ziemlich cool. Weil ich nun damit auch meine RGB Videos in YUV BT.2020 konvertieren kann. Und x264 sollte denk ich auch BT.2020 unterstützen.
Mal sehen wie die 4K Auflösungen damit aussehen.

Ich hab nach langen Suchen etwas gefunden gehabt wodurch ich dann auch endlich die entsprechenden anderen Koeffizienten herbekommen habe.

Für die, denen es interessiert erkläre ich es mal:

Man findet oft nur im Netz nur 2 Koeffizienten für die Farbmatrix.
Daraus kann man dann den 3ten Koeffizienten ermitteln.

Bsp:
Kr = 0.299
Kb = 0.114
Kg = 1 - Kr - Kb = 1 - 0.299 - 0.114 = 0.587

Das sind die Basis Koeffizienten für den Luma (Y) Anteil.

Die Koeffizienten des Luma müssen zusammen 1 ergeben

Für den U und V Bereich des Chroma muss die Summe 0 ergeben.

Bedeutet folgendes Schema für die Matrix:

|Y|    |      0.299   0.587       0.114  |   |  0.299  0.587  0.114 ||U| =  |     -0.299  -0.587  (1 - 0.114) | = | -0.299 -0.587  0.886 ||V|    | (1 - 0.299) -0.587      -0.114  |   |  0.701 -0.587 -0.114 |

Dann muss für Kr und Kb die Scala von 1 auf -0.5 und +0.5 erstellt werden. Das heißt die Werte die in der Matrix von 1 abgezogen wurden eben, sind die 0.5 Werte. Die beiden daneben stehenden Zahlen müssen dann zusammen -0.5 ergeben. Sodass halt am Ende 0 herauskommt.

Das macht man wie folgt:

Pb_diff = 0.5 / (1 - 0.114)Pr_diff = 0.5 / (1 - 0.299)

Aus diesen Werten kann man dann die fehlenden Koeffizienten ermitteln:

|Y|   |   0.299              0.587              0.114            |   |  0.299     0.587     0.114    ||U| = | (-0.299 * Pb_diff) (-0.587 * Pb_diff)   0.5              | = | -0.168736 -0.331264  0.5      ||V|   |   0.5              (-0.587 * Pr_diff) (-0.114 * Pr_diff) |   |  0.5      -0.418688 -0.081312 |

Diese 9 Koeffizienten in der Matrix werden dann noch mit der Farb-Range multipliziert.
Diese ergibt sich aus:

RangeMin = 16RangeMax = 235Range = (RangeMax - RangeMin) / 255 = 219 / 255

Bedeutet für TV Range (16 - 235) ergibt sich der Wert: 0,85882352941176470588235294117647...

Und dann hat man alle Werte für das Plugin ManualColorMatrix

In AVISynth sieht das so aus dann:

# BT.601 TV Range
Kr = 0.299
Kg = 0.587 # = 1 - Kr - Kb
Kb = 0.114




Rmin = 16.
Rmax = 235.




Range = (Rmax - Rmin) / 255.




yy = Kr * Range
yu = Kg * Range
yv = Kb * Range




Pb = 0.5 / (1. - Kb)
Pr = 0.5 / (1. - Kr)




uy = -Kr * Pb * Range
uu = -Kg * Pb * Range
uv = 0.5 * Range




vy = 0.5 * Range
vu = -Kg * Pr * Range
vv = -Kb * Pr * Range




BlankClip().Subtitle("yy = " + string(yy) + ", yu = " + string(yu) + ", yv = " + string(yv) \
      + "\nuy = " + string(uy) + ", uu = " + string(uu) + ", uv = " + string(uv) \
      + "\nvy = " + string(vy) + ", vu = " + string(vu) + ", vv = " + string(vv), lsp = 1)




ManualColorMatrix(0, yy, yu, yv, uy, uu, uv, vy, vu, vv, Rmin, 128.0, 128.0)

Hallo,

ich habe ein Problem in Bezug auf das Plugin ManualColorMatrix.

Und zwars suche ich die Formeln zur Errechnung der Matrix Koeffizienten.

Ich habe schon angefangen, aber die Werte für den UV Bereich kann ich irgendwie nicht ermitteln. Und zwars orientiere ich mich im Thread vom Plugin an das Beispiel mit der RGB -> YV24 Konvertierung mit BT.601 range 16-235

Daraus würde ich gerne ein Skript schreiben der mir anhand der 3 Kern Koeffizienten die anderen Koeffizienten errechnet.

Hier mal das was ich bisher habe (Als Kommentar daneben die Werte die rauskommen sollten):

#BT.601Kr = 0.299
Kg = 0.587
Kb = 0.114




Range = 219. / 255 # TV Range = 219. / 255 (16 - 235) ; PC Range = 255. / 255 (0 - 255)




yy = Range * Kr
yu = Range * Kg
yv = Range * Kb




#Formel ?
uy = 0 #-0.148223
uu = 0 #-0.290992
uv = 0 #0.439215




vy = 0 #0.439215
vu = 0 #-0.367789
vv = 0 #-0.071426




BlankClip().Subtitle("yy = " + string(yy) + ", yu = " + string(yu) + ", yv = " + string(yv) \
                           + "\nuy = " + string(uy) + ", uu = " + string(uu) + ", uv = " + string(uv) \
                           + "\nvy = " + string(vy) + ", vu = " + string(vu) + ", vv = " + string(vv), lsp = 1)




# -> http://forum.doom9.org/showthread.php?t=161777
# ManualColorMatrix(0, yy, yu, yv, uy, uu, uv, vy, vu, vv, 16.0, 128.0, 128.0)

Suchen tuhe ich die Formeln um die Koeffizienten für uy, uu, uv, vy, vu und vv zu errechnen aus den Werten die mir bekannt sind. Hoffe das mir da jemand helfen kann.

Aha. ok. Frage mich jetzt echt was ich falsch gemacht habe xD Ok. Dann werde ich noch mal ALAC testen

ALAC kann ich aber nicht zusammen mit einem Video Stream in einem MP4 Kontainer unterbringen.

Dazu hatte ich mir was zusammen gestellt gehabt wo man das vergleichen konnte.

http://www.mediafire.com/download/zrer5…sizer_Test_2.7z

Das Ganze sieht dann so aus: Bild1, Bild2

AVSPmod sollte auf dem Rechner drauf sein dafür

Und dann kann man anhand von Slidern halt die Tests durchführen und vergleichen.

Dabei ist:
pic_test: Das Quellmaterial. Bild, Video, etc.
Resizer: Der Resizer Typ. 14 Stück sind im Skript dort untergebracht.

Dann folgen die Stützwerte mit dem Namen der Skalierer wo sie zutreffen.

p: für den GaussResize
b und c: für BicubicResize

Und Text size: Für die Info Anzeige.

Die Info Anzeige oben rechts besteht aus:
Quellauflösung zu Zielauflösung, gefolgt vom Namen des Resizertyps und den jeweiligen Einstellungsparametern, sofern vorhanden.

In Zeile 22 im Skript sollte die Zielauflösung entsprechend eingetragen werden.

Und dann kann man halt vergleichen.

Zoom sollte unbedingt auf 100% gestellt werden, oder höher für nähere Untersuchung ob sich Artefakte oder Ringe bilden.

Ist gewiss noch erweiterbar. Sollte aber fürs erste reichen hoffe ich.:D

Zitat

Klappt denn der Encoder bei Dir mit Datei Input der gepiped wird?

Nee, klappt bei mir auch nicht. Komisch. Obwohl das so als Beispiel in der Hilfe sogar steht.

Zitat

b. wenn Du raw "s16le" nimmst, solltest Du dem Encoder vermutlich auch mitteilen, dass der Input als RAW ankommt,...

Habe ich versucht, nur leider ohne Erfolg. Kann es sein das die Hilfe nur für Linux bzw. Mac zutreffen? Also das dort die Pipe dann so funktioniert? Weil dann würde das einiges erklären, da ja die Windows Pipe ja auch nicht gerade so toll ist wie die von Linux z.B.

Den Source Code für mp4alsRM23 habe ich auch schon gefunden:
https://code.google.com/p/opensourceli…23.zip&can=2&q=

Sogar mit nem Patch:
https://code.google.com/p/opensourceli….patch&can=2&q=

Da ich kein Visual Studio habe bzw. überhaupt etwas um das zu kompilieren, denke ich das sich das vllt ein Entwickler bzw. jemand der die nötigen Programme hat es kompilieren könnte. Weil das wäre wirklich cool wenn das Tool mit einer Pipeline richtig laufen würde.

Zitat

Würde spontan sagen: Frag am Besten mal bei denen direkt nach.

Werde ich auf jeden Fall demnächst machen.

Der Encoder wäre halt ne schöne Sache, da man ihn dann in VDub hätte unterbringen können oder auch noch ganz woanders.
Weil wenn ich ein Video mache mit x264, dann mache ich oft auch FLAC Audio in einem MKV Container.
Aber MKVs wieder in einem Schnittprogramm zu laden ist wieder nicht so toll.
Daher habe ich gedacht das ich mit ALS Audio Verlustfrei komprimiere und zusammen mit dem Video und MP4 Box zusammen muxe. Sprich eine MP4 Variante zur MKV. Weil doch FLAC nicht in MP4 geht.

Hat ja auch soweit alles funktioniert. Nur möchte ich den Ablauf etwas optimieren und nicht jedesmal alles in PCM wandeln und dann noch mal in ALS. Ich meine... mit dem FLAC Encoder ging ja auch ne Pipeline aufzubauen und mit NeroAAC auch. Von daher... muss es doch auch irgendwie mit diesem Encoder gehen xD

Hallo ihr guten Leute aus dem Gleitz Forum

Und zwars habe ich ein Problem eine Pipeline zwischen FFMpeg und MP4alsRM23 aufzubauen.

Mein aktueller Versuch war bissher:

ffmpeg -i "Test.aac" -c:a pcm_s16le -f wav - | mp4alsRM23.exe - "neu.als"

Dabei schmeißt er mir folgende Fehlermeldung raus:

Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument

Dann habe ich versucht das irgendwie als RAW zu übergeben mittels:

ffmpeg -i "Test.aac" -c:a pcm_s16le -f s16le - | mp4alsRM23.exe - "neu.als"

Dies quittiert er mir dann mit:

av_interleaved_write_frame(): Invalid argument
size=       4kB time=00:00:00.02 bitrate=1411.2kbits/s
video:0kB audio:4kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
Conversion failed!

Ich habe keine Ahnung wie ich da eine funktionierende Pipeline reinbekomme. Laut der Hilfe zu mp4alsRM23 sollte die Funktion des stdin mit - für In- Und Output möglich sein.

Den Audio-Encoder habe ich hier gedownloaded: http://www.nue.tu-berlin.de/menue/forschun…s/parameter/en/

Unter dem Punkt: Reference Software

Ich hoffe ihr könnt mir da irgendwie weiterhelfen.

Weil wenn das irgendwie machbar ist, könnt ich das auch in VirtualDub nutzen. Das wäre richtig nice

Ich hatte mal das Problem bei Mencoder bezogen auf den Zsnes Emulator aber das ich die Farben drehen musste. Weil Mencoder mit BGR gearbeitet hat, wenn es sich um RAW handelte und der Encoder aber RGB haben wollte. Sprich im Endeffekt einfach mal schauen ob es so ist. Weil dann musste mal von BGR nach RGB konvertieren bei Mencoder.
Ist jetzt nur so eine fixe Idee. Kann ja bei dir ja was ganz anderes sein.

Also kann ich beruhigt auf der AVISynth MT Schiene weiterarbeiten fürs erste. Jedenfalls bis AVISynth+ MT Programmiertechnisch weiter ist und stabil läuft.

Weil MT Nutzung ist unverzichtbar, gerade da der Skripterzeuger den ich habe auf Youtubes Let's Play Scene zugeschnitten ist und die Leute schon ohnehin rumnörgeln das ihr Rechner nicht weitläufig CPUmäßig ausgelastet wird beim Encodieren.

Mit MT ist der Prozess schon wesentlich schneller.

Nur wenn AVISynth+ MT irgendwann Brauchbar und Stabil daherkommt... wann auch immer dies sein möge ..., dann wäre es schon Nice ein entsprechendes Anhängsel in mein Programm einzubinden, der dann bei der Skripterstellung sich auf die MT Nutzung von AVS+ bezieht. Und die ist ja wie ihr sagt ganz anders.

Sprich Momentan steuere ich die MT Nutzung wie folgt:
[Blockierte Grafik: http://fs2.directupload.net/images/150820/24wskvyq.png]

Je Position ein SetMTMode Befehl im Skript. Wird keine Angabe gemacht wie bei den letzten drei, so wird der letzte SetMTMode verwendet für die entsprechenden Filter. Im Startpost hatte ich diesbezüglich alle angeschaltet.
MemoryMax steht noch über den SetMTMode und die Threadangabe gilt nur dem erst gesetzten SetMTMode Aufruf.

So der jetzige Stand.

Bei AVISynth+ müsst ich dann Quasi für jeden Filter der im Skript verwendet wird quasi eine Mode Angabe machen mit abschließender Prefetch Angabe für die Threadnutzung.

Quasi so wie ich das halt schon als Beispiel hatte hier

Wäre das so korrekt in meinem Denk-Beispiel?

Die Sache ist die... falls es mal soweit sein sollte... dann ist die Funktion schon mal soweit da.

MT kann ich ja auch komplett Abschalten in mein Programm.
[Blockierte Grafik: http://fs2.directupload.net/images/150820/qve6hwnd.png]
Dann ist MT komplett raus aus dem Skript.

Ich habe das auch schon so gemacht das wenn AVISynth MT nicht installiert ist, sondern das normale, das man die MT Funktion im Programm selbst nicht nutzen kann. Sprich die ist dann ausgegraut.

Ich kann auch zwischen AVISynth+, AVISynth+ MT, AVISynth und AVISynth MT unterscheiden lassen und entsprechend die Skripte darauf abstimmen.

Daher war es nur so ein Gedanke das entsprechende Skript was ich im Startpost hatte mit der MT Funktion speziell auf AVS+ abzuändern. Hätte dafür auch ein extra Fenster noch mal gebaut.

Nur müsst ich dann wissen wie es funktioniert entsprechend. Wenn mein Denk-Beispiel-Skript so klappen sollte wie es gedacht war, dann könnt ich das entsprechend so bauen.

Mein Programm analysiert halt die fest installierte AVISynth Version. Entsprechend darauf arbeitet dann mein Programm auch. Daher auch die Idee mit dem AVS+ MT.