Beiträge von sneaker2

    Das ist komisch, sollte das die Anzahl der Threads meine CPU sein, da ich einen I7 3930k habe und dieser "nur" 6 Kerne hat und damit 12 Threads...
    Wobei ffmpeg und Megui das falsch reinschreiben...

    Das paßt schon so. x264 arbeitet standardmäßig mit Anzahl logischer CPUs x 1,5. Also 12 x 1,5 = 18.

    Doch, monarc99 hat schon Recht. Mit -pix_fmt yuv420p10le schaltet ffmpeg auf die 10 Bit-Kodierung von x264. ffmpeg läßt sich auch als Multi-Bitdepth-Variante kompilieren. Macht zeranoe auch so.

    Ja, ergibt für mich so auch keinen Sinn.

    Spontan würde

    1. ich Zeile 17 und 18 durch

    Code
    ConvertToStacked()

    und

    2. Zeile 26 durch

    Code
    ConvertFromStacked()
    ConvertBits(10, dither=0) # für 10-Bit Ausgabe. Bei 8-Bit- oder 12-Bit-Ausgabe entsprechend anpassen.

    ersetzen.

    Man muß immer im Kopf mitdenken, ob man gerade das "gehackte" Format hat (also 16 bit als 8 bit stacked oder interleaved (doublewidth)) oder das "native" avs+-Format hat. Je nach dem ob die Filter nur mit dem alten oder auch mit dem neuen Format klarkommen, muß man entsprechend dazwischen immer hin- und herwandeln. Für den Output als y4m-Pipe mit 10 oder mehr Bits braucht man das native Format.

    Hallo Zusammen,

    ich bin aktuell dabei alle meine AVI´s in MKV Container zu Transferieren. Dazu nutze ich die Mac version von MKVToolNix 26

    Klappt bei 95% der Files prima, bei einigen Beschwert sich das Tool aber das die Audiospuren "Ungültige" Daten enthalten würde, die werden entfernt... Laut InfoBox kann dies die Synchronität beeinflussen.

    Kann mir wer erklären wie so etwas zustande kommt? Kann ich hier etwas gegen tun?

    Ich kenne das, wenn man Audio-Delays mit z.B. VirtualDub realisiert. Wenn man z.B. +100ms Delay haben will, fügt VirtualDub am Anfang 100ms entsprechende "Mülldaten" an den Anfang der Tonspur. Also eigentlich ein übler Hack. Mkvmerge kann das erkennen und löschen und speichert dann die Information im mkv-Container, daß die Tonspur erst nach 100ms anfängt. Im AVI-Container geht das so nicht, daher dieser Hack von VirtualDub. Sauberer wäre es natürlich, wenn man im AVI-Container 100ms Stille encodieren würde, was VirtualDub aber nicht kann (AVI Mux GUI kann das).

    Dieser Hinweis von mkvmerge ist also nicht wirklich schlimm.

    Alternativ gibt es auch das "AviSynth Virtual File System" ("avfs"). Die neuste Version findet sich im VapourSynth-Paket.
    https://www.vapoursynth.com/doc/avfs.html

    Ich weiß aber, daß viele es bevorzugen, das Video in ein schnittfreundlicheres Format umzuwandeln. "Schnittfreundlicher" im Sinne von schneller dekodierbar, wie ProRes or AVC-Intra oder was auch immer im bevorzugten Editor am besten funktioniert.

    Die Umwandlung zu BT.709 mußt Du in AviSynth/VapourSynth/ffmpeg machen, das kann x265cli nicht selbst.

    Code
    LWLibAvVideoSource("00030.m2ts", [b]format="yuv420p10"[/b])ConvertFromDoubleWidth(bits=10)Trim(3500,3600)z_ConvertFormat(pixel_type="RGBPS",colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:l", dither_type="none")DGReinhard()z_ConvertFormat(pixel_type="YUV420P16",colorspace_op="rgb:linear:2020:l=>709:709:709:l", dither_type="none")Spline36Resize(1920, 1080)ConvertBits(10, dither=0)prefetch(4)

    Inwieweit das jetzt die richtige HDR->SDR-Umwandlung ist, kann ich nicht mit Sicherheit sagen. Ich habe quasi nur das Beispiel aus der Readme genommen. Benötigt AviSynth+.


    https://rationalqm.us/DGTonemap.rar
    https://www.dropbox.com/s/3ocrd217pprr…ize-r1d.7z?dl=1


    Pipen würde ich einfach y4m nehmen:

    Code
    :\Program Files (x86)\Video Tools\avs2pipemod-1.1.1\avs2pipemod.exe" -y4mp "01.avs" | "C:\Program Files\x265\x265-10Bit-2.7_336.exe" --preset slow --crf 22 --psy-rd 2.0 --psy-rdoq 10.0 --aq-mode 2 --rd 5 --me star --no-sao --no-open-gop --y4m --fps 24000/1001 --output "test.h265" --input -
    Code
    clip = core.vsfm.TextSubMod(clip=clip, file="F:/TestClips&Co/files/Subtitles/TITLE_1_3_lang_es.[B][U]srt[/U][/B]")


    ????

    Ansonsten mal PlayResX und PlayResY korrekt setzen. Damit werden ja die Abstände berechnet. Nicht, daß die Untertitel quasi über dem Bild verschwunden sind.

    Ich würde Dir nebenbei empfehlen, Dir die Header so zu setzen, wie Aegisub es tut. Das sollte das am besten akzeptierte Format sein.

    Jede Einstellung hat Vor- und Nachteile. Gesucht ist ein guter Kompromiss. Ob da jetzt ein Wert auf 24 oder 25 steht, macht praktisch keinen Unterschied. Bei 60 fps und Wert 600 kann halt das Seeken etwas langsamer werden, dafür ist die Kompression etwas besser. Für die meisten Filme ist 4*fps für (max) keyint ein guter Kompromiss zwischen Seek-Geschwindigkeit und Kompression. min-keyint kann einfach auf dem Standard gelassen werden. Aber ein "Richtig" oder "Falsch" in dem Sinne gibt es nicht (außer man enkodiert für spezielle Formate, die etwas vorschreiben. Z.B. man produziert eine Blu-Ray. Für Hobby-Filmbearbeiter ist das aber ziemlich egal.)

    Hoher Keyint: bessere Kompression, langsameres Seeking.
    Hoher min-keyint: vermeidet ungünstige IDR bei bestimmten Szenen (Stroboskop), kann umgekehrt auch falsch sein.