https://cardinalpeak.com/blog/the-h-264…-parameter-set/
https://en.wikipedia.org/wiki/Exponential-Golomb_coding
Hilft das? Die Teile sind wie z.B. UTF-8 teilweise mit variabler Länge codiert.
Beiträge von sneaker2
-
-
Was kann die, was die "offizielle" nicht kann?
Die ist LARGEADDRESSAWARE, d.h. sie kann trotz 32 bit-Prozess 4 GB nutzen. -
Ja, klingt logisch. Teste mal folgende VirtualDub-Version: https://www.mediafire.com/?5wdk1o6wm7c94zz
Wenn das nicht reicht: pipen (z.B. avs2pipemod). Wenn auch das nicht reicht: MTS-Dateien vorher zusammenfügen, dann in AviSynth öffnen, oder AviSynth 64 bit.
-
Ich glaube, Du schaust Dir die falschen Bits an. Wenn Du etwas nach links/rechts schaust, paßt es. Jede Verschiebung um ein Bit im Binärsystem ist Multiplikation mit 2, darum immer diese Faktoren.
80 40 00 00 FA C0 00 17 70 02 00 => 1000 0000 01[00 0000 0000 0000 0000 0000 1111 1010 11][00 0000 0000 0000 0001 0111 0111 0000 00]00 0010 0000 0000
0000 0000 0000 0000 0000 0011 1110 1011 => 1003
0000 0000 0000 0000 0101 1101 1100 0000 => 24000
(je 32 bit für vui_num_units_in_tick und vui_time_scale)10 00 00 3E B0 00 05 DC 00 80 00 => 0001 [0000 0000 0000 0000 0000 0011 1110 1011] [0000 0000 0000 0000 0101 1101 1100 0000] 0000 1000 0000 0000 0000
0000 0000 0000 0000 0000 0011 1110 1011 => 1003
0000 0000 0000 0000 0101 1101 1100 0000 => 24000 -
"FPS Wert"? Warum sollte das interessant sein, ob der mod-irgendwas ist? Ich kann Dir nicht folgen. Zeig mal ganz genau anhand eines Beispiels, wovon Du redest.
-
Das ist falsch.
-
Nein bzw. dann würde gar kein Bild angezeigt. Ruckler o.ä. ergeben sich nicht.
-
Unkomprimiertes SD-Material 4:4:4 liegt bei mir, laut Testfile, zwischen 335- und 350 Mbit/s. Ich nehme aber auch nur in 4:2:2, mit 165 Mbit/s auf.
Das paßt rechnerisch nicht. 4:4:4 zu 4:2:2 ist unkomprimiert Verhältnis 3 zu 2.Ja, da hast Du recht sneaker2, es reichen 14,4 Gbit/s für 4K/50/60 Hz nicht aus. Die Angaben bei Wikipedia sind nicht zu glauben. Danach soll HDMI 2.0 schon HDR unterstützen.
Dies soll aber erst in der Version 2.0 b möglich sein.
2.0a kann statisches HDR (CTA 861.3), 2.0b dynamisches inkl. HLG (CTA-861-G). Könnte sein, daß man beim "Ur-2.0" noch Dolby Vision oder so mit reinpacken konnte. Ist halt nicht standardisiert...Was lese ich da bei HDMI 2.1, es wird wieder auf 4:2:0 zurückgegangen.
Das wurde erstmalig mit HDMI 2.0 eingeführt. Eben weil wie oben gesagt, die Bandbreite nicht für 4Kp60 4:4:4 10 Bit ausreicht. HDMI 2.1 ermöglicht dann 4Kp60 4:4:4 10 Bit.Dann machen BT.2020 und HDR keinen Sinn mehr.
Weil? Sehe ich anders. Die machen unabhängig von der Auslösung Sinn. Und ob 4K jetzt 4:4:4, 4:2:2 oder 4:2:0 ist, ist für den Zuschauer im Grunde vernachlässigbar. Da sieht man keinen Unterschied. Unterschiede bei Farben und Kontrast könnte man hingegen auch bei DVD-Auflösung sehen.4K-Aufnahmen für Videoplattformen müssen extrem komprimiert werden. 4K mit 10 bit hoch zuladen wird kaum möglich sein, es sei denn man wartet geschätzt 24 Stunden und mehr.
Was man zurzeit bei den diversen Videoplattformen sieht, ist nur die Auflösung von 3840 x 2160 Pixel.
Alle anderen normgerechten Parameter sind wegen der zu hohen Datenrate, noch nicht möglich wiederzugeben.
Auf Youtube funktioniert 3840 x 2160/BT.2020/HDR/10 Bit. (4:2:0, aber wer will kann ja 8K hochladen...) -
Bei einer Steigerung der Bildqualität von 4:2:0 auf 4:2:2 hat man schon eine Verdoppelung der Bitrate.
Für Farben. Da die aber nur einen Teil der Daten ausmachen, ist 4:2:0 -> 4:2:2 nur 33% mehr Bitrate (unkomprimiert).unkomprimiert ca. 165 Mbit/s. 4:4:4 (unkomprimiert, ohne Alpha-Kanal) liegt bei ca. 350 Mbit/s.
Niemals. Selbst die 14,4 Gbit/s von HDMI 2.0 reichen nicht für 4Kp60 4:4:4 10 Bit. -
-
Wenn Du eh irgendeine Streaming-Lösung mit Transcodierung hast/planst, dann laß doch am besten von der die Untertitel einbrennen und mit hoher Bitrate streamen. Dann sollte auch die Bildqualität besser sein.
-
Banding/Blocking ist bei dunklen Bereichen und x264 8 bit in der Tat schwer wegzubekommen. Kannst ja mal im Forum nach "Banding" suchen.
Sind das UltraHD-Fernseher, so daß man ggf. auf HEVC 10 bit ausweichen könnte? Ansonsten sind Deine Ansprüche schwer zu erfüllen.
-
Welchen Fernseher hast Du denn? srt in mkv und zusätzlich als extra-Datei mit gleichem Dateinamen und das sollte fast jeder Fernseher können.
Zur Dateigröße: jetzt weißt Du, warum die meisten eher im Bereich CRF 18 bis 20 encoden. Wenn Du eine bestimmte Dateigröße haben willst (z.B. "so groß wie Originaldatei") mußt Du --bitrate statt --crf benutzen (optimalerweise mit 2 Passes).
-
Nachtrag:
so wie's ausschaut wird bei der " --repeat-headers" Option nach jedem GOP und somit vor jedem IDR Frame ein VPS, SPS, PPS und SEI_Prefix geschrieben
Nicht nur IDR, ist etwas komplizierter. Stichwort OpenGOP.Ich meine, der einzige "use case" der mir einfällt warum man überhaupt multi VPS/SPS/PPS bräuchte, wäre beim TV wenn zwischen 4k/HD/SD umgeschaltet wird.
Und woher bekomme ich VPS/SPS, wenn ich frisch in einen Sender zappe? Das muß laufend gesendet werden. -
Bei niedrigen (~kleiner 16) CRF lohnt x265 IMHO nicht, oder allerhöchstens bei Anime. Große Vorteile spielt der eigentlich nur bei sehr niedrigen Bitraten aus, bei hohen Bitrate geben die sich nicht viel oder teilweise liefert x264 dann sogar bessere Ergebnisse bei schnellerem Encoding und besserer Player-Kompatibilität.
-
Danke.
Falls Du Clips für Multi-SPS brauchst, einfach mit x265 --repeat-headers encoden.
-
nahezu Original und Unterschiede sieht man als normal sterblicher auch bei 4k Inhalte nicht
Insbesondere bei 4K nicht. Je höher die Auflösung ist, desto mehr Bits nutzt x264 bei ansonsten konstantem CRF.CRF 10 ist selbst für PAL-Auflösung meist Overkill. Teste auf jeden Fall auch mal Werte im Bereich 18 oder 20, nur zum Vergleich. Kommt aber natürlich auf Deine Ansprüche an.
-
Hast Du VLC 32 bit oder 64 bit getestet?
-
Ganz grob: ja.
Genauer gesagt: nein. Sowohl crf als auch preset drehen Parametern, die sowohl Dateigröße als auch Qualität ändern können. (außer halt bei qp=0, weil lossless lossless ist und sich da an der Qualität nichts ändern kann)Üblicherweise wählt man deshalb erst das preset, welches einem noch schnell genug ist, und anschließend einen CRF, bis einem die Qualität ausreichend ist. (Bei noch genauerer Betrachtung sieht man allerdings, daß auch CRF die Geschwindigkeit etwas beeinflußt.)
-
Worum es mir geht ist das ich Untertitel einbrennen kann bei lossless bzw. nahezu lossless da ich schon oft die Erfahrung gemacht habe das jeder Fernseher der MKV Dateien abspielt eben Problme mit Untertitelspuren hat und ich möchte zumindest die "Zwangsuntertitel" immer Verfügbar haben und die Zeit fürs erstellen der MKV sollte schnell sein. Dateigröße ist egal, wobei nicht größer als Original wäre schön
Das wird so nicht funktionieren, denn die allermeisten Geräte können mit lossless H.264 nichts anfangen. Außerdem wird die Datei i.d.R. um ein Vielfaches größer als die Ausgangsdatei. Versuch es lieber mit einem "normalen" CRF wie z.B. 18. Den Rest hat LigH ja bereits erklärt.
