Videokonvertierung, Handbrake, Videotoolbox: Anfängerfrage

[lisanet]

Mit sudo > Passwort ging's:

... tja, da habe ich das README mal wieder nicht sauber geschrieben. (ich mag einfach keine Dokus schreiben, lieber Code.) Allerdings denke ich mir auch, dass jemand der github repos nutzt und source code selbst kompiliert, auch ein paar Kleinigkeiten weiß, wann man was als admin macht und wann nicht github ist nichts für "Nur-User". Für "Nur-User" gibt es vorkompilierte binaries.

Und unabhängig von meiner Doku ist es ja auch durchaus möglich, dass man /usr/local/bin user-writeable macht, wenn man eh Software entwickelt und der einzige User auf dem System ist.

Vielleicht sollte ich daher den ganzen Teil, wie man die sourcen kompiliert komplett entfernen. Sonst kommt irgendjemand noch drauf und meldet ein issue, weil bei ihm auf einen nagelneuen Mac noch kein Verzeichnis "/usr/local/bin" existiert.

Ich werde mir das mal überlegen.

Allerdings bekomme ich nun immer solche Meldungen:

~ % fx-upscale -i /Users/difool/Movies/hurt-dog.mp4 -q 80 -o output_4k.mov
Error: Unknown option '-i'
Usage: fx-upscale <url> [--width <width>] [--height <height>] [--codec <codec>]
  See 'fx-upscale --help' for more information.

Und du hast ganz sicher mein github repo ausgechecked? Die Zeile

fx-upscale <url> [--width <width>] [--height <height>] [--codec <codec>]

ist nämlich nur in der ursprünglich originalen Version enthalten.

Die option -i war mein allererster commit und stammt von 10.09. noch bevor ich hier im Forum überhautp was zu dem Tool geschrieben habe.

Also, einfach wirklich mein repo auschecken / nochmals neu ausschecken, nicht das originale repo, oder mit "git pull" die aktuelle Version holen (... nein, ich werde im README keine Anleitung zu git einfügen )

 

[jteschner]

Was ich heute mal als "Praxistest" tun werde:
ich werde einen Vergleich mit dem bereits verwendeten "Atlantis Video 576x300" starten, gerade weil es auch wirklich keine Top-Quali hat und ich daher denke, dass Unterschiede noch eher auffallen werden:
1- Video "as is" in h264
2- Video mit ffmpeg konvertiert in h265 mit üblichen Parametern (Handbrake nehme ich da nicht, da ich dem nicht so ganz traue)
3- Video mit fx-upscale auf fhd und h265 hochgerechnet

Und die drei dann über ATV/Plex auf meinem TV anschauen - nur doof, dass man die drei nicht parallel schauen kann. Aber mal sehen wie mein Eindruck ohne Pixelpeeping ist.

So, das habe ich nun getestet.
Zusammmengefasst: sichtbare bis deutliche Unterschiede.

Alles aus Plex heraus auf dem ATV abgespielt, ATV auf 4k-DolbyVision-60Hz mit TV verbunden, an den Einstellungen des TV nix verdreht

1- Video 45min, 576x320, h264 in mkv container, Größe 216MB:
Quali: na ja, erwartete Auflösung, wenig Artefakte, freiwillig würde ich sowas nur im Not-/Ausnahmefall schauen, aber ist schaubar ohne Nervenzucken

2- Video aus 1- mit ffmpeg umkodiert in h265 (-c:v hevc_videotoolbox -bf 1 -vtag hvc1 -prio_speed 1 -q:v 58 -c:a copy), Größe 107MB:
Quali: deutlich schlechter, etwas verwaschen, mehr sichtbare Artefakte, hätte ich so nicht erwartet, wird aber wohl mit dem schon suboptimalen Quellmaterial zusammenhängen und liesse sich bestimmt durch einen höheren -q:v verbessern, würde ich aber sofort wieder löschen.

3- Video aus 1- (nach umkopieren der Streams in mp4 container) mit fx-upscale (-t fhd) in 1920x1066 h265 hochgerechnet, Größe 340MB:
Quali: sichtbar besser als Video aus 1-, und schon gar nicht zu vergleichen mit 2- , kein Burner aber schaubar, fx-upscale lohnt sich

Dies mal ein kurzes erstes Ergebnis. Zumindest würde dieses bestätigen, das fx-upscale anders arbeitet als ein upscaling im ATV, aber Wunder darf man natürlich nicht erwarten

 

[lisanet]

