codec conversion und x264 komprimieren FRAGE

Du nimmst ja in YUV422p10 auf. Limitierter Farbbereich sollte also richtig sein 16-235.

X264 Parameter sind leicht. Bei der Leistung heutiger CPUs kann man einfach Preset Veryslow nehmen und die Ref-frames auf 4 limitieren. Sowie B-frames 3-5 wählen. Passender Rate-Fator (CRF) für SD-Inhalte etwa 18-23. Dazu Level 3.1 High. Bei mehr als 30fps Level 3.2 High. Colormaxtrix für PAL setzen ->bt470bg

--crf 20 --preset veryslow --profile high --level 3.1 --partitions all --no-fast-pskip --vbv-maxrate 17500 --vbv-bufsize 17500 --bframes 5 --ref 4 --min-keyint 24 --colorprim bt470bg --colormatrix bt470bg --transfer bt470bg

Ich sehe das so wie LigH.

Dazu noch einige Tipps.
Ja, für YouTube kann man das Script so verwenden, das Smurf vorschlägt. Bei PAL würde ich aber bei 25- oder 50 fps bleiben, bei 30 fps kann es sein, dass der Ton nicht mehr synchron ist. Für 10bit, würde ich crf 16 einstellen, da hier eine höhere Bitrate erforderlich ist.

Videonachbearbeitung mit einem Schnittsystem in unkomprimiert bei SD in 4:2:2 (x265, H.264):
Hier würde ich darauf achten, dass eine Bitrate von 20.000 Kbps (konstant) anliegt, wegen der 10bit Farbtiefe. Wichtig wäre dabei ein Referenzbild von 1 Bild (I Frames only). Das heißt, jedes Bild ist ein Schlüsselbild. Dabei hat man keine GOP-Struktur, da die Zwischenbilder 3-5 entfallen.

Der große Vorteil ist, dass man bei jedem Bild einen Hartschnitt ausführen kann, ohne das es zu Bildfehlern kommt. Bei einer GOP-Struktur schneidet man, jedenfalls meistens, in der Mitte der Zwischenbilder. Dabei können aber Bildfehler auftreten.

"Level" definiert nur die Decoder-Limits, daher sinnvoll sich max. an Level 4.1 oder geringer zu halten. Alles über 4.1 wird von vielen Blu-ray Playern oder Fullhd-TVs schon nicht mehr unterstützt. Das hat nichts damit zu tun, dass hier die Framerate convertiert wird. https://en.wikipedia.org/wiki/Advanced_Video_Coding#Levels

Um Speicherplatz zur sparen kann man als Zwischenschritt seine lossless Captures natürlich nochmal so wie von Pro Jo beschrieben in sehr hoher Qualität in x264/x265 transcoden. Nur I-Frames zu nutzen verschlechter die Kompression enorm und treibt die Bitrate steil nach oben, sollte man bedenken. Schneiden, falls nötig, würde man dann im finalen Schritt, wenn das Material in das Endformat gewandelt wird. Deweiteren würde man hier auch wieder interlaced mittels MBFAA-Verfahren (x264) encoden und das braucht nochmals sehr viel Bitrate. Ich hätte hier fast Bauchschmerzen mit "nur" 20Mbit/s zu encoden. Er captured ja mit etwa 220Mbit/s. Würde daher 30-50 Mbit/s anpeilen. Wäre immer noch eine enorme Platzeinsparung ohen sichtbaren Qualitätsverlust.

Wenn er genügen Speicherplatz hat und seine 220-Mbit/s-Captures daher behalten kann, kann er sich den Zwischenschritt auch sparen und eben gleich ins Endformat trancoden. Wie in meinem vorherigen Post eben beschrieben. Natürlich muss er sein Subsampling von YUV422p10 nach YUV420p8 / YV12 wandeln, sonst wird das kein TV oder Blu-ray Player abspielen.

ConvertToYUV420()
ConvertBits(8)

Quote from LigH

