Posts by Selur
-
-
-
-
Ich würde keine Leveländerungen vornehmen.
-
Die gegebenen Informationen zu Quelle sagen nichts über:
1. den verwendeten Farbraum,
2. das verwendete color sampling
3. die Entstehungsgeschichte aus.
aus und ist damit nutzlos.
Einzigen weg den ich sehe das zu testen, davon ausgegangen, dass keine verlässlichen Metadaten zur Verfügung stehen, wäre ein Farbvergleich gegen eine Testsequenz, die speziell für BT.601 und BT.709 erstellt wurde, und vergleicht, wie die Farben im Video aussehen. Farbabweichungen können Hinweise auf den verwendeten Farbraum geben. (nein, ich habe keine entsprechende Testsequenz)
=> wenn es sich nicht um Computer generiertes Material handelt, ist deine Quelle vermutlich BT.601Praktischer Ansatz:
Speichere das Material zweimal in einem Format mit VUI Signaling, setze einmal BT.601 und einmal BT.709 und schaue welche Farben korrekter aussehen bei der Wiedergabe. -
Quote
Shotcut findet den Hardware-Decoder h264_qsv.
Bisher habe ich libx264 verwendet,
Der Encoder und der Decoder sind erst mal unabhängig.
Wenn man Hardware Decoder und Encoder verwendet und diese auf den gleichen Speicher zugreifen, kann eventuell ein Zwischen weg über die CPU gespart werden.QuoteEntspricht hier VBR 68% qscale = 17 den obigen Einstellungen mit crf 17?
Nein, eventuelle crf, quantizer, qscale Werte sind i.d.R. nicht blind zwischen verschiedenen Encodern 1:1 übertragbar.QuoteIst es sinnvoll, umzusteigen?
Du meinst, ob es Sinn macht von x264 zu QSV H.264 als Encoder zu wechseln?
Das ist nicht pauschal beantwortbar.
Der Software x264 Encoder ist i.d.R. langsamer, hat aber mehr Optionen und kann potenziell ein besseres Verhältnis zwischen Datenerhaltung zu Kompression erreichen. Der QSV H.264 Hardware Encoder hingegen hat weniger Optionen, ist aber wesentlich schneller.
Je höher die Datenrate und, desto weniger der Encoder wirklich komprimieren muss, desto geringer sind die Unterschiede zwischen den Ausgaben der Encoder (und sogar Formaten).
=> Du musst Du selber entscheiden, ob was Du komprimierst, mit den von Dir gewählten Einstellungen des Encoders, so viel bessere Ergebnisse (bei gleicher Größe) erzeugst, als wenn Du den (potenziell) schnelleren QSV H.264 Hardware Encoder verwendest.
Cu Selur -
Ja, BT.709 ist etwas größer als BT.601 kann also mehr Farben darstellen.
Das 709 bessere Qualität erzeugt ist pauschal erst mal falsch.
Das Verwenden eines Farbraums an sich sagt nicht allgemein über die Qualität aus, sondern nur darüber, wie viele bzw. welche Farben dargestellt werden können. Wenn Deine Quelle nicht mehr Farben enthält als BT.601 wird das verwenden von BT.709 nicht zu besserer Qualität (= dem Original eher entsprechenden Farben) führen.
Da es immer noch Formate und Player gibt, die VUI Signalisierung nicht unterstützen, sollte man bei SD Material i.d.R. bei 601 und bei HD Material eher 709 verwenden. Eine Umwandlung der Farbdarstellung ist z.B. durch ColorMatrix in Avisynth oder Vapoursynth oder durch entsprechende LUTs möglich.
Eine Umwandlung von einem größeren zu einem kleineren Farbraum (z.B. 709 nach 601) verlustbehaftet, wenn Farben verwendet wurden, die im größeren existieren, aber im kleineren nicht.Cu Selur
-
-
*2024.09.29.1:
*changed*- Vapoursynth: SoftLight require PC scale when mode != 8
- Vapoursynth: updated RIFE, RIFE(mlrt)
- Vapoursynth: use constants for Matrix, Primaries, Chroma, Luma
- Video: NVEnc/QSVEnc support --vpy-mt
- Jobs: add abort-option to size- and audio-warning onjo create&start
- Jobs: added scripts to report file
- Video: removed NVEnc input type checks
- Filtering: hide deinterlace control on progressive input, since it confuses users
- Avisynth: FFmpeg2Source use YUV422PX instead of YUY2
- Avisynth: increased suported memory max to 65536MB
- Avisynth: Hybrid now comes without Avisynth 32bit support, it is an addon now
- Video: do not check for UT Video, assume its present
- Vapoursynth: prefer BestSource as default for file input
- Vapoursynth: torch - added 'Requires'-controls to VSGAN and VSGAN Filter
- Input: Switch from Vapoursynth to Avisynth (when available) on .avs input
- Vapoursynth: TemporalDegrain2: degrainTR default and crash with degrainTR=0
- Video: x264, disable and deactivate 'auto' for color space on profile 'None'
- Video: x264, x264 - added 'adjust gop max to output fps'
- Ui: changed maximize handling
- Ui: option to set debug output path
- Vapoursynth: add masking for frame matching
- Vapoursynth: added FTF to TIVTC
- FFmpeg: don't set color signaling for pipes
- Avisynth: added 'Never use AviSource'
*fixed*- Avisynth: enable avsToon for 32bit
- Video: x264 minimizeCL with 'superfast'
- Vapoursynth: FileQueue and Masking issues
- Vapoursynth: ReplaceSince
- Vapoursynth: torch - remove unnecessary resize call after VSGAN
- Extraction: use ffmpeg for ProRes from mkv extraction
- Video: SVT-AV1 typo 'enableResotration' vs 'enableRestoration'
- Vapoursynth: SMDegrain smdegrain.py script interlaced handling fixed
- Vapoursynth: mlrt - DPIR FP16 inverted
- Video: NVEnc - max bitrate initial value
- Video: NVEnc - EdgeLevel not added to command line
- Input: Zip format handling (ffmpeg and analysis)
- Synh: fix typo in CustomSynthScript QQDFPlus and abcxyz YUVALLX -> ALLYUVX
- Vapoursynth: QTGMC in CompareView with 'custom', use Preset='Fast' for original side.
- Vapoursynth: torch, VSGAN (Filter), width/height mixup
- Vapoursynth: torch, DeOldify 'render_vivid' and 'dark' passed as string instead of bool
- Vapoursynth: SmoothGrad fix min value 1
- Vapoursynth: Frame->Resize UI scaling
- Vapoursynth: torch, ProPainter 'Inference'-CheckBox not working
- Vapoursynth: cfhd handling
- Vapoursynth: SSIMD: fix output color
- Vapoursynth: letterboxing YUV422 mod2
- Vapoursynth: vsRemoveDirt defaults
- Video: FFmpegs zscale-call for PNG output
- Video: x264 slow preset using b-adapt 2 instead of 1
- FFmpeg: 2020 signaling
- Extract: vp9 video
- Model: loadfromJson respect skipList
- Avisynth: TIVTC+QTGMC
- Avisynth: fix histogram color restriction check, no YUY2 support
- Avisynth: QTGMC+Custom+UltraFast missing YadifMod2 dependency
- Avisynth: DeblockPP7 and aSharp were unnecessarily disabled for 64bit Avisynth
- Video: ProRes encoding when mencoder is used as decoder
- Vapoursynth: DecimateMode set output fps for mode 2, which is (still) broken
- Vapoursynth: RainbowSmooth require mod16
- Vapoursynth: don't try to set ColorMatrix on RGB content
- Vapoursynth: DGSharpen requires mod16
- Vapoursynth: rectangular mask for high bit depth
- Decoder: changed Avisynth input handling
- Muxing: mkv helper for ffmpeg color matrix and vfr
- Jobs: fix cleanup job handling on raw audio only output
- Jobs: fix warning handling
*added*- Vapoursynth: GLSL Gamma, RGBAdjust filter ports(Levels broken&disabled)
- Vapoursynth: proToon
- Vapoursynth: vs_temporalfix
- Vapoursynth: torch/vmlrt option to set (trt) 'engine path'
- Avisynth: added CustomSynthScripts for 32bit and 64bit proToon-v0.75.1
- Generate output name suffix added '%DATE%','%TIME%','%TIMEMS%' replacements
- Vapoursynth: torch - add vs_colorfix for VSGAN and VSGANFilter
-> downloads: http://www.selur.de/downloadsCu Selur
-
Ist das der erste llma chat bot, der sich hierher verirrt hat?
Willkommen im Board.
-
http://avisynth.nl/index.php/RGBAdjust und http://avisynth.nl/index.php/GradationCurve sind vielleicht auch interessant.
-
Falls Du Hybrid installiert hast, könntest Du:
1. "Config->Internals->Handling->Ingore all timecodes" aktivieren
2. Die Quelle laden
3. "Base->Processing" Audio&Video auf passthrough stellen.
4. "Muxing->Overwrite->Frame rate" auf 25 setzen
5. Output festlegen und Job erstellen, Processing starten
Falls nicht, versuch mal:1. mit mkvextract die Audio&VideoStreams alle zu extrahieren
2. mit mkvmerge (bzw. mkvtoolnix-gui) die Streams zu muxenCu Selur
-
mkvmerge ist ein Command Line Programm, vermute Du verwendet mkvtoolnix-gui und nicht mkvmerge wie Du geschrieben hast.
Vermute, in mkvtoolnix-gui sollte man:
1. 'Default duration/FPS' auf 50i (davon ausgegangen der Inhalt ist wirklich interlaced); eventuell muss man da auch 25i oder 25p wählen, meine da war ne Unterscheidung je nachdem of PAFF or MBAFF genutzt wird.
und
2. 'Fix bitstream timing info' (das sollte Zeiteinteilungsinformationen im Bitstrom anpassen" sein)Cu Selur
-
Schmeiß die TimeCodes raus, sprich extrahiere alle Streams und keine TimeCode file, dann muxe die Streams wieder.
-
Nope, liegt nicht am DNS (213.186.33.5),... => nicht tragisch
-
Strange,... muss wohl was bei 1und1/Telekom sein,..
-
https://downforeveryoneorjustme.com/videocodecs.info?proto=https
sagt die Seite ist erreichbar,...
Wenn ich per http drauf gehe sieht man 'Site en construction'¯\_(ツ)_/¯
-
Zumindest bei mir geht der Link nicht,... "Beim Verbinden mit videocodecs.info trat ein Fehler auf."
-
-
a. Kann man den Output mittlerweile im MPC-HC und mit LibavSource decodieren?
b. funktioniert frame rate signaling mittlerweise korrekt? (siehe: https://github.com/mpeg5/xeve/issues/109)