- Video aus 1- mit ffmpeg umkodiert in h265 (-c:v hevc_videotoolbox -bf 1 -vtag hvc1 -prio_speed 1 -q:v 58 -c:a copy), Größe 107MB:
Quali: deutlich schlechter, etwas verwaschen, mehr sichtbare Artefakte, hätte ich so nicht erwartet, wird aber wohl mit dem schon suboptimalen Quellmaterial zusammenhängen und liesse sich bestimmt durch einen höheren -q:v verbessern, würde ich aber sofort wieder löschen.

Das hat gar nichts mit -q zu tun. Auch ffmpeg und fx-upscale nutzen den exakt gleichen Videoencoder mit exakt gleichen Parametern.

Du hast mit der ffmpeg-Zeile ja auch gar nicht skaliert, sondern nur neu kodiert. Da wird das Video im besten Fall visuell gleich, aber nicht "besser". Da müsstest du schon skalieren, nachschärfen, vorher glätten etc. Und das mit fürs Video passenden Werten. Ein one-size-fits-all haben die Filter von ffmpeg nur eingeschränkt. Mit -q:v hat das so gut wie nichts zu tun

 

[jteschner]

Das hat gar nichts mit -q zu tun. Auch ffmpeg und fx-upscale nutzen den exakt gleichen Videoencoder mit exakt gleichen Parametern.

Du hast mit der ffmpeg-Zeile ja auch gar nicht skaliert, sondern nur neu kodiert. Da wird das Video im besten Fall visuell gleich, aber nicht "besser". Da müsstest du schon skalieren, nachschärfen, vorher glätten etc. Und das mit fürs Video passenden Werten. Ein one-size-fits-all haben die Filter von ffmpeg nur eingeschränkt. Mit -q:v hat das so gut wie nichts zu tun

Ich habe ja auch keine *bessere* Quali erwartet - wo soll sie auch herkommen? Und skalieren wollte ich auch nicht - das kam ja in 3-. Soviel weiss ich inzwischen auch. Mir ging es ausschliesslich um das neu-kodieren (mache ich immer so mit den Mediathek-Videos, die ja in h264 kommen -> etwas Platz sparen bei nahezu gleicher Quali) - nur war das ein Schuss in den Ofen.

 

[lisanet]

mache ich immer so mit den Mediathek-Videos, die ja in h264 kommen -> etwas Platz sparen bei nahezu gleicher Quali

ah, ok.

Sind die Mediathek-Videos tatsächlich nur in so einer geringen Auflösung vorhanden? Das ist ja noch nicht mal SD

 

[jteschner]

Sind die Mediathek-Videos tatsächlich nur in so einer geringen Auflösung vorhanden? Das ist ja noch nicht mal SD

Nein, nein. Die gibt es in drei Größen: 576i, 720p und 1080p
Filme hole mir meist in 1080p, Serien/Episoden meist in 720p - und dann eben per Finder-Schnellaktion in hevc konvertiert und somit ca. 50% Platz gespart.
Diese "Stargate Atlantis" Videos kommen von einem Kollegen, der mir einen Gefallen tun wollte. Ich hatte ihm gesagt "DVD-Quali 576i ist ok" und da er null Ahnung hat, wurde das 576x320 mit irgendeinem komischen tool ... Eigentlich wollte ich sie schon löschen, habe sie aber noch auf dem NAS liegen.

 

[lisanet]

Ich hatte ihm gesagt "DVD-Quali 576i ist ok" und da er null Ahnung hat, wurde das 576x320 mit irgendeinem komischen tool ...

das könnte durchaus Handbrake gewesen sein und er hat deinen Wunsch wohl zu wörtlich genommen. Wenn man in Handbrake als Auflösungslimit DVD nimmt und dann nicht "optimale Größe" wählt, sondern eigene Werte will, dann wird bei Eingabe von 576 als Breite automatisch 324 errechnet. Wenn er dann noch irgendwo gelesen hat, das man auf Vielfach von 8 runden sollte und niemals hochskalieren, dann kommt 576x320 raus. Früher hat Handbrake auch von sich aus schon auf 8 gerundet.

 

[jteschner]

@lisanet Nachdem du nun fx-update in einer neuen Funktion u.a. mit der neuen target-Option "hd 1280x720" veröffentlicht hast, war ich mal wieder neugierig und habe einen "unsinnigen" Test gemacht :
Ich wollte mal wissen, wie sich fx-update verhält, wenn ich ein h264-Video in 1280x720 einfach nur in h265 konvertiere ohne zu upscalen.
Ausgangsmaterial:
Download aus ÖRR-Mediathek, Dateigröße 801MB, Info aus ffmpeg: Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1280x720 [SAR 1:1 DAR 16:9], 1975 kb/s, 50 fps, 50 tbr, 12800 tbn, start 0.080000 (default)