QTGMC sicher der qualitativ beste Filter; nur die Installation aller beteiligter Komponenten ist etwas aufwändig. Es wird dann von 50 Halbbildern pro Sekunde auf 50 Vollbilder pro Sekunde hochgerechnet, es sei denn, du lässt die Bildrate entweder innerhalb von QTGMC mit FPSDivisor=2 oder nachträglich halbieren.

Kann nicht empfehlen von 50 Halbbilder auf 25 Vollbilder zu gehen, Bildabschnitte mit viel Bewegung wirken dann nicht ganz flüssig.

@RextheC du fragst jetzt schon monatelang in verschiedenen Foren und kommst keinen Schritt weiter. Gut gemeinter Ratschlag: gibt das Projekt an einen professionellen VHS/Bearbeitungs-Service.

Die Option ist deshalb ausgegraut, weil SD eigentlich nur für 8 Bit gedacht ist. Ich sehe da nur zwei Möglichkeiten ein SD-Video mit 10 Bit zu erstellen. Das ist, entweder mit AviSynth zu 10 Bit wandeln, oder gleich beim capturen mit einem 10 Bit-Codec zu digitalisieren. Das ist meistens der 10 Bit-Codec (v210) von AJA.

In den Treibereigenschaften der BM-Software, müsste es auch die Möglichkeit zum gleichzeitigen Deinterlacing von SD-Material geben.
QTGMC könnte aber besser sein. Das muss man selbst ausprobieren.

Croppen:
Dass ein Encoder nicht unnötig strabaziert wird, gibt man folgende Werte bei den vier Bildseiten ein:

Oben: -8 Pixel
Unten: -12 Pixel
Linke Seite: -8 Pixel
Rechte Seite: -16 Pixel
Sollte unten ein größerer Störbereich vorliegen, z. Bsp. ein großer Kopfumschaltbereich, dann nur abdecken, nicht croppen. Aber bei den -12 Pixeln beim croppen bleiben. Da die Bildproportionen stimmen, kann man mit 704 x 576 Pixeln in den Encoder importieren und im Encoder dann entweder mit dem 4:3 - oder 16:9-Flag exportieren. Das sollte dann so aussehen: 704 x 576, 4:3. So müsste es auch Mediainfo anzeigen. Um ein Flag zu setzen, bietet meistens der Codec von MainConcept.

Wenn man sich daran nicht hält, dann berechnet der Encoder ein ganz neues Bild. 720 x 576 Pixel, 4:3, wäre dann mit Bildoverlay. Ja, 360 Pixel dann wieder auf 720 Pixel erweitern.

704 x 576, 4:3 und 720 x 576, 4:3 sind quadratische Pixel. Dann ist der Ball rund und nicht eliptisch. Es ist etwas kompliziert, aber es soll ja auch funktionieren.

Smurf, mit deinen Angaben bist du völlig im Irrtum. Wo hast du so einen Quatsch gelesen?

Da es sich um SD-Material handelt, sind folgende Werte normgerecht:
SD-Video liegt im Bereich von 3.1 und 3.2. 4.1 ist ab 4k. Ein SD-Video hat rechnerisch nur eine Bitrate von 15.600 Kbps bei MPEG-2 und nicht 220.000 Kbps. Das hast du mit 4k verwechselt. Diese 220.000 Kbps, sind viel zu hoch, das macht bei SD technisch überhaupt keinen Sinn. Selbst nicht, wenn es HDR10 bei SD wäre. Deine Bitrate liegt im Studio-Bereich, wenn man z. Bsp. 100 Kopien von einem HD-Material machen muss, dann ja. Aber hier handelt es sich um Amateur-Aufnahmen. Die genormte Bitrate bei 4k sind 270.000 Kbps. Ein 4k-Player müsste YUV422p10 abspielen können. Ein 4k Sat-Receiver wiedergibt ja auch YUV422p, sogar in 12 Bit, wenn man das will. Ein Sat-Receiver für 30 Euro, wird das kaum machen. Und bei einem Stream, dürfte das kein Problem sein.

Diese 20 Mbps die ich geschrieben habe, sind schon hoch. Da x264 und H.264 drei Mal so effektiv sind, bräuchte man daher nur 5.200 kbps. Bei 10 Bit würde ich noch 20% Bitrate dazuzählen. Alles andere bringt bei SD technisch nichts mehr.

