Videokonvertierung, Handbrake, Videotoolbox: Anfängerfrage

[lisanet]

@jteschner @Difool und alle interessierten Mitleser:

Ich habe für fx-upscale soeben eine neue Version veröffentlicht: 2.1.0-skl

Die wesentlichen Änderungen, neben kleineren Code-Änderungen, sind

• eine crop Option --crop width:height:left:top. Das cropping wird vor dem upscalen vorgenommen.
• soweit als sinnvoll, sind nun alle Parameter in einer kurzen und einer langen Variante vorhanden, einheitlich mit jeweils - und --
• ein neues Flag: --verbose zeigt die Parameter des Videos und verwendeten Parameter des Tools an.
• Für B-frames und prio_speed ist der default nun auf yes gesetzt.
• das README wurde deutlich erweitert und ergänzt.

-> https://github.com/lisanet/fx-upscale

Edit:

README mit MarkEdit erstellt

 

[jteschner]

Toll - nur dumm, dass ich gerade kein Video zur Hand habe, das ein Croppen erfordert.
Aber bei nächster Gelegenheit ...

 

[lisanet]

... was haltet ihr von der nun neuen Art der Ausgabe von Infos?

Ich bin mir da nicht so recht sicher, ob es sinnvoller ist, standardmäßig die Infos zu unterdrücken und nur auf expliziten Wunsch mit -v/--verbose anzuzeigen, oder umgekehrt, die Infos immer anzuzeigen und auf Wunsch mit sowas wie --silent/--quiet zu unterdrücken.

Zudem habe ich die Infozeilen dynamisch gestaltet: Infos zu bframes, gop und prio_speed werden nur ausgegeben, wenn diese aktiv / gesetzt sind.

Da fällt mir gerade ein, dass ich dieses dynamische Anzeigen auch fürs croppen machen sollte, damit es stimmig bleibt.... Also wird es wohl recht kurzfristig eine Version 2.1.1 geben müssen.

 

[jteschner]

... was haltet ihr von der nun neuen Art der Ausgabe von Infos?

Ich bin mir da nicht so recht sicher, ob es sinnvoller ist, standardmäßig die Infos zu unterdrücken und nur auf expliziten Wunsch mit -v/--verbose anzuzeigen, oder umgekehrt, die Infos immer anzuzeigen und auf Wunsch mit sowas wie --silent/--quiet zu unterdrücken.

Zudem habe ich die Infozeilen dynamisch gestaltet: Infos zu bframes, gop und prio_speed werden nur ausgegeben, wenn diese aktiv / gesetzt sind.

Teste ich etwas später - muss nun erst etwas "in die Bewegung" ...

 

[jteschner]

... was haltet ihr von der nun neuen Art der Ausgabe von Infos?

Ich bin mir da nicht so recht sicher, ob es sinnvoller ist, standardmäßig die Infos zu unterdrücken und nur auf expliziten Wunsch mit -v/--verbose anzuzeigen, oder umgekehrt, die Infos immer anzuzeigen und auf Wunsch mit sowas wie --silent/--quiet zu unterdrücken.

Zudem habe ich die Infozeilen dynamisch gestaltet: Infos zu bframes, gop und prio_speed werden nur ausgegeben, wenn diese aktiv / gesetzt sind.

Da fällt mir gerade ein, dass ich dieses dynamische Anzeigen auch fürs croppen machen sollte, damit es stimmig bleibt.... Also wird es wohl recht kurzfristig eine Version 2.1.1 geben müssen.

So. Getestet - einmal mit -v und einmal ohne.
Die Ausgabe mit -v bei mir:

mbp14:jt - /Users/jt/Downloads/fx-upscale_test
> fx-upscale -i input.mp4 -v -s 2.0 -q 60 -b 1 --prio_speed yes -o output.mp4
i Video duration: 00:45:44.539, total frames: 137227
i Upscaling: 960x540 to 1920x1080
i Codec: hevc, bframes, quality 60
i Encoding time: 00:08:56.343, fps: 255.86
✓ Video successfully upscaled!

und ohne:

mbp14:jt - /Users/jt/Downloads/fx-upscale_test
> fx-upscale -i input.mp4 -s 2.0 -q 60 -b 1 --prio_speed yes -o output.mp4
✓ Video successfully upscaled!