Test 1: > fx-upscale -i input.mp4 -t hd
Ergebnis, Dateigröße 453MB :
Video duration: 00:50:31.840, total frames: 151592
Upscaling: 1280x720 to 1280x720
Codec: hevc, bframes, quality 58
Encoding time: 00:04:44.663, fps: 532.53

Test 2: > ffmpeg -i input.mp4 -c:v hevc_videotoolbox -bf 1 -vtag hvc1 -prio_speed 1 -q:v 58 -c:a copy output.mp4
Ergebnis, Dateigröße 419MB :
frame=151588 fps=564 q=-0.0 Lsize= 409298KiB time=00:50:31.78 bitrate=1105.9kbits/s speed=11.3x elapsed=0:04:28.54

Test 3: > fx-upscale -i input.mp4 -t fhd
Ergebnis, Dateigröße 707MB :
Video duration: 00:50:31.840, total frames: 151592
Upscaling: 1280x720 to 1920x1080
Codec: hevc, bframes, quality 58
Encoding time: 00:09:22.092, fps: 269.69

Ich weiss gar nicht genau was ich erwartet habe, war ja auch nur ein Versuch - aber ich wollte zumindest mal wissen, ob fx-update vielleicht sogar noch schneller arbeitet als ffmpeg wenn es "nur" konvertieren muss. Tut es offensichtlich nicht. Ich denke mal, weil es die gleichen Routinen nutzt ...
Aber egal - Für das, was es programmiert ist -> "upscaling", zeigt allein Test 3 schon wie fix es ist - bei exzellenter Ausgabequalität!

 

[lisanet]

Was der Test 1 soll, ist mir nicht so recht klar.

Bei fx-update läuft jeder frame, egal welche Ausgangs- und Zielgröße _immer_ durch die gleiche Pipeline. Da gibt es keinen shortcut. Okay, das Metalframework hat dann wenig bis keinen Aufwand der Skalierung von 1280x720 auf 1280x720. Aber es wird eben jedes einzelne Frame geladen, dekomprimiert, in buffer kopiert, an Metal übergeben, zurück kopiert, in hevc umgewandelt und dann wieder geschrieben.

fx-update kann nicht "nur" konvertieren. Es wird immer via Metal "skaliert"

Dein Test 2 macht dies nicht. da fehlt der gesamte Aufwand, von in buffer kopieren, an Metal übergeben, skalieren auf gleiche Größe, zurück kopieren.

Wenn du vergleichen willst, dann musst du in ffmpeg auch skalieren, also "-vf scale=1280:720". Erst dann wird es vergleichbar. Ob ffmpeg einen shortcut nimmt, wenn es identische Größen erkennt, weiß ich nicht. Ich kann mit bei ffmpeg, das aber gut vorstellen, da die Entwickler auf sowas extrem Wert legen. Da wird kaum irgendwo im Code ne extra Runde gedreht. ffmpeg ist hoch optimiert.

Und bei Test 3, solltes du auch mal mit ffmpeg skalieren, also "-vf scale=1920:1080" und dann nicht nur Geschwindigkeit sondern auch Qualität vergleichen.

 

[lisanet]

@jteschner und allen anderen die mit fx-udate arbeiten können:

Wie würdest du folgenden Funktion beurteile? Sinnvoll, überflüssig, zu komplex, nur manuell, oder "best guess"?

Hier die Situation:

Jedes Video ist in einem bestimmten Farbraum produziert. In deinem o.g Beispiel, siehst du das an dem Teil yuv420p(tv, bt709, progressive)

Dabei ist "bt709" der entsprechende Farbraum, der für HD-Content (alles ab 1280x720) angwendet wird. Eigentlich müsste ffmpeg anzeigen "bt709,bt709,bt709", da der Farbraum immer durch 3 "Komponenten" bestimmt wird: colorspace (oder auch matrix genannt), color primaries ("Eckwerte für rot, grün, blau) und color_transfer (wie werden die RGB-Pixel in Signal für den TV umgewandelt)

Bei SD-Kontent ist es etwas komplexer (historisch bedingt). Eine PAL-DVD wird standardmäßig einkleinwenig anders mit Farbraum-Angaben versehen als eine NTSC-DVD. Konkret "smpte170m, bt709, bt470bg"

Noch unglücklicher ist es, wenn man eine DVD rippt (mit bspw MakeMKV). Viele DVD haben diese Farbraumdaten gar nicht gespeichert und MakeMKV übernimmst sie auch gar nicht. Ergebnis: nach einem Rip kann man nur raten (meist anhand der Bildfrequenz)

Noch schriller wird es, wenn man selbst mit bspw einer Capture-Card (wie EyeTV) TV-Signale aufnimmt. Da kann dann auch mal ein Spielfilm, obwohl deutsche Produktion und 25 fps, also PAL, mit NTSC-Farbraum versehen sein....) Alles schräg