Bei I Frames only wird fast nicht komprimiert, vergrößert das File ein wenig, das ist richtig. Aber dafür ist die Bildqualität bei SD auch besser, das kann man überall nachlesen. Außerdem, wie schon geschrieben, sollte man nicht in der Mitte einer GOP-Sequenz schneiden. Nur, man müsste es halt verstehen. Das ist das Problem. Jeder kann das so machen, wie er es möchte.

Grüße

Wenn der Threadersteller hier so ein Wirrwar mit so vielen Ungenauigkeiten liest, wundert es mich fast nicht, dass er auch nicht weiterkommt.

Er kann theoretisch croppen, wie er lustig ist, das interessiert so einen modernen Encoder wie x264 recht wenig. Wo und weshalb wird da der Encoder strapaziert und was soll das heißen? Die Rechenleistung und Encodingzeit steigt? Die Bildqualität sinkt oder die Ränder blurren? Ich kann verstehen, wenn man mit dem MOD16-Argument kommt, da x264 16x16 Makroblock-Größen nutzt aber selbst das macht heutzutage ja kaum noch jemand. Weshalb wäre es wichtig, dass vertikal genau 20 und horizontal 24 Pixel gecroppt werden? MOD16 entspräche das jedenfalls nicht. (696x556)

Wieso werden in deinem Beispiel 704x576 an den Encoder gegeben? Die Werte die gecroppt werden, werden der Auflösung abgezogen und so an den Encoder gegeben. Alles andere wäre Resizing ODER du meinst wahrscheinlich die Ränder mit "AddBorders" wieder auffüllen. Das liest sich nur mit Fantasie heraus.

Encoder Level 4.1 ist AVC Blu-ray Standard, das ist halt Fakt und überall nachlesbar. Wobei hier natürlich entscheidend ist, was wirklich im Videostream steckt. Neben den Limits der Encoder Settings (Ref-Frames 4, B-Frames 3, min-keyint 1, keyint 24, b-pyramid strict etc.) natürlich auch Framerate, Auflösung und Subsampling. Stichwort: Blu-ray compliant encoding. Der TE hatte gefragt, mit welchen finalen Settings er nach x264 encoden sollte. Daher habe ich empfohlen, Level 4.1 nicht zu überschreiten damit auch FullHD Blu-ray Player / TVs / und Reciever etc. die Dateien sicher wiedergeben können. x264 mit YUV422p10 Subsampling kann jedenfalls kein FullHD-Hardwareplayer. Bin mir nicht mal sicher, ob es ein gewöhnlicher 4K-Player kann, da der Hartwaresupport für x264 10bit nicht vorhanden ist.

Die "220 Mbit/s" habe ich nicht als "die" SD-Bitrate definiert das ist die avg. Bitrate seiner Captures im lossless YUV422p10 Format. (Sample vom TE in einem anderen Forum gepostet)

Für den finalen Encode würde ich auch keine 20-50 Mbit/s anstreben, hier gibt es um einen "Zwischencode", falls dem TE die riesigen unkomprimierten Captures zu groß sind.

Quote from Pro Jo

Außerdem, wie schon geschrieben, sollte man nicht in der Mitte einer GOP-Sequenz schneiden. Nur, man müsste es halt verstehen. Das ist das Problem. Jeder kann das so machen, wie er es möchte.

Dass man ohne Reencoding nur an I-Frames schneiden kann, ist mir bekannt. Da gibts nicht viel zu verstehen

Quote from LigH

ie Spezifikationen einer DVD Video erfordert bei PAL entweder 352, 704 oder 720 Pixel Breite bei 576 Zeilen Höhe, 696 Pixel sind nicht erlaubt. Bei analogem Capturing ist es relativ egal. Wer ein Video mit 696 Pixeln Breite in MPEG-4 AVC (H.264) von einem Smart-TV abspielen lässt, kann Glück oder Pech haben, dass es verzerrt oder korrekt aussieht. Ein guter Mediaplayer auf dem PC wird sich an die Markierungen halten, die entweder im Videostream oder im Container (MP4, MKV o.ä. / SAR oder DAR) eingestellt wurden.