Mein Urteil: die Detailausgabe durch -v sollte Default sein, da es ja nur ein paar informative Zeilen und keine seitenweisen Infos sind. Wer auch diese unterdrücken will, könnte ja dann --quiet nutzen. Würde dann so auch ffmpeg irgendwie entsprechen.

Crop kann ich in Ermangelung von Quellmaterial gerade nicht testen.
Edit: Errorhandling konnte ich allerdings testen, da sich die Parameter wohl etwas geändert haben und mein vorgefertigtes Kommando nicht mehr funktionierte Klappte nach meinen Anpassungen aber sehr gut. Wie immer: top Arbeit!

 

[lisanet]

Mein Urteil: die Detailausgabe durch -v sollte Default sein, da es ja nur ein paar informative Zeilen und keine seitenweisen Infos sind. Wer auch diese unterdrücken will, könnte ja dann --quiet nutzen. Würde dann so auch ffmpeg irgendwie entsprechen.

hhmm, das mit ffmpeg ist ein gutes Argument.

Crop kann ich in Ermangelung von Quellmaterial gerade nicht testen.

Infos zum genauen croppen sind noch nicht implementiert, nur die Anzeige bei Upscaling: wird dann von

i Upscaling: 960x540 to 1920x1080

mit --crop 960:400:0:70 sich auf

i Upscaling: 960x400 to 1920x1080

ändern.

Ich habe an so eine Ausgabe gedacht, wenn cropping aktiv ist

>./fx-upscale -i in.mp4 --crop 960:400:0:70  -o out.mp4 -y  -q 60 -v
i Video duration: 00:01:39.799, total frames: 2495
i Cropping: 960x540 to 960x400 at (0,70)
i Upscaling: 960x400 to 1920x800
i Codec: hevc, bframes, quality 60
i Encoding time: 00:00:11.283, fps: 221.12
✓ Video successfully upscaled!

Ein Tipp: du kannst -b 1 --prio_speed yes weg lassen, da beides standardmäßig aktiv ist. Die "dynamische" Anzeige geht dabei wie folgt: "bframes" wird nur angezeigt wenn sie aktiv sind (also standardmäig), "Prioritize speed: no" wird nur angezeigt, wenn eseben auf no gesetzt wird.

Der Grund für den Unterschied war für mich, dass bframes ein Parameter des Codecs ist und es dort sinnvoller erscheint "bframes" anzuzeigen oder eben weg zu lassen, wenn sie nicht vorhanden sind. "no bframes" anzuzeigen wäre IMO recht unglücklich und würde zu Verunsicherungen führen.

Anders bei prio_speed. Das ist IMO eine sinnvolle Vorgabe und sollte, wenn deaktiviert, eben deutlich angezeigt werden.

 

[jteschner]

hhmm, das mit ffmpeg ist ein gutes Argument.

Dann habe ich ja auch mal eine gute Idee gehabt ;-)

Ich habe an so eine Ausgabe gedacht, wenn cropping aktiv ist

>./fx-upscale -i in.mp4 --crop 960:400:0:70  -o out.mp4 -y  -q 60 -v
i Video duration: 00:01:39.799, total frames: 2495
i Cropping: 960x540 to 960x400 at (0,70)
i Upscaling: 960x400 to 1920x800
i Codec: hevc, bframes, quality 60
i Encoding time: 00:00:11.283, fps: 221.12
✓ Video successfully upscaled!

OK. Sehr gut.

Ein Tipp: du kannst -b 1 --prio_speed yes weg lassen, da beides standardmäßig aktiv ist. Die "dynamische" Anzeige geht dabei wie folgt: "bframes" wird nur angezeigt wenn sie aktiv sind (also standardmäig), "Prioritize speed: no" wird nur angezeigt, wenn eseben auf no gesetzt wird.

Ja, war mir im Nachhinein nach einem genaueren Blick auf die "Hilfe" auch aufgefallen. Und ich habe meine eigene Doku/Hilfe zu fx-upscale (in Obsdian ) schon angepasst.