Das "Problem" ist nun folgendes:

Ein Player (Apple-TV, FireTV, Nvidia Shield etc) kann nun zwei Wege gehen

a) er übernimmt die Angaben im Video und konvertiert selbst den Farbraum korrekt um und gibt ihn dann erst aus.
b) er unterstellt bt709, da das ja der Standard ist, und reicht die Pixel einfach durch, was immer passiert, wenn keine Angaben da sind.

Bei a) passt alles. Bei b) werden die Farben verfälscht.

Zwischen SD und HD ist diese Verfälschung aber sehr subtil und man merkt das nur, wenn man direkt vergleicht und weiß worauf man achten soll. Rot und Hauttöne wirken etwas weniger intensiv, etwas "blasser", grün kann auch etwas mehr hervortreten (macht die Haut etwas "krank")

Ein Vergleich geht nicht mit IINA, VLC oder anderen Playern, die auf mpc oder ffmpeg basieren. Die kriegen alle das Farbraummanagement nicht korrekt hin. Nur der Quicktime-Player schafft das.

Man ist also auf der sicheren Seite, wenn fx-upscale die Farbraumkonvertierung immer vornimmt. Rein software-mäßig kriege ich das hin und es klappt auch perfekt.

Tja, dazu muss aber fx-upscale bekannt sein, was das Original besitzt. Da wie oben beschrieben, das nicht immer eindeutig erkennbar ist, bin ich mir nicht im Klaren, wie ich es implementieren soll, wenn das Original keine Daten dazu hat.

a) automatisch nach "best guess": Nach fps zwischen PAL und NTSC unterscheiden, sollte meist klappen, aber halt nicht immer. Besonders bei so Freaks wie mir, die den PAL-Speedup wieder rückgängig machen, um das Original-Format zu erhalten.
Das würde bedeuten, dass die User glauben, fx-upscale macht es korrekt, was aber eben nicht immer so ist. Finde ich nicht so toll. Dafür kann es aber auch von "Nicht-Freaks" angewandt werden

b) Möglichkeit "PAL" oder "NTSC" als Parameter vorzugeben. Das würde dann sicher bei vielen Usern, mehr Fragen aufwerfen, als das es nützt. Auch nicht so toll. Aber wer sich auskennt, kriegt immer korrekte Farbkonvertierung (auch wenn man "Fehler" eh ohne direkten Vergleich im Grunde nicht sieht)

c) Im README den User darauf hinweisen, dass das Original richtig getagged sein muss (dann geht es nämlich definitiv immer korrekt und automatisch). Mit ffmpeg kann man das nachträglich auch machen. Aber da bin ich mir auch wiederum sicher, dass es kaum jemand weiß wie. Und zudem müsste dann immer vor dem upscalen erst mit ffmpeg gearbeitet werden (wäre aber lossless)

d) ???

Also: was würdest du tun, was würdest du für gut empfinden? Hast du alternative Ideen?

Die gleichen Fragen gehen natürlich auch an alle Mitleser hier (in der Hoffnung, dass noch jemand anderes sich einwenig mit diesen Dingen auskennt und auch Wert darauf legt)

 

[jteschner]

Was der Test 1 soll, ist mir nicht so recht klar.

Bei fx-update läuft jeder frame, egal welche Ausgangs- und Zielgröße _immer_ durch die gleiche Pipeline. Da gibt es keinen shortcut. Okay, das Metalframework hat dann wenig bis keinen Aufwand der Skalierung von 1280x720 auf 1280x720. Aber es wird eben jedes einzelne Frame geladen, dekomprimiert, in buffer kopiert, an Metal übergeben, zurück kopiert, in hevc umgewandelt und dann wieder geschrieben.

fx-update kann nicht "nur" konvertieren. Es wird immer via Metal "skaliert"

Dein Test 2 macht dies nicht. da fehlt der gesamte Aufwand, von in buffer kopieren, an Metal übergeben, skalieren auf gleiche Größe, zurück kopieren.

Wenn du vergleichen willst, dann musst du in ffmpeg auch skalieren, also "-vf scale=1280:720". Erst dann wird es vergleichbar. Ob ffmpeg einen shortcut nimmt, wenn es identische Größen erkennt, weiß ich nicht. Ich kann mit bei ffmpeg, das aber gut vorstellen, da die Entwickler auf sowas extrem Wert legen. Da wird kaum irgendwo im Code ne extra Runde gedreht. ffmpeg ist hoch optimiert.