Das hieße es ist schon empfehlenswert nach PAR 1:1 zu resizen, wenn man durch Cropping die 720, 704, 352 nicht einhalten kann, da manche Player das Bild dann falsch entzerren. So richtig? Meine das auch mal gelesen zu haben. Was wäre, wenn man auf 704x560 croppt, als unübliche veritkale Auflösungen? Haben Hartware-Player mit der Entzerrung Probleme? Ich schätze im Zweifelsfall einfach mal probieren?

Bei meinem Player/TV bräuche ich PAL theoretisch gar nicht croppen, da die LG-TV eine "just scan" Option hat und damit die Ränder schon bei der Wiedergabe nicht mit abbildet.

@RextheC das passt nicht, damit ist das Bild vertikal verzerrt. 704 -> 768 passt (PAR 12:11). Die vertikale Auflösung bleibt unverändert. Crop-Filter ist wie folgt: Crop(left, top, -right, -bottom); wirklich so viele Pixel vertikal nötig?

Wenn du nur 8 Pixel links und rechts croppst, wirst du allerdings die schwarzen Ränder nicht komplett los.

Ein Wirrwarr ist das nicht, es sind die Bitraten, die man einstellen sollte, alles andere wäre „aufgeblasen". 2002 hat das ZDF seine ganzen Filme im Archiv auf DVCPRO50 (4:2:2) überspielt. Du willst den Profis dort bestimmt nicht sagen, dass 50 MBit/s eine schlechte Bildqualität ist. Übrigens, meine empfohlenen 20 MBit/s bei x264 und H.264, entsprechen 60 MBit/s bei MPEG-2.
Encoder:
Das habe ich ja schon geschrieben. Wenn ein Encoder das Bild ganz neu berechnen muss, dann brauch dieser mehr Zeit. Das summiert sich dann schon bei ca. 150 Bändern. Der Hauptgrund ist, dass der Encoder die schwarzen Streifen vom Bildoverlay als zusätzliches Rauschen interpretiert. Zu diesem Thema war einmal vor langer Zeit, ein Beitrag im c’t Magazin gestanden.

704x576 an den Encoder geben:
Man muss vorher entweder mit AviSynth oder mit einem Schnittsystem auf 704 Pixel croppen, exportieren, und dann erst in den Encoder importieren. Gute Encoder zeigen 704 oder 720 Pixel an, aber nicht 768 Pixel, das müsste dann manuell eingetragen werden. 768 Pixel werden erst durch das jeweilige Flag erzeugt.

Croppen mache ich nicht mit VDub oder anderen Hilfsmitteln, sondern nur im Media Composer. 704 Pixel ist eigentlich kein Resizing, da das 4:3-Flag die Bildpoportionen korrekt einstellt, und das Bild nicht vergrößert wird. Das dachte ich früher auch, stimmt aber nicht.

Die Einstellungen mit Level 4.1 und den 4 Ref-Frames stimmen, das sehe ich auch so, unter normalen Umständen. Ich meinte nur, wenn man so ein erzeugtes Material (H.264/265) vorliegen hat und dann nachträglich schneiden will, z. Bsp. mit einem Schnittsystem, dann sollte man das vor dem Import in ein Schnittsystem, zu I-Frame only wandeln. Das ist vielleicht dir bekannt, aber meistens den Anfängern nicht. Aber, warum hast du dann wieder 4 Ref-Frames geschrieben?

220 MBit/s:
Für SD ist das normalerweise zu hoch, es sei denn man hat Filmmaterial mit sehr schnellen Bewegungen, was im Amateur-Bereich fast nicht vorkommt. Lossless mit 4:2:2 und10 Bit ist bereits mit 185 MBit/s mit dem professionellen SD-Codec von Avid möglich. Aber auch mit anderen Codecs. HUFFyuv müsste auch gehen. Hat ohne 10 Bit, glaube ich, 135 MBit/s.