Der Grund für den Unterschied war für mich, dass bframes ein Parameter des Codecs ist und es dort sinnvoller erscheint "bframes" anzuzeigen oder eben weg zu lassen, wenn sie nicht vorhanden sind. "no bframes" anzuzeigen wäre IMO recht unglücklich und würde zu Verunsicherungen führen.

Anders bei prio_speed. Das ist IMO eine sinnvolle Vorgabe und sollte, wenn deaktiviert, eben deutlich angezeigt werden.

Verstehe.

 

[lisanet]

... und schon umgesetzt.

Version 2.1.1-skl ist nun online mit den folgenden Änderungen:

• neue Option --quiet um die Info-Ausgabe zu unterdrück, die nun standardmäßig aktiviert ist. Dafür fällt dann -v/--verbose weg
• Infos zu crop Parametern wird nun ebenso ausgegeben.

-> https://github.com/lisanet/fx-upscale

 

[jteschner]

... und schon umgesetzt.

Version 2.1.1-skl ist nun online mit den folgenden Änderungen:

• neue Option --quiet um die Info-Ausgabe zu unterdrück, die nun standardmäßig aktiviert ist. Dafür fällt dann -v/--verbose weg
• Infos zu crop Parametern wird nun ebenso ausgegeben.

-> https://github.com/lisanet/fx-upscale

Und schon ausprobiert. Geht (natürlich)
Zwei Sachen, die ich mal ausprobiert habe.
Ich habe dabei ein vergleichbares Quell-Video in h264 wie oben genutzt.

1. Alles auf Default

fx-upscale -i input.mp4
i Video duration: 00:45:44.539, total frames: 137227
i Upscaling: 960x540 to 1920x1080
i Codec: hevc, bframes, quality auto

"Quality Auto" ergibt dann allerdings ein "Mammut-Video": aus 370MB wurden 4GB -mit einer Bitrate >11MBit/s
Das finde ich etwas viel wenn nicht sogar unnötig und sieht irgendwie nach -q 90 oder so aus.
Auf jeden Fall würde ich das so niemals verwenden.
Du hast da bestimmt eine knappe Erklärung

2. Quality gesetzt

Video duration: 00:45:44.539, total frames: 137227
i Upscaling: 960x540 to 1920x1080
i Codec: hevc, bframes, quality 58

Entsprach voll meinen Erwartungen. Top Quali, Ziel-Video: knapp 500MB (eher klein)

Frage/Idee:
Sollte/Könnte man nicht den festen Scale-Faktor von 2.0 im Default nicht besser kalkulieren lassen, so dass immer 1920x1080 (FHD) bzw. eine optimale genäherte Größe rauskommt? Die Formeln dazu wären ja da ...
Damit liesse sich dann sogar eine kinderleichte Schnellaktion für den Finder erstellen. Oder man müsste in der Schnellaktion die Kalkulation machen - was ja auch gehen sollte.

 

[lisanet]

"Quality Auto" ergibt dann allerdings ein "Mammut-Video": aus 370MB wurden 4GB -mit einer Bitrate >11MBit/s
Das finde ich etwas viel wenn nicht sogar unnötig und sieht irgendwie nach -q 90 oder so aus.
Auf jeden Fall würde ich das so niemals verwenden.
Du hast da bestimmt eine knappe Erklärung

das ist halt der default Wert, der in Videotoolbox kodiert ist. So war es auch im original Project eingestellt. Deswegen habe ich es drin gelassen und im README erwähnt, das -q 60 der empfohlene Wert wäre.

Ich bin aber auch zwiegespalten, ob -q 60 nicht sinnvoller wäre als default. Also: überzeuge mich noch ein klein wenig mehr Der Aufwand im Code ist minimal. Es ist mehr Arbeit das README anzupassen.

Sollte/Könnte man nicht den festen Scale-Faktor von 2.0 im Default nicht besser kalkulieren lassen, so dass immer 1920x1080 (FHD) bzw. eine optimale genäherte Größe rauskommt?

Hmm, nachdem 4 K immer weiter verbreitet ist, denke ich dass ein default auf FullHD nicht so ganz zeitgemäß mehr wäre, auch wenn ich selbst nur FullHD nutze. Da finde ich dann den Factor von 2.0 ganz charmant, weil er PAL und NTSC Videos auf in etwa FullHD und FullHD auf 4K bringt.