Und bei Test 3, solltes du auch mal mit ffmpeg skalieren, also "-vf scale=1920:1080" und dann nicht nur Geschwindigkeit sondern auch Qualität vergleichen.

Ja, du hast ja Recht - ich sagte ja im Eingang: "ein unsinniger Test" - in 1, 2, 3 kam es mir nur mal auf die Geschwindigkeiten an. Einen Qualitätsvergleich fx-upscale vs ffmpeg hatte ich doch schon mal gemacht: Ergebnis: fx-upscale gewinnt ganz klar.
Aber danke für die Erklärungen.
Deine nächste Anfrage schaue ich mir morgen mal an - aktuell bin ich zu müde

 

[jteschner]

@jteschner und allen anderen die mit fx-udate arbeiten können:

Wie würdest du folgenden Funktion beurteile? Sinnvoll, überflüssig, zu komplex, nur manuell, oder "best guess"?

Hier die Situation:

Jedes Video ist in einem bestimmten Farbraum produziert. In deinem o.g Beispiel, siehst du das an dem Teil yuv420p(tv, bt709, progressive)

Dabei ist "bt709" der entsprechende Farbraum, der für HD-Content (alles ab 1280x720) angwendet wird. Eigentlich müsste ffmpeg anzeigen "bt709,bt709,bt709", da der Farbraum immer durch 3 "Komponenten" bestimmt wird: colorspace (oder auch matrix genannt), color primaries ("Eckwerte für rot, grün, blau) und color_transfer (wie werden die RGB-Pixel in Signal für den TV umgewandelt)

Bei SD-Kontent ist es etwas komplexer (historisch bedingt). Eine PAL-DVD wird standardmäßig einkleinwenig anders mit Farbraum-Angaben versehen als eine NTSC-DVD. Konkret "smpte170m, bt709, bt470bg"

Noch unglücklicher ist es, wenn man eine DVD rippt (mit bspw MakeMKV). Viele DVD haben diese Farbraumdaten gar nicht gespeichert und MakeMKV übernimmst sie auch gar nicht. Ergebnis: nach einem Rip kann man nur raten (meist anhand der Bildfrequenz)

Noch schriller wird es, wenn man selbst mit bspw einer Capture-Card (wie EyeTV) TV-Signale aufnimmt. Da kann dann auch mal ein Spielfilm, obwohl deutsche Produktion und 25 fps, also PAL, mit NTSC-Farbraum versehen sein....) Alles schräg

OK. Halbwegs verstanden. Habe ich allerdings nie drauf geachtet. Ist schon recht "Advanced" und nix für Anfänger

Das "Problem" ist nun folgendes:
...

Tja, dazu muss aber fx-upscale bekannt sein, was das Original besitzt. Da wie oben beschrieben, das nicht immer eindeutig erkennbar ist, bin ich mir nicht im Klaren, wie ich es implementieren soll, wenn das Original keine Daten dazu hat.

Guter Punkt.

a) automatisch nach "best guess": Nach fps zwischen PAL und NTSC unterscheiden, sollte meist klappen, aber halt nicht immer. Besonders bei so Freaks wie mir, die den PAL-Speedup wieder rückgängig machen, um das Original-Format zu erhalten.
Das würde bedeuten, dass die User glauben, fx-upscale macht es korrekt, was aber eben nicht immer so ist. Finde ich nicht so toll. Dafür kann es aber auch von "Nicht-Freaks" angewandt werden

Finde ich als "Anfänger" auch nicht so dolle. Sollte es nicht klappen, dann sind die Augen groß und man weiss nicht was passiert ist.

b) Möglichkeit "PAL" oder "NTSC" als Parameter vorzugeben. Das würde dann sicher bei vielen Usern, mehr Fragen aufwerfen, als das es nützt. Auch nicht so toll. Aber wer sich auskennt, kriegt immer korrekte Farbkonvertierung (auch wenn man "Fehler" eh ohne direkten Vergleich im Grunde nicht sieht)

Stimmt.

c) Im README den User darauf hinweisen, dass das Original richtig getagged sein muss (dann geht es nämlich definitiv immer korrekt und automatisch). Mit ffmpeg kann man das nachträglich auch machen. Aber da bin ich mir auch wiederum sicher, dass es kaum jemand weiß wie. Und zudem müsste dann immer vor dem upscalen erst mit ffmpeg gearbeitet werden (wäre aber lossless)

Hmmmm, OK. Was heisst "lossless"? zig-GB Daten? Dann könnte das auch zu Problemen führen.

d) ???