VHS zu x264:
Soviel wie ich gelesen habe, handelt es sich bei dem Kollegen um SD-Material, und nicht um HD. Es sei denn, er möchte SD zu HD resizen und auf Blu-ray speichern. Hellsehen, kann ich leider noch nicht. Heutzutage macht man das aber nicht mehr auf Scheibe, sondern mit Streams.

Einen „Zwischen-Codec“ braucht man normalerweise nicht. Man kann beim capturen gleich einen professionellen 4:2:2-Codec mit 10 Bit anwenden. Es kann auch in 10 Bit gerendert werden. Der „End-Codec“ z. Bsp. H.264, wird dann vom Encoder erzeugt. Dann kann man auch 4 Ref.-Frames einstellen.

4k-Player:
Laut den Bildspezifikationen müsste ein 4k-Player auch YCrCb 4:2:2 und auch YCrCb 4:4:4 wiedergeben. Besser ist aber RGB 4:4:4, da HDMI nur RGB-Leitungen hat, aber keine extra Kontakte mehr für FBAS und Y/C. Composite und Y/C erkennt aber das HDMI-Interface durch die verschiedenen Datenleitungen, und werden trotzdem wiedergegeben.

Ja, für Anfänger sind das viele Infos, das muss man erst lernen zu verstehen.

Das sehe ich ähnlich. Ein wenig überkompliziert. Bei unkomprimierten Codecs hat man keinen wirklichen Einfluss auf die Bitrate und diese ist abhängig von der Auflösung, Framerate, Bittiefe und Subsampling. Kann man sogar recht einfach berechnen.

Für YUV444p8: 720x576 = 414720 Pixel je Frame * 25FPS entspricht 10.368.000 Pixel je Sekunde * 8 bzw. 10 für die Bittiefe = 82.944.000bpsY + 82.944.000bpsCb + 82.944.000bpsCr = 248Mbps. Wir sind uns einig, dass das unnötig viel ist.

Quote from LigH

Können wir nicht das Problem der senkrechten Streifen erst einmal lösen, also mal etwas Beispielmaterial sehen, um eventuell die Ursache dafür zu erahnen?

Absolut, er hat da so eine Art Moiré-Effekt (trifft es ganz gut) oder Dotcrawl, was die Aufnahme meiner Meinung nach ziemlich unbrauchbar macht. Die Auflösung zu halbieren ist nicht wirklich das Heilmittel dafür. (Habe mir mal erlaubt ein Bild vom Capture des TE zu machen und hier anzuhängen. Falls das nicht erwünscht ist, bescheid geben und ich nehme es wieder raus) Vergrößert auf 300%

Quote from Pro Jo

nachträglich schneiden will, z. Bsp. mit einem Schnittsystem, dann sollte man das vor dem Import in ein Schnittsystem, zu I-Frame only wandeln. Das ist vielleicht dir bekannt, aber meistens den Anfängern nicht. Aber, warum hast du dann wieder 4 Ref-Frames geschrieben?

Die Sache einfach halten. Wenn nur normale Schnitte benötigt werden und keine Effekte oder Übergange / Fade-in oder Fade-out, dann kann man das Schneiden einfach gleich in seinem Avisynth-Script abarbeiten. (Trim)

Quote from Pro Jo

Der „End-Codec“ z. Bsp. H.264, wird dann vom Encoder erzeugt. Dann kann man auch 4 Ref.-Frames einstellen.

Davon rede ich ja. Avisynth-Script erstellen und x264 damit füttern. Preset veryslow und CRF 18-23 wie erwähnt.

Mein Script für seinen geposteten Capture sähe wie folgt aus. Weiß allerdings nicht, ob Farbraumconvertierung korrekt ist. Sieht erstmal nicht verkehrt aus.

 25: ConvertToYUV420(interlaced=true)
 26: ConvertBits(8)
 27: AssumeTFF()
 28: QTGMC(preset="Very Fast", InputType=0, sourceMatch=3, sharpness=0, tr2=2, ediThreads=8)
 29: Levels(0, 1.0, 255, 16, 235, coring=false)
 30: Crop(12, 10, -14, -16)
 31: BicubicResize(756, 550)