x264 Lossless Mode und unterschiedliche Einstellungen,...

Selur

Mich würde interessieren in wie weit DeBlocking, motion estimation&co, trellis, max references, cabac, no dct decimation, no fast p-skip, Custom Quantizer Matrizen und Macroblock Optionen einen Einfluss auf den Lossless Mode von x264 haben. (In MeGui lassen sich diese Features auch im Lossless Mode aktivieren/konfigurieren.

Kann da jemand was zu sagen?
Macht es auf das Endresultat keinen Einfluss? Ist das Endresultat vielleicht nicht mehr Lossless je nach Option? (vor allem bei Noise Reduction vermute ich ist dies der Fall)
Wird eventuell alles ignoriert was ich sonst noch einstelle?
....

Cu Selur

Ps.: hab auch mal im englischen Forum was dazu gepostet: http://forum.doom9.org/showthread.php?t=123261

Kopernikus

Ich würde vermuten (ohne jetzt in den Code geschaut zu haben):

Keinen Einfluss:
Deblocking (ist bei niedrigen Quantizern eh deaktiviert), trellis (es findet keine Quantisierung statt, also auch kein Grund, das zu optimieren), CQM, no dct decimation

Einfluss:
motion Estimation, max references, cabac, Macroblock optionen, da das die Qualität der Voraussage ändert, wird es auch einen Einfluss auf die Endgröße haben.

Selur

Danke schon mal, so etwa hab ich mir das auch gedacht.

Bleibt also noch die Frage:

Nutzt wer Lossless und hat mal etwas rumprobiert und kann sagen in wie weit Motion Estimation&Co die Endgröße beeinflussen?

Cu Selur

Selur

Habe mal ein paar Tests gemacht:

Lossless 1

Code

--qp 0 --ref 6 --mixed-refs --no-fast-pskip --bframes 6 --b-pyramid --b-rdo --bime --weightb --direct auto --nf --subme 7 --trellis 2 --analyse all  --8x8dct --b-bias 20 --me esa --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless1.mp4" "G:\filmworks\Wunder.avs"

Speed: 6,87fps
Size: 77,6 MB

Lossless 2

Code

--qp 0 --no-cabac --subme 1 --analyse p8x8,b8x8,i4x4 --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless1.mp4" "G:\filmworks\Wunder.avs"

Speed: 36,46fps
Size: 90,8 MB

Lossless 3 (Load Default + High Profile + Lossless)

Code

--qp 0 --analyse p8x8,b8x8,i4x4 --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless 3.mp4" "G:\filmworks\Wunder.avs"

Speed: 19,9fps
Size: 78,4 MB

Lossless 4 (Load Default + High Profile + Lossless + Deblocking off)

Code

--qp 0 --nf --analyse p8x8,b8x8,i4x4 --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\filmworks\Wunder.mp4" "G:\filmworks\Wunder.avs"

Speed: 19,98fps
Size: 78,4 MB

Lossless 5 (Load Default + High Profile + Lossless + CABAC off)

Code

--qp 0 --no-cabac --analyse p8x8,b8x8,i4x4 --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless 8.mp4" "G:\filmworks\Wunder.avs"

Speed: 29,8fps
Size: 89,9 MB

Lossless 6 (Load Default + High Profile + Lossless + Subpixel Refinement 7)

Code

--qp 0 --subme 7 --analyse p8x8,b8x8,i4x4 --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless 5.mp4" "G:\filmworks\Wunder.avs"

Speed: 12,01fps
Size: 78,1 MB

Lossless 7 (Load Default + High Profile + Lossless + Number of Reference Frames 6)

Code

--qp 0 --ref 6 --analyse p8x8,b8x8,i4x4 --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless 6.mp4" "G:\filmworks\Wunder.avs"

Speed: 17,4fps
Size: 77,6MB

Lossless 8 (Load Default + High Profile + Lossless + Macoblock Options -> All)

Code

--qp 0 --analyse all  --8x8dct --threads auto --thread-input --progress --no-psnr --no-ssim --output "G:\lossless 6.mp4" "G:\filmworks\Wunder.avs"

Speed: 17,08fps
Size: 78,8MB

Cu Selur

Henrik

Selur
Wenn ich das richtig sehe,die höchste erreichte fps erzeugt hat auch am meisten MB. (Lossless 2) Und was sagst du zu den sichtbaren Unterschieden,falls es welche gibt.

Wie viel größer ist die Endgröße gegenüber CRF ??
Lohnt sich Lossless,deine Einschätzung bzw Empfehlung ?

Selur

Zitat

Und was sagst du zu den sichtbaren Unterschieden,falls es welche gibt.

Verlustfrei ist verlustfrei, da darf&kann es keine Unterschiede nach dem Decoden geben.

Zitat

Wie viel größer ist die Endgröße gegenüber CRF ??

Keine Ahnung ich nutz crf fast nie. Für mich ist der Vergleich aber auch unsinnig, da ich entweder verlustfrei will oder nicht. Und crf ist nicht verlustfrei.

Zitat

Lohnt sich Lossless,deine Einschätzung bzw Empfehlung ?

Wenn man lossless braucht lohnt es sich definitiv. Will man es einiges Schneller und kann mit einer Größeren Datei leben sollte man CABAC deaktivieren, will man es lieber kleiner sollte man die Anzahl der Referenzen erhöhen.

Cu Selur

Henrik

Selur
THX
Die geringste fps bei dir, 6,87fps habe ich (P2 2GHz) noch nie erreicht...(jammer heul.. Neuer Rechner muss her)

Deinorius

Von den ganzen Tests finde ich Lossless 2 und 4 am interessantesten.

Aber mich würde noch der Vergleich mit ffdshow-HuffYUV, Lagarith und MSU interessieren. Ne Möglichkeit selber was zu testen (vielleicht mit 1080p Elephants Dream).

Selur

Die anderen Codecs interessieren mich ehrlich gesagt nicht, oder nur kaum.
Aber falls jemand die entsprechenden Codecs installiert hat kann er ja mal nen Vergleich machen. (Gibt dergleichen auch im englischen Doom9 Forum soweit ich mich entsinne.)

Cu Selur

Deinorius

Soviel hab ich bis jetzt verglichen.
Source: Elephants Dream auf 720p resized
geordnet nach Größe (und damit praktisch auch nach fps :D)

ffdshow-huffYUV (default; Adaptive Huffman Tables)
ca. 37,3 fps: 5,18 GB

Lagarith (default, MT aktiviert)
ca. 37 fps: 3,95 GB

FFV1 (default)
23,92 fps: 3,46 GB

x264 (CQ_Lossless, CABAC deaktiv., subme 1, diamond, M.E. Range 12)
24,07 fps: 3,30 GB

Code

--qp 0 --nf --no-cabac --subme 1 --analyse p8x8,b8x8,i4x4,p4x4 --me dia --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim

x264 (CQ_Lossless, CABAC deaktiv., subme 3, diamond, M.E. Range 12)
21,63 fps: 3,25 GB

Code

--qp 0 --nf --no-cabac --subme 3 --analyse p8x8,b8x8,i4x4,p4x4 --me dia --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim

x264 (CQ_Lossless)
14,41 fps: 2,84 GB

Code

--qp 0 --nf --subme 3 --analyse p8x8,b8x8,i4x4,p4x4 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim

x264 (CQ_Lossless, subme 5, M.E. Range 12)
12,15 fps: 2,81 GB

Code

--qp 0 --nf --analyse p8x8,b8x8,i4x4,p4x4 --merange 12 --threads auto --thread-input --progress --no-psnr --no-ssim

MSU (default)
ca. 9,3 fps: 2,57 GB

Also derzeit würde ich sagen, dass Lagarith und x264 die beste Wahl (besonders bei DualCore) sind.

HQ-LQ

sind die videos (besonders bei x264) wirklich lossless
mal beim rückrechnen den CRC vergichen?

Selur

Zitat

sind die videos (besonders bei x264) wirklich lossless

Sofern das Inputmaterial schon im richtigen Farbraum war: Meines Wissens nach ja.

Zitat

mal beim rückrechnen den CRC vergichen?

Nö.

Cu Selur

Deinorius

Bei MSU gibts ja Einstellungen, die Lossless nur auf der subjektiven Ebene wirken lassen, aber das ist eher die Ausnahme.

Ist das Rückrechnen mit CRC nicht der falsche Weg? Wenn ich mich nicht irre, müssen die Bits und Bytes identisch sein, nicht aber die Bildqualität. oO

Redfox

Zitat von Deinorius

Bei MSU gibts ja Einstellungen, die Lossless nur auf der subjektiven Ebene wirken lassen, aber das ist eher die Ausnahme.

Im Gegenteil, alle Lossy-Codecs versuchen das. ;D
Aber du hast recht - Lossles codecs die nicht lossless sind, sind selten.

Zitat von Deinorius

Ist das Rückrechnen mit CRC nicht der falsche Weg? Wenn ich mich nicht irre, müssen die Bits und Bytes identisch sein, nicht aber die Bildqualität. oO

Zurückrechnen?

ZB.: Mpeg2(original) -> lossless -> Mpeg2(recode)

Dann sind die CRCs von Mpeg2(original) und Mpeg2(recode) mit sicherheit nicht identisch.

Wenn man allerdings zb. die ersten 1000 Frames einmal als lossless-Kompremiert speichert und einmal als unkompremierten RGB-Stream und aus dem lossless dann ebenfals einen rgb stream erstellt, dann müssten die beide die gleichen MD5-Werte haben [RGB-aus-Original==RGB-aus-Loosles).

(oder hab ich dich jetzt falsch verstanden und wir reden aneinander vorbei?)

Deinorius

Zitat von Redfox

Im Gegenteil, alle Lossy-Codecs versuchen das. ;D

Ich hab aber nur Lossless Codecs gemeint.

Zitat von Redfox

Zurückrechnen?

ZB.: Mpeg2(original) -> lossless -> Mpeg2(recode)

Dann sind die CRCs von Mpeg2(original) und Mpeg2(recode) mit sicherheit nicht identisch.

Also ich habs so verstanden, dass HQ-LQ Quelle und Lossless Video vergleichen würde, indem man die beiden Decodingstreams vergleicht.
Aber CRC ist meines Wissens nach nur für die Überprüfung der vorhandenen Dateien gebräuchlich, basierend auf den Bits, aus denen sie bestehen.

nexustheoriginal

Zitat von Redfox

Wenn man allerdings zb. die ersten 1000 Frames einmal als lossless-Kompremiert speichert und einmal als unkompremierten RGB-Stream und aus dem lossless dann ebenfals einen rgb stream erstellt, dann müssten die beide die gleichen MD5-Werte haben [RGB-aus-Original==RGB-aus-Loosles).

Genau.

Zitat von Deinorius

Also ich habs so verstanden, dass HQ-LQ Quelle und Lossless Video vergleichen würde, indem man die beiden Decodingstreams vergleicht.
Aber CRC ist meines Wissens nach nur für die Überprüfung der vorhandenen Dateien gebräuchlich, basierend auf den Bits, aus denen sie bestehen.

Zitat von Wiki

CRC-Werte können jedoch nicht die Integrität der Daten bestätigen. Das heißt, es ist verhältnismäßig leicht, durch beabsichtigte Modifikation einen Datenstrom zu erzeugen, der den gleichen CRC-Wert wie eine gegebene Nachricht hat. Wenn eine solche Sicherheit gefordert ist, müssen kryptografische Hash-Funktionen wie z. B. MD5 zum Einsatz kommen.

Deinorius

Zitat von Redfox

Wenn man allerdings zb. die ersten 1000 Frames einmal als lossless-Kompremiert speichert und einmal als unkompremierten RGB-Stream und aus dem lossless dann ebenfals einen rgb stream erstellt, dann müssten die beide die gleichen MD5-Werte haben [RGB-aus-Original==RGB-aus-Loosles).

Nachtrag.
Ja, so meinte ich das eigentlich in etwa. Nur kenne ich den Unterschied zwischen CRC und MD5 nicht.
Deinen Satz hab ich erst jetzt kapiert.

Selur

MSU hat gestern einen Lossless-Codec-Vergleich veröffentlicht, bei dem auch x264 dabei ist, siehe:
http://www.compression.graphicon.ru/video/codec_co…cs_2007_en.html

Zitat

1. In Video Capture and Video Editing Area the overall clear winner is
Lagarith.
2. In Maximum Compression area the overall winner is YULS.
3. The most balanced and flexible codec is FFV1: relatively good
speed and high compression for various presets.
4. In RGB24 the obvious leader for video capturing and editing is Lagarith, it
significantly outperforms competitors in this area both by speed and
compression ratio. In YUY2 and YV12 situation in video capturing and
editing slightly changes. HuffYuv becomes fastest, however the
difference in speed with Lagarith is small, while the last is much better in
compression. On some sequences in YUY2 ArithYuv is better in
compression than HuffYuv, but in general it is worse. That’s strange
taking into the account that ArithYuv uses arithmetic coding instead of
variable-length codes.
5. In the area of maximum compression the leader is YULS. However, in
RGB24 color space FFV1 is almost as good as YULS, while being much
faster. But in YUY2 and YV12 the advantage of YULS in compression
ratio is significant and obvious. In YV12 MSU also shows a good result
filling the gap in speed between slow YULS and FFV1.
6. The example of generally weak x264 results possibly demonstrates the
necessity of different approaches to lossy and lossless video
compression.
7. At the same time x264 clearly shows that multi-threading techniques can
significantly improve

Alles anzeigen

Cu Selur

Henrik

Selur
THX
Deinen Kommentar und den der anderen Spezialisten, zu den Aussagen,besonders

Zitat

1. In Video Capture and Video Editing Area the overall clear winner is Lagarith.

würde mich sehr interessieren.

Selur

Zitat

In Video Capture and Video Editing Area the overall clear winner is Lagarith.

Was soll man dazu sagen, je nach Szenario gibt es schnellere oder besser komprimierende Codecs, wenn man aber alles zusammen betrachtet ist Lagarith der Codec der das sinnigste Kompressions-/Geschwindigkeitsverhältnis über alle Farbräume betrachtet hat.

Cu Selur

Jetzt mitmachen!