Wenn das Ausgangsvideo nicht anamorph ist, dann reicht ja fürs upscaling auf FullHD bei 4:3 Videos ein --height 1080 und bei 16:9 Videos ein --width 1920. Der andere Parameter wird proportional hoch gerechnet.

Bei ananmorph codierten Videos, was eigentlich nur gerippte DVDs sind, muss man halt das Seitenverhältnis des Films heran ziehen und beides, --width und --height, angeben, was aber auch keine große Kunst ist: 1440x1080 bei 4:3 und 1920x1080 bei 16:9. Andere Formate gibt es eh nicht auf DVD

Bei croppen muss man halt etwas rechnen, ist aber auch kein Aufwand.

Übrigens:

Das croppen habe ich deswegen programmiert, weil ich "Ben Hur" aus 1959 in der originalen Kinofassung sehr "wide" finde mit 1920x688 (2,76:1) Und da wollte ich einfach mal eine zweite Version erstellen in 1920x800. Also musste ich erst an den Seiten croppen und dann upscalen. Ähnlich ging es mir mit dem Film "The Creator", der auch ebenso so "wide" mit 2,76:1 aufgenommen ist. Auch den habe ich so gecropped.

 

[jteschner]

das ist halt der default Wert, der in Videotoolbox kodiert ist. So war es auch im original Project eingestellt. Deswegen habe ich es drin gelassen und im README erwähnt, das -q 60 der empfohlene Wert wäre.

Ich bin aber auch zwiegespalten, ob -q 60 nicht sinnvoller wäre als default. Also: überzeuge mich noch ein klein wenig mehr Der Aufwand im Code ist minimal. Es ist mehr Arbeit das README anzupassen.

Verstehe den Hintergrund. Tja, überzeugen ... aus der Sicht eines Anwenders finde ich halt eher "erschreckend", was da an Dateigröße trotz hevc herauskommt. Das hätte ich niemals erwartet und so wie ich würden sich andere fragen, was das soll und dem tollen Tool ggf. die Schuld geben.
Also ich fände -q 60 als Default super und wäre zudem noch der gleiche Default wie bei Handbrake.

Hmm, nachdem 4 K immer weiter verbreitet ist, denke ich dass ein default auf FullHD nicht so ganz zeitgemäß mehr wäre, auch wenn ich selbst nur FullHD nutze. Da finde ich dann den Factor von 2.0 ganz charmant, weil er PAL und NTSC Videos auf in etwa FullHD und FullHD auf 4K bringt.

Nachvollziehbar. Da habe ich zu sehr auf den eigenen Bedarf geschaut.
Nur aus Sicht eines "einfachen Anwenders" wäre es schon toll, wenn man zB einfach sagen könnte: -s fhd oder -s 4k und das Tool kalkuliert selbst.
Aber ich verstehe schon was du erklärt hast und es ist ja auch für jemanden mit Grundverständnis und Taschenrechner keine Raketenwissenschaft.
Ich dachte halt an eine Finder-Schnellaktion, die mir ohne zu rechnen mal eben FHD-Videos erzeugt. Ich habe da noch ein paar "krumme" Videoformate aber auch 1280x720. Da passt ein Scalingfaktor von 2.0 nicht wirklich.

 

[lisanet]

Verstehe den Hintergrund. Tja, überzeugen ... aus der Sicht eines Anwenders finde ich halt eher "erschreckend", was da an Dateigröße trotz hevc herauskommt. Das hätte ich niemals erwartet und so wie ich würden sich andere fragen, was das soll und dem tollen Tool ggf. die Schuld geben.
Also ich fände -q 60 als Default super und wäre zudem noch der gleiche Default wie bei Handbrake.

hhmm, vielleicht nehme ich eher 58 als default. Wenn ich im README schreibe, dass alles über 56 gute Ergebnisse liefert und ann 60 als empfohlenen Wert mache, passt das nich so ganz zusammen. Irgendwie stimmiger wäre zu schreiben, alles ab 58 wäre gut und das auch als default nehmen. (ist zudem auch mein default mir meinen ffmpeg-scripten )

Nur aus Sicht eines "einfachen Anwenders" wäre es schon toll, wenn man zB einfach sagen könnte: -s fhd oder -s 4k und das Tool kalkuliert selbst.

