Wie sieht eure Erfahrungen mit x264 10bit?
Wie viel langsamer ist das Encoding?
Wie viel bringt es wirklich im Gegensatz zu 8bit? (wirklich 5-10%?)
Womit guckt ihr euch das 10bit Material an? (momentan scheinen an kostenlosen Decodern ffplay und lavvideo zu gehen)
Wäre schön, wenn ein paar Leute ihre Erfahrungen posten könnten. 
Cu Selur
Das encoden dauert gut 50% länger dafür werden die Datei grössen bis zu 20-30% kleiner, Raw mit 623 mb wurde 128Mb gross mit zusätzlichen filter in avi script wurde sogar der blur und denoise effekt reduziert.natürlich kann ich dank 10 bit auch mit viel weniger fps encoden. Das Bild bleibt aber auf dem gleichen Niveau wen nicht sogar besser. Ankuck wird es mit Mplayer, ich habe mit verscheidenen software den 10bit encode gestestet, mediacoder ffdshow x264gui, Das Hybrid von dir hab ich noch nicht ausbrobiert. Alle quellen wurden immer über avisynth script geladen. Angelblich kann der neue vlc auch 10 bit videos abspielen wurde aber noch nicht gestestet.
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : High 10@L3.0
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für ReFrame : 2 frames
Codec-ID : avc1
Codec-ID/Info : Advanced Video Coding
Dauer : 6min 19s
Bitraten-Modus : variabel
Bitrate : 1 000 Kbps
maximale Bitrate : 22,5 Mbps
Breite : 768 Pixel
Höhe : 432 Pixel
Bildseitenverhältnis : 16:9
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 29,970 FPS
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 10 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.101
Stream-Größe : 43,6 MiB (88%)
verwendete Encoder-Bibliothek : x264 core 115 r1995 c1e60b9
Kodierungseinstellungen : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=1 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=abr / mbtree=1 / bitrate=1000 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Kodierungs-Datum : UTC 2011-06-27 16:53:06
Tagging-Datum : UTC 2011-06-27 16:53:08Audio
ID : 2
Format : MPEG Audio
Format-Version : Version 1
Format-Profil : Layer 3
Format_Settings_Mode : Joint stereo
Codec-ID : 6B
Dauer : 6min 19s
Bitraten-Modus : konstant
Bitrate : 128 Kbps
maximale Bitrate : 134 Kbps
Kanäle : 2 Kanäle
Samplingrate : 44,1 KHz
Stream-Größe : 5,79 MiB (12%)
verwendete Encoder-Bibliothek : LAME3.98r
Hier der vergleich einmal mit x264 8bit und einmal mit 10 bit alle Einstellungen waren sonst die selben.
kurze frage:
was ist dieses 10 bit überhaupt?
und wie beeinflusst es das encoding?
bleibt die qualität beim alten verfahren bei ähnlichen einstellungen gleich?
Man muss unterscheiden zwischen 10bit Farbraum (4:2:2; gegenüber 8bit 4:2:0) und der mit der Unterstützung einhergehenden generellen Erweiterung der Genauigkeit der Berechnungen, da nicht mehr nur 8bit sondern 10bit verwendet werden können.
Bei http://www.x264.nl/ sind ein paar nette Links:
10bit-depth output information links: .pdf 01 .pdf 02 .pdf 03
pdf 01 -> Warum 4:2:2 schöner ist als 4:2:0 (banding&co).
pdf 02 -> Warum 10bit Genauigkeit besser sind als 8bit.
pdf 03 -> 01&02 in einer Präsentation zusammengefasst.
Nachteile sind, dass:
1. zumindest aktuell die 10bit Variante langsamer ist
2. man das High10-Profil verwenden muss
Cu Selur
Also im klartest heisst das 10 Bits Farbtiefe pro Kanal XD
Zunächst einmal: Was bedeutet Farbtiefe?
Die Farbtife gibt an, mit welcher Präzision Farbinformationen abgespeichert werden können. Die bisherigen Encodes haben eine Präzision von 8Bits (256 Abstufungen) pro Farbkanal, das heisst insgesamt 12 Bits pro Pixel (bzw. nach der Konvertierung zu RGB dann 24 Bits pro Pixel, was der Farbtiefe der meisten Systemen entspricht).
Man könnte auch 9 Bits pro Farbkanal verwenden, aber egal das lassen wir mal Beiseite.
Bei Encodes mit 10 Bits pro Farbkanal stehen 1024 Abstufungen und 15 bzw. 30 Bits pro Pixel zur Verfügung, was natürlich wesentlich genauer ist. Aber: Die meisten im Handel erhältlichen Anzeigegeräte und Grafikkarten zeigen nur 24 Bits pro Pixel an.
Nun was machen Dagegen
Dazu ein wenig Info nebenbei: Die meisten LCD Displays (TN-Panels, um genau zu sein) können nur eine Farbtiefe von 6 Bits pro Kanal (gerade einmal 64 Abstufungen) darstellen. Das würde natürlich unter Normalen Umständen absolut schrecklich aussehen. Daher bedient man sich eines Tricks: Um die Farbtiefe von 8 Bits zus imulieren, kommt Dithering zum Einsatz. Dithering heisst stark vereinfacht ausgedrückt, dass der Controller des Panels mit einem dynamischen Muster schnell zwischend en nächstgelegenen Farbwerten der einzelnen Pixel wechselt. Hierzu sieht er in einer Tabelle, der sogenannten Lookup Table oder auch LUT nach, welche Farbe wie dargestellt werden kann.
Genau diesen Trick kann man auch bei der Darstellung von High-Bit-Depth-Encodes anwenden.
Man könnte jetzt einfachh mit 8 Bits encoden und das Dithering gleich einbauen. Das würde selbstverständlich gehen und wird auch schon so gemacht um Banding zu vermeiden. Allerdings hat das auch einen gewaltigen Nachteil: Die Bitrate, die erforderlich ist, um dieses Dithering und andere Details beizubehalten, ist sehr hoch.
Aus diesem Grund sit eine hohe Farbtiefe beim Encode sehr vorteilhaft. Man kann sich das Dithering und somit auch jede Menge Bits sparen.
Die höhere Präzision steigert auch die QAllgemeine Effizienz des Encoders.
Um zu verdeutlichen, wie sehr die Effizienz gesteigert wird, siehe oben mein beispiel des Qualitätsunterschieds
oder zb Eine Videospur hat etwa 623 MiB bei 8 Bits Farbtiefe.
Dasselbe Material — also immer noch 8 Bits und mit bereits manuell hinzugefügtem Dithering — mit denselben Einstellungen braucht bei 10 Bits pro Kanal gerade mal 128 MiB, und das ohne Qualitätsverluste — im Gegenteil: der Encode sieht sogar besser aus.
Was ich noch nicht versucht habe sit, wenn man das entsprechende Dithering dem Encoder überlässt und diesen einfach mit hoher Farbtiefe füttert, sollte das Ergebnis sogar noch besser ausfallen, muss ich aber auch noch zuerst mal testen
Okay lauter Vorteile hier nun die Nachteile
Den die gibt es lieder auch, und zwar unterstützt derzeit noch nichts ausser MPlayer und meinen gepatchten MPlayer2-Builds diese Encods. Alles andere zeigt entweder gar kein Bild oder man bekommt stark verfälschte Farben, weil versucht wird, das Video zu dekodieren, als hätte es nur 8 Bits pro Kanal.
Die noch traurigere Nachricht ist, dass es aufgrund von Schwierigkeiten in der Entwicklung (völlig verkorkster Code) wohl noch sehr lange dauern wird, bis MPC-HC und FFdshow-tryouts dies unterstützen werden. Selbst VLC wird wahrscheinlich schneller dran sein. Bei CoreAVC und Hardware-Dekodern sieht es noch düsterer aus. Des Weiteren ist der für das Dekodieren und Dithern zuständige Code in FFmpeg noch nicht sehr gut optimiert, benötigt also eine höhere CPU-Leistung. Das sollte sich aber in nächster Zeit ändern. Wobei es da auch einen Hoffnungsschimmer gibt CCP und FFdshow haben erst kürzlich 10bit taugliche Versionen realisiert.
deutlich kleinere Encodes, aber gleiche oder leicht bessere Qualität
Es kann also nur besser werden!
Andere Frage, wann bringt x264 eine Version raus die 4.2:2 unterstützt??
funktioniert der 10bit vorteil auch noch bei sehr einfach gehaltenen animatinen/cartoons/optimierten animes? da müsste man theoretisch mit einem niedigerem farbraum und ohne dithering auskommen...
und wie verhält sich 8/10bit zu RGB24?
da sollte es jakeine probleme mit farbüberläufen geben...
Farbraum:
10bit -> kein Banding (es sei den es ist in der Quelle und man dithered nicht)
8bit -> wie bis her immer: banding es sei denn man dithered beim Playback
Precission:
10/8bit hat damit eigentlich nix zu tun. 
Das Anfangs verwirrende ist, dass man in von x264 eine 8bit und eine 10bit Variante hat, die beide aber durchaus auch 4:2:2 (10bit) als Farbraum output haben können, aber intern anders rechenen.
8bit + 4:2:2 -> High 4:4:4 Profile
10bit + egal ob 4:2:0, 4:2:2, 4:4:4 -> High10
Cu Selur
Ps.: Gerade ne neue Hybrid version rausgebracht die erlaubt den Output Colorspace zu setzen.
Andere frage was macht youtube oder Facebook mit einem 10bit video? Wird das wiederum auf 8 bit codiert? habe zum testen ein fake Profil auf fb gemacht, Kann ich jetzt irgendwie die Videoinformationen rausholen?
H264 ist doch 4:2:2 tauglich aber x 264 noch nicht oder bin ich nicht auf dem neusten Stand?
x264 --fullhelp:
...
--input-fmt <string> Specify input file format (requires lavf support)
--input-csp <string> Specify input colorspace format for raw input
- valid csps for `raw' demuxer:
i420, yv12, nv12, i444, yv24, bgr, bgra, rgb, i422
- valid csps for `lavf' demuxer:
yuv420p, yuyv422, rgb24, bgr24, yuv422p,
yuv444p, yuv410p, yuv411p, gray, monow, monob,
pal8, yuvj420p, yuvj422p, yuvj444p, xvmcmc,
xvmcidct, uyvy422, uyyvyy411, bgr8, bgr4,
bgr4_byte, rgb8, rgb4, rgb4_byte, nv12, nv21,
argb, rgba, abgr, bgra, gray16be, gray16le,
yuv440p, yuvj440p, yuva420p, vdpau_h264,
vdpau_mpeg1, vdpau_mpeg2, vdpau_wmv3,
vdpau_vc1, rgb48be, rgb48le, rgb565be,
rgb565le, rgb555be, rgb555le, bgr565be,
bgr565le, bgr555be, bgr555le, vaapi_moco,
vaapi_idct, vaapi_vld, yuv420p16le,
yuv420p16be, yuv422p16le, yuv422p16be,
yuv444p16le, yuv444p16be, vdpau_mpeg4,
dxva2_vld, rgb444le, rgb444be, bgr444le,
bgr444be, y400a, bgr48be, bgr48le, yuv420p9be,
yuv420p9le, yuv420p10be, yuv420p10le,
yuv422p10be, yuv422p10le, yuv444p9be,
yuv444p9le, yuv444p10be, yuv444p10le
--output-csp <string> Specify output colorspace ['i420']
- i420, i444, rgb
...Andere frage was macht youtube oder Facebook mit einem 10bit video?
Wenn sie es reencoden, dann sicher mit 8bit, da 10bit encoder nicht so verbreitet sind und es auch länger dauert.
(der flash player kann high10 soweit mir bekannt)
Cu Selur
Das Anfangs verwirrende ist, dass man in von x264 eine 8bit und eine 10bit Variante hat, die beide aber durchaus auch 4:2:2 (10bit) als Farbraum output haben können, aber intern anders rechenen.
In Deinem letzten Post hast Du doch selbst die x264-Hilfe zitiert: x264 unterstützt keine 4:2:2-Ausgabe. (weder mit 8, noch mit 10 Bit)
Bitte korrigiert mich, wenn ich falsch liege, aber meine Laienmeinung zu diesen Dingen: Generell scheinen hier im Thread Farbunterabtastung (4:2:0, 4:2:2 etc.) und Farbtiefe (8 bit, 10 bit) durcheinandergewürfelt zu werden, obwohl sie erst einmal nicht viel miteinander zu tun haben. Wenn die x264-Entwickler von 10 bit bzw. High 10 Profile sprechen, reden sie immer von der Präzision bzw. Farbtiefe der Ausgabe - nicht aber von einer 4:2:2-Farbunterabtastung, welche x264 ja auch gar nicht bzw. x264cli nur als Input unterstützt (Nur nebenbei: Streng genommen bedeutet "High 10 Profile" immer 4:2:0). Dies ermöglicht 64 mal mehr Farben (2^10 / 2^8) und erlaubt x264 damit besser zu Komprimieren (Kompression vor Runden ist effizienter als Kompression nach Runden, auch wenn man mit 2 Bit mehr arbeiten muß). Die Farbunterabtastung gibt nur an, in welchem Verhältnis (in horizontaler und vertikaler Richtung) die Auflösungen (Breite x Höhe in Pixeln) der Farb- und Helligkeitskanäle zueinander stehen. 4:2:2 bringt bezüglich Bandings nicht die Vorteile gegenüber 4:2:0, welche 10 Bit Farbtiefe gegenüber 8 Bit Farbtiefe bringt.
x264 unterstützt keine 4:2:2-Ausgabe
Jetzt schon. -> http://git.videolan.org/?p=x264.git;a=…98e36d6492ffa7e
Frage ist nur, welcher Decoder kann 4:2:2 AVC handeln?
hab mal drei Samples erstellt (http://www.multiupload.com/QGSL0TFVRV):
mencoder422:
mencoder "G:\Hybrid\test - clips\test.avi" -ovc raw -noskip -vf scale,format=yuy2 -forcedsubsonly -nosub -nosound -mc 0 -lavdopts threads=8 -really-quiet -ofps 25 -of rawvideo -o - | x264 --crf 18 --level 4.1 --no-8x8dct --vbv-maxrate 150000 --vbv-bufsize 187500 --input-csp i422 --output-csp i422 --fps 25 --input-res 640x352 --output "D:\Encoding output\mencoder422.mp4" -ffmpeg422:
ffmpeg -v -10 -i "G:\Hybrid\test - clips\test.avi" -threads 8 -vsync 0 -an -r 25 -pix_fmt yuyv422 -f rawvideo - | x264 --crf 18 --level 4.1 --no-8x8dct --vbv-maxrate 150000 --vbv-bufsize 187500 --input-csp i422 --output-csp i422 --fps 25 --input-res 640x352 --output "D:\Encoding Output\ffmpeg422.mp4" -x264_422:
x264 --demuxer auto --input-csp 420 --no-interlaced --output-csp i422 --crf 18 --level 4.1 --no-8x8dct --vbv-maxrate 150000 --vbv-bufsize 187500 --output-csp i422 --fps 25 --output "D:\Encoding Output\x264_422.mp4" "G:\Hybrid\test - clips\test.avi"4:2:2 wird von libav momentan noch nicht unterstützt, der einzige Decoder der es aktuell kann ist vermutlich der von Mainconcept 
Cu Selur
egal ob 10bit oder 422
welcher decoder kann das überhaupt?
wirklich nur Mainconcept?
gibt es denn bei 10bit mehr decoder?
ffdshow und vlc haben jedenfalls schonmal versagt.
interressant sind die leute von vlc,
baun mit am x264 encoder, aber decodieren können die es nicht.
wie wollen die den encoder überhaupt prüfen!?
ich habe den neusten (1.1.11)
Für 10bit:
VLC kann es ab 1.2.x, diese gibt es bisher nur als Nightlies, nicht als stabile Version. ffdshow, LAV Video, madVR und CoreAVC können es in ihren aktuellen Versionen.
Keine Ahnung, was 4:2:2 angeht.
4:2:2 wir also nur von einem kostenpflichtigen Decoder unterstützt?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!