Also: was würdest du tun, was würdest du für gut empfinden? Hast du alternative Ideen?

Was hältst du von:
d) Du ermittelst bei starten ob eine automatische Anpassung möglich/sinnvoll/... ist oder nicht zB wie in c) genannt: sind die Parameter gesetzt? Oder hast du eine mögliche "Diskrepanz" ermittelt zu einem Standard (gemäß 1) oder 2))?
In diesem Fall könntest du den Ablauf anhalten und dem User mitteilen:
"Pass auf, ich habe folgendes ermitteln können: Dein Video hat das Farbformat .... Ich kann für es für dich automatisch ändern in: .... Willst du, dass ich das tue? (Y/n)"
oder/und
"Pass auf, die Parameter für den Farbraum sind bei deinem Video nicht gesetzt. Ich habe aber ermittelt, dass es folgendermaßen sein könnte: ... Du kannst nun abbrechen (q), die Parameter mittels ffmpeg selbst setzen und fx-update neu starten oder die von mir ermittelten Werte passen und ich soll die Konvertierung automatisch vornehmen (Y). lässt den Farbraum wie er ist. (q, Y, n)"
Und dann je nach Entscheidung weiter.

So oder ähnlich - ist natürlich alles mit der heißen Nadel formuliert - geht bestimmt besser/einfacher/klarer.
Das mit ffmpeg und Parameter setzen ist für mich noch unklar. Ist das einfach oder schwierig? Wie lang dauert sowas? Lässt sich das nicht auch automatisieren? ...

Das fände ich als Nutzer besser. Doof wäre es wenn da was geändert würde und ich ich das eigentlich gar nicht will. Vielleicht finde ich ja die "schrägen Farben" gerade richtig? Farben sind schon eine "sensible Geschichte" - da würde ich nix automatisch und ohne bewusste User-Entscheidung tun.

 

[Difool]

b) Möglichkeit "PAL" oder "NTSC" als Parameter vorzugeben. Das würde dann sicher bei vielen Usern, mehr Fragen aufwerfen, als das es nützt. Auch nicht so toll. Aber wer sich auskennt, kriegt immer korrekte Farbkonvertierung (auch wenn man "Fehler" eh ohne direkten Vergleich im Grunde nicht sieht)

Wenn aber ein aktives weglassen von „PAL“ oder „NTSC“ nichts bewirkt und die Vorgabe übernommen wird – so what?
Wen es bis hierhin nicht kümmerte, den kümmerts auch dann nicht.
Wer aber es angeben möchte, kann.
Ist doch super.

Ich habe gestern Nacht bsw. mal, weil ich die Serie gerade wiedermal schaue, mich daran gemacht und die Folgen von M*A*S*H von SD auf FHD gepimpt.
Erst mit „hevc“ jetzt mal mit „h264“ – mit „h264“ bekommt es etwas mehr Tiefenschärfe und klarere Farben, was allerdings mögliche Fehlerpixel ebenso hervorhebt.

Auch haben meine Vorlagen keine Farb-Angaben, so auch deren upscales nicht:
(könnte ich aber etwas setzen, wie „bt709“ wäre das wohl auch nicht schlecht.)



Konvertieren lassen habe ich es via batch im Ordnerpfad im Terminal:

hevc

for i in *.mp4; do fx-upscale -i $i -t fhd; done

h264

for i in *.mp4; do fx-upscale -i $i -c h264 -t fhd; done

hevc - batch mit temp dir

mkdir "temp" && for i in *.mp4; do mv $i temp && fx-upscale -i temp/$i -t fhd && rm -rf temp/$i; done

Bei der Variante „hevc - batch mit temp dir“ bekomme ich es leider nicht hin, dass die Originale im parent-Verzeichnis bleiben
und nur die konvertierten files in dem temp-Ordner landen. Irgendwie vertüddel ich den „copy“-Befehl immer oder er wird ignoriert.
Mit obigen „batch mit temp dir“ geht es aber auch; man muss nur daran denken, dass man die Originale einmal vorher dupliziert,
da die Originale dann automatisch gelöscht werden, wenn jeweils die Konvertierung fertig ist.

edit: @lisanet
Ach, eine Volume Anpassung in deinem fx-upscale fände ich auch noch superb.
Bei den M*A*S*H Episoden ist der Ton recht leise – dies müsste ich sonst auch erst über ffmpeg machen lassen, richtig?

 

[lisanet]

OK. Halbwegs verstanden. Habe ich allerdings nie drauf geachtet. Ist schon recht "Advanced" und nix für Anfänger

erst mal Danke, das du dich damit befasst. Das hilft mir schon sehr. Danke.