Da es aber auch anamorph codierte Videos gibt (DVD-Rips) geht das nicht so einfach mit dem Hochrechnen. Und wenn das Video schon gecroppt wurde, wirds nochmals etwas aufwendiger. Wie ich die Seitenverhältnisse aus den Metadaten auslesen kann, weiß ich auch nicht.

Ich dachte halt an eine Finder-Schnellaktion, die mir ohne zu rechnen mal eben FHD-Videos erzeugt. Ich habe da noch ein paar "krumme" Videoformate aber auch 1280x720. Da passt ein Scalingfaktor von 2.0 nicht wirklich.

... solange du keine DVD-Rips, also keine anamorphen Videos, hast, kannst du doch einfach --width 1920 bei 16:9 nehmen und --height 1080 bei 4:3. Du musst nur feststellen, welches Seitenverhältnis vorliegt. Und das programmtechnisch zu ermitteln geht nur dann verlässlich, wenn du die Metadaten raus kriegst. In einem shell script kannst du einfach ffmpeg aufrufen. In einem swift-Programm musst du da erst mal ne API dazu finden, falls es eine gibt.

 

[jteschner]

hhmm, vielleicht nehme ich eher 58 als default. Wenn ich im README schreibe, dass alles über 56 gute Ergebnisse liefert und ann 60 als empfohlenen Wert mache, passt das nich so ganz zusammen. Irgendwie stimmiger wäre zu schreiben, alles ab 58 wäre gut und das auch als default nehmen. (ist zudem auch mein default mir meinen ffmpeg-scripten )

58 nehme ich auch bei ffmpeg - das passt schon.
bei Handbrake lasse ich einfach den Default auf 60. HB nehme ich aber nur noch selten.

Da es aber auch anamorph codierte Videos gibt (DVD-Rips) geht das nicht so einfach mit dem Hochrechnen. Und wenn das Video schon gecroppt wurde, wirds nochmals etwas aufwendiger. Wie ich die Seitenverhältnisse aus den Metadaten auslesen kann, weiß ich auch nicht.

... solange du keine DVD-Rips, also keine anamorphen Videos, hast, kannst du doch einfach --width 1920 bei 16:9 nehmen und --height 1080 bei 4:3. Du musst nur feststellen, welches Seitenverhältnis vorliegt. Und das programmtechnisch zu ermitteln geht nur dann verlässlich, wenn du die Metadaten raus kriegst. In einem shell script kannst du einfach ffmpeg aufrufen. In einem swift-Programm musst du da erst mal ne API dazu finden, falls es eine gibt.

Verstehe. Ich schaue mal wie ich es mache - im Zweifel einfach manuell.

Danke fürs Feedback

 

[jteschner]

Da es aber auch anamorph codierte Videos gibt (DVD-Rips) geht das nicht so einfach mit dem Hochrechnen. Und wenn das Video schon gecroppt wurde, wirds nochmals etwas aufwendiger. Wie ich die Seitenverhältnisse aus den Metadaten auslesen kann, weiß ich auch nicht.

... solange du keine DVD-Rips, also keine anamorphen Videos, hast, kannst du doch einfach --width 1920 bei 16:9 nehmen und --height 1080 bei 4:3. Du musst nur feststellen, welches Seitenverhältnis vorliegt. Und das programmtechnisch zu ermitteln geht nur dann verlässlich, wenn du die Metadaten raus kriegst. In einem shell script kannst du einfach ffmpeg aufrufen. In einem swift-Programm musst du da erst mal ne API dazu finden, falls es eine gibt.

Ich war mal etwas neugierig und habe trotz meiner vollkommen rudimentären Kenntnissen in Swift, ChatGPT ein Programm erstellen lassen, das ...
- über die Option -i ein Videofile einliest
- unter Nutzung von Funktionen aus Foundation, AVFoundation und CoreMedia
- zB folgende Ausgabe liefert

> ./videoinfo.swift -i '/Volumes/video/Serie/Stargate Atlantis (2004)/Staffel 1/Stargate Atlantis S01E01E02.mp4'
📺 Videoinformationen:
──────────────────────────────
Datei: /Volumes/video/Serie/Stargate Atlantis (2004)/Staffel 1/Stargate Atlantis S01E01E02.mp4

