Macht der denn überhaupt noch Sinn, wenn man z.B. den i3-8100 für unter 140 Euro (boxed) bzw. unter 130 Euro (tray) bekommt?
Zur eigentlichen Frage: soll an Produktionsengpässen liegen.
Aber: schon die RAM-Preise gesehen?
Macht der denn überhaupt noch Sinn, wenn man z.B. den i3-8100 für unter 140 Euro (boxed) bzw. unter 130 Euro (tray) bekommt?
Zur eigentlichen Frage: soll an Produktionsengpässen liegen.
Aber: schon die RAM-Preise gesehen?
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.
3.1.0.800 ist eh schon wieder veraltet. 3.2.0.802 enthält unter anderen Crash-Fixes. (Ob jetzt speziell für Dein Problem, weiß ich natürlich nicht.)
Nun, das Format ist jetzt aber "P010". Und das kann der dfttest nicht!
Habe ich doch bereits berücksichtigt?
Vermutlich MediaInfo. (Ich empfehle die Textansicht. "View" bzw. "Ansicht" -> "Text".)
Ja, ergibt für mich so auch keinen Sinn.
Spontan würde
1. ich Zeile 17 und 18 durch
und
2. Zeile 26 durch
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.
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:
https://www.dropbox.com/sh/3i81ttxf028…oVhYLasmwa?dl=0
Gibt aber schon seit etwa einem Jahr keine Updates mehr, wenn ich nichts verpaßt habe.
Wie LigH sagt: mehr Infos nötig.
Schau aber, daß nicht nur Videoauflösung etc. passen sondern überhaupt die gleichen Tracks da sind. Also auch gleiche Anzahl/Typ an Ton- und Untertitelspuren.
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.
[Script Info]
; Script generated by Aegisub 3.2.2
; https://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None
PlayResX: 1920
PlayResY: 1080
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,20,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,2,2,2,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:01:00.00,0:01:10.00,Default,,0,0,100,,TEXTTEXTTEXT
Display More
Samples von Youtube sind schlecht, weil da mehrere Streams angeboten werden und ich nicht weiß, ob wir beide denselben benutzen. Ich habe jetzt über "youtube-dl -f 22 ybPtPFAww_A" runtergeladen. Allerdings sind Video- und Tonspur nur 9ms an Länge Unterschied. Bei 3 oder 4 Dateien würde man das noch nicht wirklich wahrnehmen.
Puh, ich habe da nicht wirklich Ahnung von. Meine Vermutung, warum es irgendwann Async wird: Video- und Tonspur sind nicht immer gleich lang. Sagen wir mal, die Tonspuren sind immer 50ms kürzer. Dann addiert sich dieser Fehler mit jeder weiteren Datei, bis er irgendwann bemerkbar wird.
Vielleicht könnte man da mit einem Kommando with -shortest gegenwirken?
Auf Blu-ray ist es nicht erlaubt
Doch. Wird aber selten genutzt.
Zum Rest wurde ja eigentlich genug gesagt. Letztendlich ist es hauptsächlich eine Frage der Playerkompatibilität. Wenn man die Maximieren will, ist wahrscheinlich 720p50 (falls aus Europa) am Besten. Für beste Kompression auf 1440x1080 belassen, ggf. deinterlacen.
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.
Sind die Zeiten immer gleich? (Sollten sie oder?)
Nein. (Siehe LigHs Beispiel: VFR. Wobei das für VFR nicht nötig ist, aber das Prinzip noch weiter verfeinern kann. Z.B. wie bei Untertiteln, wo es ja Lücken gibt.)
Welche Zeit hat Vorrang?
Vorrang vor was? (Egal: BlockDuration hat immer Vorrang.)