Hmmmm, OK. Was heisst "lossless"? zig-GB Daten? Dann könnte das auch zu Problemen führen.

Das taggen mit ffmpeg ist lossless, d.h. das Video und das Audio werden nicht angefasst, sondern einfach nur kopiert. Genau so wie auch beim remuxen. Ich weiß nur nicht wie ich das anders nennen soll.

Was hältst du von:
d) Du ermittelst bei starten ob eine automatische Anpassung möglich/sinnvoll/... ist oder nicht zB wie in c) genannt: sind die Parameter gesetzt? Oder hast du eine mögliche "Diskrepanz" ermittelt zu einem Standard (gemäß 1) oder 2))?

ich kann ermitteln ob Parameter für den Farbraum vorhanden sind und falls ja, auch welche. Wenn ich aber was ermittle, muss man diesen Werten zwingend vertrauen, da es zwar Standards gibt, aber die nicht immer eingehalten werden.

In diesem Fall könntest du den Ablauf anhalten und dem User mitteilen:
"Pass auf, ich habe folgendes ermitteln können: Dein Video hat das Farbformat .... Ich kann für es für dich automatisch ändern in: .... Willst du, dass ich das tue? (Y/n)"
oder/und

Da geht so nicht.

Wenn Farbraum-Parameter vorhanden sind, muss denen geglaubt werden und somit kann die Farbraumkonvertierung einfach durchgeführt werden. Der Zielfarbraum ist ja durch die Zielgröße (hd, fhd etc) vorgegeben.

"Pass auf, die Parameter für den Farbraum sind bei deinem Video nicht gesetzt. Ich habe aber ermittelt, dass es folgendermaßen sein könnte: ... Du kannst nun abbrechen (q), die Parameter mittels ffmpeg selbst setzen und fx-update neu starten oder die von mir ermittelten Werte passen und ich soll die Konvertierung automatisch vornehmen (Y). lässt den Farbraum wie er ist. (q, Y, n)"
Und dann je nach Entscheidung weiter.

Interaktiv finde ich suboptimal, da es batch-Abluaf erschwert und ggf. auch unmöglich macht.

Wenn ich "nur" eine Info-Ausgabe mache in der Art "Das Origianlvideo hat keine Farbrauminformatinen" oder so, bin ich wieder bei den Usern, die das komplett überfordert. Fürm "Freaks" ist das toll.

So oder ähnlich - ist natürlich alles mit der heißen Nadel formuliert - geht bestimmt besser/einfacher/klarer.
Das mit ffmpeg und Parameter setzen ist für mich noch unklar. Ist das einfach oder schwierig? Wie lang dauert sowas? Lässt sich das nicht auch automatisieren? ...

Nehmen wir mal folgendes an: du rippst mit MakeMKV eine DVD. Da mkv eh nicht lesbar ist von fx-upscale musst du remuxen. Dabei kannst du gleichzeitig auch die Farbraum-Parameter taggen.

Für PAL-DVDs

ffmpeg -colorspace smpte170m -color_primaries bt470bg -color_trc bt709 -i input.mkv -c copy output.mp4

Die 3 color... Parameter müssen als input-Parameter (d.h. vor dem -i ) stehen, wenn du mit ffmpeg irgendwas anderes ncoh machst, wie hier mkv -> mp4, oder wenn du konvertierst etc.

Die 3 color... Parameter müssen als output-Parameter (d.h. nach dem -i) stehen, wenn du ausschließlich das Video anchträglich taggen willst und nichts änderst,also auch nicht den Contaiern, BSP

ffmpeg -i input.mp4 -c copy -colorspace smpte170m -color_primaries bt470bg -color_trc bt709 -output.mp4

Für NTSC-DVDs

ffmpeg -colorspace smpte170m -color_primaries smpte170m -color_trc bt709 -i input.mkv -c copy output.mp4

Das fände ich als Nutzer besser. Doof wäre es wenn da was geändert würde und ich ich das eigentlich gar nicht will.

Es gibt keine Grund, einen Farbraum der autoamtisch konvertiert werden kann, nicht zu konvertieren. Wenn du nicht passende Farben haben willst, kannst du das nach Belieben mit ffmpeg oder anderen Tools machen.

Vielleicht finde ich ja die "schrägen Farben" gerade richtig? Farben sind schon eine "sensible Geschichte" - da würde ich nix automatisch und ohne bewusste User-Entscheidung tun.

Da gibt es für mich kein "Das ist zwar richtig, aber ich will das falsch gerechnet wird"-Argument. Ich bin mir auch sicher, dass es die wenigstens User bewusst entscheiden könne, da sie die Thematik nicht kennen. Genaus das ist ja mein Problem, das ich aktuell habe