Codec-Trackgröße (Pixelmatrix vor SAR/Rotation): 576x320
Nach Rotation (Track-Orientierung angewendet): 576x320
Pixel Aspect Ratio (SAR): 1:1
Displaygröße (nach SAR): 576x320
Display Aspect Ratio (DAR): 1.800:1

Zielgröße (max Full HD 1920×1080, Seitenverhältnis beibehalten): 1920x1067
Skalierungsfaktor: 3.333

Schon mal interessant als erster Versuch (vor allem da ich wahrscheinlich erst in ein paar Jahren in der Lage wäre so etwas überhaupt selbst zu schreiben) - wenn auch nicht perfekt, denn die Prio liegt wohl auf der Ziel-Breite und nicht der Höhe.

Ich schicke dir das Script gern falls du Interesse hast und reinschauen möchtest. Wenn nicht, auch kein Problem ...

 

[lisanet]

oh ja, das wäre schon mal ein Ausgangspunkt.

Wichtig ist, dass alle möglichen Fälle berechnet werden können. Dabei gibt es 2 Quell SAR (1:1 und anamorph), 2 Größenänderungen (crop/ nicht crop) und 2 Ziel SAR (1:1 und anamoph), also 8 Varianten.

Ich habe aktuell all diese 8 Fälle mittlerweile umgesetzt, was die manuelle Angabe von width und/oder heigth oder scale betrifft. Das wären

1) Quell-SAR 1:1

a) SAR 1:1 -> scale -> SAR 1:1
b) SAR 1:1 -> crop -> scale -> SAR 1:1
c) SAR 1:1 -> scale -> SAR anamorph
d) SAR 1:1 -> crop -> scale -> SAR anamorph

2) Quell-SAR anamorph

a) SAR anamorph -> scale -> SAR anamorph
b) SAR anamorph -> crop -> scale -> SAR anamorph
c) SAR anamorph -> scale -> SAR 1:1
c) SAR anamorph -> crop -> scale -> SAR 1:1

Man kann es sich etwas vereinfachen, wenn man unterstellt, das es keine "Hochkant"-Videos gibt, als Quell-DAR immer größer 1:1 ist.

Wenn du also weiter etwas an der Berechnung arbeiten willst, dann hast du damit so die wensentlichen Parameter. Und wenn du da ein Funktion raus kriegst, die als Ergebnis die neue Höhe und Weite zurück gibt, als CGSize(width: w, height: h) dann wäre das richtig super. Und es wäre ja auch eine gute Idee um weiter in Swift einzusteigen

Ich werde aber natürlich auch mich selbst mal daran versuchen.

PS: Stargate Atlantis ... Das werde ich mir gönnen, wenn ich mit SG-1 demnächst durch bin (bin da bei S08E04)

Edit: für dich zur Info:
Um die obigen Fälle zu berechnen (ohne die symbolischen maximalen Größen) kann man dabei folgende Formel nutzen

Ziel-SAR = Quell-SAR * input-Size / Ziel-DIM

Wobei input-Size die Pixel-Dimensionen sind, die direkt vor dem scaling vorhanden sind, also entweder die originalen Pixel-Dimensionen oder die nach dem croppen.

Ich habe die souren bereits auf github veröffetlicht. Diese Berechnung findest du in UpscalingExportSession.swift in Zeile 336 - 345. Da kannst du dir ja auch vielleicht etwas aus dem Code abschauen.

 

[jteschner]

oh ja, das wäre schon mal ein Ausgangspunkt.

Wichtig ist, dass alle möglichen Fälle berechnet werden können. Dabei gibt es 2 Quell SAR (1:1 und anamorph), 2 Größenänderungen (crop/ nicht crop) und 2 Ziel SAR (1:1 und anamoph), also 8 Varianten.

Ich habe aktuell all diese 8 Fälle mittlerweile umgesetzt, was die manuelle Angabe von width und/oder heigth oder scale betrifft. Das wären

1) Quell-SAR 1:1

a) SAR 1:1 -> scale -> SAR 1:1
b) SAR 1:1 -> crop -> scale -> SAR 1:1
c) SAR 1:1 -> scale -> SAR anamorph
d) SAR 1:1 -> crop -> scale -> SAR anamorph

