DNxHR HQX 10-Bit zu x265 MKV Container FPS Problem

  • Ich habe eine Frage. Ein DaVinci Resolve Workflow, ausgegeben als DNxHR HQX 10-Bit soll mittels Avisynth (Frontend Staxrip) mit x265 in h.265/HEVC kodiert werden. Soweit so gut, ich nutze LSMASHVideoSource als 10-Bit Pipeline.


    Hier das Avisynth Scrypt:

    Code
    1. LoadPlugin("E:\VIDEOTOOLS\AVIS riPPen\StaxRip-x64-2.0\Apps\Plugins\avs\L-SMASH-Works\LSMASHSource.dll")
    2. LSMASHVideoSource("E:\SOLO 2K.mov", format = "YUV422P10")
    3. ConvertFromDoubleWidth(bits=10)
    4. ConvertToYV12()
    5. Crop(0, 276, -0, -276)
    6. Addborders(0, 276, 0, 276)


    Das HEVC Raw File sieht auch erstmal gut aus.


    Jetzt die Kuriosität. Wenn ich das File mit MKVtoolnixGui in einen MKV Container muxe, passiert das:


    Das ganze auch bei x264. Meine Vermutung ist, irgendeine Option stimmt bei der Avisynth Source nicht. Auch wenn ich DSS2 Source oder FFMS2 Source nehme passiert genau das gleiche. Das ganze mit VidCoder (Handbrake Engine) enkodiert funktioniert einwandfrei, ist nur leider keine Option, da ich noch diverse Filter drüber jagen muss.


    Für Tipps und Hilfe wäre ich dankbar.

  • AviSynth kann darauf keinen Einfluss mehr haben. Wie du siehst, ist die korrekte Rate bereits im Video enthalten. Die Ursache kann also ausschließlich im Multiplexer liegen. Bei einer Gesamtdauer von etwa 17 Sekunden wird optisch keine Veränderung auffallen, vielleicht ist auch die kurze Dauer ein Grund für ein "Abrunden"; am besten weiß das aber sicherlich Mosu als Autor von mkvtoolnix (HandBrake und VidCoder werden stattdessen wohl ffmpeg im Kern als MKV-Multiplexer verwenden).

  • Ich habe auch versucht, das HEVC RAW File mit FFMPEG in einen MKV Container zu muxen. FFMpeg meckert aber rum, dass im Bitstream FPS Informationen fehlen würden. Den Enkoder schliesse ich aus, denn das ganze passiert auch, wenn ich DNxHR HQX mit x264 enkodiere.


    Nehme ich aber die gleichen Einstellungen des Enkoders und kodiere ein HEVC File und nehm als Source Filter DGIndexNV, habe ich das Problem nicht. Es tritt nur bei diesem Quicktime Codec als Source auf. Daher mein Verdacht, das ich irgendetwas vergesse, wenn ich das YUV422P10 Source Material mittels Avisynth zu YUV420P10 konvertiere.

  • Du kannst je gerne noch ein AssumeFPS(24000,1001) an den Source-Filter anfügen, um exakt das richtige Verhältnis sicherzustellen.


    Es kann gut sein, dass in rohem HEVC-Video keine Framerate erkannt wird. Dann kann man sie für ffmpeg aber immer noch per Parameter festlegen.

  • Hehe, auch das habe ich probiert. Selbes Ergebnis. Sogar wenn ich --fps 24000/1001 in der x265 Befehlszeile einfüge, passiert das beim muxen in den Container.


    Code
    1. FFVideoSource("%source_file%", colorspace="YUV422P10", fpsnum=24000, fpsden=1001, \
    2. cachefile = "%source_temp_file%.ffindex")


    Selbst im Source Filter direkt habe ich das nochmal angegeben. Kann es sein, da StaxRip irgendwie die AVSPipeline + y4m nimmt, das da irgendwie meine Daten überschrieben werden?


    LÖSUNG:


    Avisynth Script:


    Code
    1. LoadPlugin("E:\VIDEOTOOLS\AVIS riPPen\StaxRip-x64-2.0\Apps\Plugins\avs\L-SMASH-Works\LSMASHSource.dll")
    2. LSMASHVideoSource("E:\SOLO.mov", format = "YUV422P10")
    3. ConvertFromDoubleWidth(10)
    4. ConvertToYV12()
    5. AssumeFPS(24000, 1001)
    6. Crop(0, 276, -0, -276)
    7. Addborders(0, 276, 0, 276)


    In den x265 Optionen zusätzlich noch einstellen:


    Code
    1. --fps 24000/1001


    Jetzt passt der MKV Container.

  • In FFVideoSource wäre falsch, weil dann der Decoder versucht, auf Krampf diese Framerate zu erzeugen, indem eventuell Frames übersprungen oder verdoppelt werden.


    AssumeFPS im AviSynth-Skript ist sicherlich wichtig, weil dann der Bruch wohl mit besserer Genauigkeit verarbeitet wird. Eigentlich sollte der fps-Parameter für x265 genügen, um das richtige Framerate-Flag zu setzen; allerdings arbeite ich auch eher ohne StaxRip...