Ich weiß wie es korrekt sein muss und könnte das in vielen Fällen automatisch so machen und daher korrekte Ergebnisse liefern.

Das aber genügend Videos keine Farbraum-Infos haben, fängt das Problem eben an

Wenn du mal falsche Farben haben willst, dann tagge einfach mal deine Mediathekvideos mit UHD-HDR-Infos:

ffmpeg -i input.mp4 -c copy -colorspace bt2020c -color_primaries bt2020 -color_trc bt2020-12 -output.mp4

 

[lisanet]

Wenn aber ein aktives weglassen von „PAL“ oder „NTSC“ nichts bewirkt und die Vorgabe übernommen wird – so what?
Wen es bis hierhin nicht kümmerte, den kümmerts auch dann nicht.
Wer aber es angeben möchte, kann.
Ist doch super.

Auch dir erst mal Danke, dass du dich da rein denkst.

Aber ganz so einfach ist es nicht:

a) es gibt im Original Parameter.

-> dann kann ich immer korrekt rechnen.

b) es gibt im Original keine Parameter

-> einfach nix machen -> möglicherweise nicht korrekte Darstellung des Players, obwohl es von Freaks behoben werden könnte (wie oben beschrieben, etnweder durch Optionen in fx-upscale oder durch taggen mit ffmpeg)

-> versuchen zu ermitteln -> kann falsch liegen, was nicht gut ist. Den User PAL oder NTSC wählen lassen, genau das bin ich mir ja unsicher: überforder ich da nicht die meisten User? Weißt du bei deinen M*A*S*H Videos ob die PAL oder NTSC sind.

Das werden dann viele User einfach gar nichts wählen.

Wenn das aus eurer Sicht eine sinnvolle Lösung ist, okay. Dann werde ich es so implementieren. Ich bin mir da halt nur sehr unsicher.

Ich habe gestern Nacht bsw. mal, weil ich die Serie gerade wiedermal schaue, mich daran gemacht und die Folgen von M*A*S*H von SD auf FHD gepimpt.
Erst mit „hevc“ jetzt mal mit „h264“ – mit „h264“ bekommt es etwas mehr Tiefenschärfe und klarere Farben, was allerdings mögliche Fehlerpixel ebenso hervorhebt.

h264 und h265 haben keinerlei Farbunterschiede. Der Codec hat mit Farben never ever was zu tun.

Auch haben meine Vorlagen keine Farb-Angaben, so auch deren upscales nicht:
(könnte ich aber etwas setzen, wie „bt709“ wäre das wohl auch nicht schlecht.)

Einfahc nur was setzen ist der falsche Weg.

Wenn du einfach nur Tags setzt und die korrekten Tags sind, dann kriegst du falsche Farben.

Anhang anzeigen 472785

der screenshot sagt auch aus, dass deine Original _nicht_ getagged waren. Wären sie getagged gewesen, hätte fx-upscale diese Tags übernommen. ABER: da es vorher SD-Videos waren, wäre durch fx-upscale auch weiterhin SC-Tags drin und die sind eben bei FullHD-Videos falsch.

Einfach nur andere Tags dann nachträglich hin zufügen, rechnet ja nicht die Pixelwerte korrekt um. Du erhälst dann weiterhin falsche Farben.

Lässt du das Video ungetagged, wird der Player davon ausgehen (wegen FullHD) dass bt709 viorliegt, was aber nicht stimmt (da eben hochkaliert von SD)

Konvertieren lassen habe ich es via batch im Ordnerpfad im Terminal:

hevc

for i in *.mp4; do fx-upscale -i $i -t fhd; done

h264

for i in *.mp4; do fx-upscale -i $i -c h264 -t fhd; done

hevc - batch mit temp dir

mkdir "temp" && for i in *.mp4; do mv $i temp && fx-upscale -i temp/$i -t fhd && rm -rf temp/$i; done

Bei der Variante „hevc - batch mit temp dir“ bekomme ich es leider nicht hin, dass die Originale im parent-Verzeichnis bleiben

Es fehlt bei fx-upscale der -o Parameter, also sowas wie "-o mein/neuer/Pfad/für/die/Ausgabe"

edit: @lisanet
Ach, eine Volume Anpassung in deinem fx-upscale fände ich auch noch superb.
Bei den M*A*S*H Episoden ist der Ton recht leise – dies müsste ich sonst auch erst über ffmpeg machen lassen, richtig?

Ja das musst du über ffmpeg machen.

Bei fx-upscale werde ich nichts dergleichen implementieren. Da geht es nur ums upscalen (und das will ich korrekt machen)