2) Quell-SAR anamorph

a) SAR anamorph -> scale -> SAR anamorph
b) SAR anamorph -> crop -> scale -> SAR anamorph
c) SAR anamorph -> scale -> SAR 1:1
c) SAR anamorph -> crop -> scale -> SAR 1:1

Man kann es sich etwas vereinfachen, wenn man unterstellt, das es keine "Hochkant"-Videos gibt, als Quell-DAR immer größer 1:1 ist.

Wenn du also weiter etwas an der Berechnung arbeiten willst, dann hast du damit so die wensentlichen Parameter. Und wenn du da ein Funktion raus kriegst, die als Ergebnis die neue Höhe und Weite zurück gibt, als CGSize(width: w, height: h) dann wäre das richtig super. Und es wäre ja auch eine gute Idee um weiter in Swift einzusteigen

Ich werde aber natürlich auch mich selbst mal daran versuchen.

PS: Stargate Atlantis ... Das werde ich mir gönnen, wenn ich mit SG-1 demnächst durch bin (bin da bei S08E04)

Edit: für dich zur Info:
Um die obigen Fälle zu berechnen (ohne die symbolischen maximalen Größen) kann man dabei folgende Formel nutzen

Ziel-SAR = Quell-SAR * input-Size / Ziel-DIM

Wobei input-Size die Pixel-Dimensionen sind, die direkt vor dem scaling vorhanden sind, also entweder die originalen Pixel-Dimensionen oder die nach dem croppen.

Ich habe die souren bereits auf github veröffetlicht. Diese Berechnung findest du in UpscalingExportSession.swift in Zeile 336 - 345. Da kannst du dir ja auch vielleicht etwas aus dem Code abschauen.

Ich schicke dir mal die GPT sourcen - habe gerade wenig Zeit, um alles genau durchzuarbeiten und zu verstehen ...

 

[jteschner]

Wichtig ist, dass alle möglichen Fälle berechnet werden können. Dabei gibt es 2 Quell SAR (1:1 und anamorph), 2 Größenänderungen (crop/ nicht crop) und 2 Ziel SAR (1:1 und anamoph), also 8 Varianten.

Ich habe aktuell all diese 8 Fälle mittlerweile umgesetzt, was die manuelle Angabe von width und/oder heigth oder scale betrifft. Das wären

1) Quell-SAR 1:1

a) SAR 1:1 -> scale -> SAR 1:1
b) SAR 1:1 -> crop -> scale -> SAR 1:1
c) SAR 1:1 -> scale -> SAR anamorph
d) SAR 1:1 -> crop -> scale -> SAR anamorph

2) Quell-SAR anamorph

a) SAR anamorph -> scale -> SAR anamorph
b) SAR anamorph -> crop -> scale -> SAR anamorph
c) SAR anamorph -> scale -> SAR 1:1
c) SAR anamorph -> crop -> scale -> SAR 1:1

Das muss ich als Anfänger erst mal verstehen. Aber ich werde mich bemühen :-/

Wenn du also weiter etwas an der Berechnung arbeiten willst, dann hast du damit so die wensentlichen Parameter. Und wenn du da ein Funktion raus kriegst, die als Ergebnis die neue Höhe und Weite zurück gibt, als CGSize(width: w, height: h) dann wäre das richtig super. Und es wäre ja auch eine gute Idee um weiter in Swift einzusteigen

Ja, wobei ich ja selbst den Code nicht erstellt habe. Aber ein Einstieg ist es wirklich.

PS: Stargate Atlantis ... Das werde ich mir gönnen, wenn ich mit SG-1 demnächst durch bin (bin da bei S08E04)

Witzig: SG-1 schaue ich auch gerade ... SG Atlantis hab ich bereits durch ... immer wieder schön.

Insgesamt:
Puh, harter Stoff für mich.
Hoffentlich erwartest du nicht, dass ich da in den nächsten 6 Monaten eine Lösung auf den Tisch lege. Mir fehlt noch viel zu viel Basiswissen im Bereich Video. Geschweige denn Swift ...

 

[lisanet]

Hoffentlich erwartest du nicht, dass ich da in den nächsten 6 Monaten eine Lösung auf den Tisch lege. Mir fehlt noch viel zu viel Basiswissen im Bereich Video. Geschweige denn Swift ...

nee, keine Sorge. Ich kann mir das gut vorstellen, wenn da beides, Video und Swift, zusammen kommt. Ich tu mich da auch gerade etwas schwer, weil ffmpeg die Dinge etwas anders bezeichnet, als das die API von Apple tun.

Was in ffmpeg SAR (sample aspect ratio) heißt, ist in Swift "pixel aspect ratio". was man dann gerne mit PAR abkürzt. Das aber war (ist?) zumindest früher in ffmpeg die Bezeichnung für die Pixel-Auflösung, die wiederum in swift "pixel dimensions" lautet. ffmpeg DAR (display aspect ratio) heißt in Swift "presentation dimensions". Und das macht mich gerade wahnsinnig.

 

[jteschner]

nee, keine Sorge. Ich kann mir das gut vorstellen, wenn da beides, Video und Swift, zusammen kommt. Ich tu mich da auch gerade etwas schwer, weil ffmpeg die Dinge etwas anders bezeichnet, als das die API von Apple tun.

Das beruhigt mich

Was in ffmpeg SAR (sample aspect ratio) heißt, ist in Swift "pixel aspect ratio". was man dann gerne mit PAR abkürzt. Das aber war (ist?) zumindest früher in ffmpeg die Bezeichnung für die Pixel-Auflösung, die wiederum in swift "pixel dimensions" lautet. ffmpeg DAR (display aspect ratio) heißt in Swift "presentation dimensions". Und das macht mich gerade wahnsinnig.

Ja, das Leben wäre langweilig ...
Und was hältst du grundsätzlich von dem Code, den GPT erzeugt hat? Geht bestimmt alles besser und kürzer ...

 

[lisanet]

... hhmm, der Code von ChatGPT ist schon gut und ausführlich und, wenn man bedenkt, dass auch eine Eingabe entgegen genommen wird, das Video gelesen wird, dann ist das schon gut.

Die Berechnung selbst, ist ok, aber das geht auch ohne den scale Faktor und vorallem auch ohne .naturalSize. .naturalSize kann bei anamorphen Videos Probleme bereiten

Also für den Prompt, macht es genau das was du wolltest.

Allerdings ist bspw die Art des Einlesens der Commandozeilen-Parameter halt auch nur für diesen Fall angepasst. Wenn du das als Beispiel nimmt, wie man das macht, dann wird es bei mehreren Parametern, wie bei fx-upscale, eher sehr unübersichtlich und aufwendig.

Und das ist IMO auch das Problem, wenn man anhand von Code einer KI was erlernen will. Für den konkreten Prompt sehr gut, aber zum erweitern wird es zäh und oft sehr schwer. Und du lernst nicht unbedingt spezifische APIs kennen oder bereits vorhandene Swift-Module. Besser finde ich es, nachdem man die Grundlagen einigermaßen beherrscht, wenn man sich Code von anderen Entwicklern ansieht und versucht den nachzuvollziehen. Da kann dann ein KI sehr gut helfen: Code-Teil kopieren und fragen was das bedeutet / macht / auslöst.

So habe ich bspw bei fx-update das Modul zum Parsen der Kommandozeile kennen gelernt. Wenn man das mal einigermaßen verstanden hat, dann ist das schon echt genial. Sieh die mal den Code auf github an.

Ich habe mittlerweile auch eine Funktion geschrieben, die die Berechnungen durchführt und für alle (sinnvollen) Varianten funktioniert, egal ob 1:1 oder anamorph, ob crop oder nicht, ob horizontales oder vertikales Video. Was keinen Sinn ergibt bei diesen symbolischen Größen sind die o.g Fälle 1c + 1d und 2c und 2d. Da müsste man immer noch zusätzlich angeben, ob die Berechnung sich an Höhe oder Breite orientieren soll. Und dann kann man gleich die Größen direkt angeben. Das sind aber auch sehr spezielle Fälle und IMO kaum bis nicht praxisrelevant.

Ich schick dir den Code per PM. Kannst ja mal ansehen. Alles weitere dann vielleicht per PM. Den Code kompilierst du mit

swiftc name.swift -o name

und dann aufrufen mit eben

./name