x264 and high profile: custom quant matrices are here

[LigH]

Revision 266 introduces custom quant. matrices (bob0r already has rev. 267 available). This would probably lead into another extra matrices dialog for the VfW codec and the CLI GUIs, I'm afraid... ;)

There are two matrices presets: "flat" (default) and "jvt" (= "Joint Video Team"). I wonder where the JVT matrices are documented...
__

Found them inside http://trac.videolan.org/x264/file/trunk/common/set.h - at least I hope so...

[Doom9]

I'm wondering about the format of the following options:

--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

does a cqm4* always take 16 integers, and a cqm8* 64 integers?

[LigH]

From a look into the mentioned sources, this seems most probable; other examples for custom scale matrices from a different source look similar.

[falcon2000eg]

here is my first post :scared:
a quick test for the new matrices

first: "flat"

X264 --keyint 460 --subme 6 --bframe 2 --b-pyramid --ref 3 --bitrate 512 --analyse all --weightb --8x8dct --progress -o %1.mp4 %1

x264 [info]: 8x8 transform intra:63.8% inter:61.8%
x264 [info]: PSNR Mean Y:42.86 U:47.57 V:46.37 Avg:43.82 Global:43.06 kb/s:545.78
encoded 2917 frames, 7.57 fps, 545.78 kb/s


Second: "jvt"

X264 --keyint 460 --cqm jvt --subme 6 --bframe 2 --b-pyramid --ref 3 --bitrate 512 --analyse all --weightb --8x8dct --progress -o %1.mp4 %1

x264 [info]: 8x8 transform intra:80.5% inter:70.5%
x264 [info]: PSNR Mean Y:42.44 U:48.18 V:46.80 Avg:43.54 Global:42.75 kb/s:548.4
encoded 2917 frames, 7.89 fps, 548.45 kb/s


ftp://ftp3.itu.ch/av-arch/jvt-site/ 2004_03_Munich/JVT-K029r1.doc
thanx google

[omion]

There are two matrices presets: "flat" (default) and "jvt" (= "Joint Video Team"). I wonder where the JVT matrices are documented...

So, the default quantization matrix is a flat 16 matrix? Isn't that a bit... odd? I mean, I thought the whole point of the quantization matricies was to store certain frequencies at a higher quality than others. Isn't it always better to put more bits into low frequencies?

By the way, what exactly does the "rate distortion optimization" optimize? The quantizers are the same for every macroblock.

[bond]

great stuff!

i already talked with pengvado about the idea to add to x264 the ability for parsing external single cqm files, which contain all the matrices, as its already done with asp (xvid aso) and in the avc reference software. that way its possible that some pros develop such custom quant matrices files, label them and than throw them at newbies or even other encoders (eg the reference or ateme), which is a big advantage compared to having to set each value via the specific x264 commandline and than spread these commandlines aso
still he wasnt sure if he can do it soon, i hope so!

splitted to an own thread

[CREXbzh]

here is my first post :scared:
a quick test for the new matrices

first: "flat"

X264 --keyint 460 --subme 6 --bframe 2 --b-pyramid --ref 3 --bitrate 512 --analyse all --weightb --8x8dct --progress -o %1.mp4 %1

x264 [info]: 8x8 transform intra:63.8% inter:61.8%
x264 [info]: PSNR Mean Y:42.86 U:47.57 V:46.37 Avg:43.82 Global:43.06 kb/s:545.78
encoded 2917 frames, 7.57 fps, 545.78 kb/s


Second: "jvt"

X264 --keyint 460 --cqm jvt --subme 6 --bframe 2 --b-pyramid --ref 3 --bitrate 512 --analyse all --weightb --8x8dct --progress -o %1.mp4 %1

x264 [info]: 8x8 transform intra:80.5% inter:70.5%
x264 [info]: PSNR Mean Y:42.44 U:48.18 V:46.80 Avg:43.54 Global:42.75 kb/s:548.4
encoded 2917 frames, 7.89 fps, 548.45 kb/s

You do not seem to be encoding with 2 passes, which leads to a different mean bitrate. Though some people know some formulats to convert a certain %age of change in the bitrate into a PSNR change, I do think it's even simple if you use 2 passes all the time, so you don't have to do some magic with the figures. :D

[falcon2000eg]

You do not seem to be encoding with 2 passes, which leads to a different mean bitrate. Though some people know some formulats to convert a certain %age of change in the bitrate into a PSNR change, I do think it's even simple if you use 2 passes all the time, so you don't have to do some magic with the figures. :D

Sorry but it was an ULTRA quick test :D

[omion]

Can anything play non-standard matricies yet? I'm getting weird artifacts playing JVT with FFDshow (20050619)...

[bond]

Can anything play non-standard matricies yet? I'm getting weird artifacts playing JVT with FFDshow (20050619)...
all libavcodec based players cant play them (mplayer, ffdshow, videolan...) as there is no support for cqm added till now to libavcodec, but nero's decoder should handle them already afaik

[CREXbzh]

all libavcodec based players cant play them (mplayer, ffdshow, videolan...) as there is no support for cqm added till now to libavcodec, but nero's decoder should handle them already afaik

But this is being worked on since this week-end by Måns Rullgård. This should be possible to play CQM... ehrm... well, when it's ready! :)

[bond]

cool!

[Doom9]

By the way, for those wishing to test but unfamiliar with commandline tools: MeGUI (http://forum.doom9.org/showthread.php?t=96032) already supports custom commandlines.

So if, for instance, you want to test the jvm matrix, just plug "--cqm jvt" withouth " into the textbox in the x264 configuration (the more tab), and then you can start encoding.

Or if you want to use the following 4x4 matrix:
16 15 14 13
13 14 15 16
12 11 10 15
16 16 16 16

Plug in the following into that field: (take the first line, separate values by commas, take the 2nd line, etc.)

--cqm4 16,15,14,13,13,14,15,16,12,11,10,15,16,16,16,16

The same goes for any other matrix you'd like to use. Obviously, you probably won't write 20 16x16 matrices, but you can share the strings here.

[defunkt]

pengvado is a coding machine.

[falcon2000eg]

another test for the jvt matrix two passes this time

first: "flat"

x264.exe --progress --pass 2 --bitrate 512 --stats "\x264.stats" --subme 6 -
-ref 3 --threads 1 --filter 0:0 --keyint 450 --min-keyint 25 --scenecut 40 --qpm
in 10 --qpmax 49 --qpstep 4 --direct temporal --me hex --merange 16 --sar 1:1 --
bframes 2 --weightb --b-pyramid --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp
0.60 --analyse all --8x8dct -o "\output.mp4" "E:\New.avs"

x264 [info]: 8x8 transform intra:63.4% inter:60.8%
x264 [info]: PSNR Mean Y:42.61 U:47.44 V:46.20 Avg:43.59 Global:42.95 kb/s:512.9
encoded 2917 frames, 8.17 fps, 513.01 kb/s



Second: "jvt"

x264.exe --progress --pass 2 --cqm jvt --bitrate 512 --stats "\x264.stats" -
-subme 6 --ref 3 --threads 1 --filter 0:0 --keyint 450 --min-keyint 25 --scenecu
t 40 --qpmin 10 --qpmax 49 --qpstep 4 --direct temporal --me hex --merange 16 --
sar 1:1 --bframes 2 --weightb --b-pyramid --b-bias 0 --ipratio 1.40 --pbratio 1.
30 --qcomp 0.60 --analyse all --8x8dct -o "\output1.mp4" "E:\New.avs"

x264 [info]: 8x8 transform intra:80.4% inter:70.7%
x264 [info]: PSNR Mean Y:42.20 U:48.06 V:46.65 Avg:43.31 Global:42.66 kb/s:512.4
encoded 2917 frames, 8.02 fps, 512.45 kb/s


any one know why there is a big deffrince in 8x8 transform line ?

[Doom9]

I'm also wondering about the allowable range of each coefficient. uint8 seems to suggest 1 byte or 0-255. Is that correct?

[Sharktooth]

1-255

[LigH]

The reference seems to allow different matrices for Cb=U and Cr=V chrominance planes, x264 does as well; a third tool not (yet?). But that shall be marginal, I hope...

[Sharktooth]

Well, ChromaU and ChromaV can be combined in a single matrix.
As i said (on irc though) AVC offers too much control over quantization.

[bond]

ok there seems to be a problem with setting custom quant matrices via dos commandline when the commandline gets too long, eg try the following one, setting the "q_matrix (http://forum.doom9.org/showthread.php?t=96159)" cqm:

x264 --bitrate 700 --cqm4i 6,12,19,26,12,19,26,31,19,26,31,35,26,31,35,39 --cqm4p 9,13,18,21,13,18,21,24,18,21,24,27,21,24,27,30 --cqm8i 6,10,13,16,19,24,26,28,10,12,16,19,24,26,28,31,13,16,19,24,26,28,31,33,16,19,24,26,28,31,33,35,19,24,26,28,31,33,35,37,24,26,28,31,33,35,37,39,26,28,31,33,35,37,39,42,28,31,33,35,37,39,42,44 --cqm8p 9,12,14,16,18,19,21,22,12,13,16,18,19,21,22,24,14,16,18,19,21,22,24,25,16,18,19,21,22,24,25,27,18,19,21,22,24,25,27,28,19,21,22,24,25,27,28,30,21,22,24,25,27,28,30,31,22,24,25,27,28,30,31,33 --ratetol 1 --threads 1 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --8x8dct --weightb --progress -o output.mp4 input.avswhen using cygwin bash and not dos batch it works

i hope pengvado can add external cqm files parsing to x264!

[LigH]

Or even better: Support for configuration files via the usual "@filename" option... ;)

[bond]

ok i now compared the following metrices listed here (http://forum.doom9.org/showthread.php?t=96159) with x264:
- flat
- jvt
- q_matrix
- q_matrix2
- soulhunter_v1

i used the following commandline:
--bitrate 770 --bframe 3 --b-pyramid --ref 5 --filter -5:-5 --analyse all --8x8dct --weightb --progress -o output.mp4 input.avsof course 2pass and with the cqm

the clip was 1000 frames of matrix1 (smith interrogating morpheus)


results:

flat
x264 [info]: slice I:8 Avg QP:17.13 Avg size: 21154 PSNR Mean Y:46.36 U:49.05 V:49.95 Avg:47.17 Global:47.12
x264 [info]: slice P:394 Avg QP:19.29 Avg size: 6222 PSNR Mean Y:44.32 U:47.85 V:48.86 Avg:45.29 Global:45.13
x264 [info]: slice B:598 Avg QP:21.01 Avg size: 2063 PSNR Mean Y:43.54 U:47.75 V:48.73 Avg:44.61 Global:44.52
x264 [info]: slice I Avg I4x4:57.7% I8x8:27.0% I16x16:15.3%
x264 [info]: slice P Avg I4x4:4.1% I8x8:7.0% I16x16:4.2% P:58.0% P8x8:10.6% PSKIP:16.0%
x264 [info]: slice B Avg I4x4:0.6% I8x8:1.8% I16x16:0.7% P:32.6% B:12.6% B8x8:2.9% DIRECT:6.8% BSKIP:42.0%
x264 [info]: 8x8 transform intra:46.9% inter:28.8%
x264 [info]: PSNR Mean Y:43.87 U:47.80 V:48.79 Avg:44.90 Global:44.76 kb/s:770.8

encoded 1000 frames, 4.17 fps, 770.88 kb/sjvt
x264 [info]: slice I:8 Avg QP:17.50 Avg size: 19112 PSNR Mean Y:44.91 U:49.32 V:50.44 Avg:46.02 Global:45.98
x264 [info]: slice P:394 Avg QP:19.63 Avg size: 6105 PSNR Mean Y:43.94 U:48.11 V:49.21 Avg:45.02 Global:44.89
x264 [info]: slice B:598 Avg QP:21.31 Avg size: 2155 PSNR Mean Y:43.39 U:47.99 V:49.04 Avg:44.52 Global:44.45
x264 [info]: slice I Avg I4x4:54.4% I8x8:29.2% I16x16:16.3%
x264 [info]: slice P Avg I4x4:4.0% I8x8:6.4% I16x16:4.4% P:60.4% P8x8:10.0% PSKIP:14.8%
x264 [info]: slice B Avg I4x4:0.6% I8x8:1.0% I16x16:0.4% P:30.7% B:11.4% B8x8:2.6% DIRECT:6.2% BSKIP:47.1%
x264 [info]: 8x8 transform intra:42.7% inter:25.7%
x264 [info]: PSNR Mean Y:43.62 U:48.05 V:49.12 Avg:44.73 Global:44.63 kb/s:769.4

encoded 1000 frames, 4.03 fps, 769.51 kb/sq_matrix
x264 [info]: slice I:8 Avg QP:17.88 Avg size: 18855 PSNR Mean Y:44.90 U:49.32 V:50.44 Avg:46.01 Global:45.98
x264 [info]: slice P:394 Avg QP:20.16 Avg size: 6165 PSNR Mean Y:44.01 U:48.14 V:49.23 Avg:45.08 Global:44.96
x264 [info]: slice B:598 Avg QP:21.76 Avg size: 2127 PSNR Mean Y:43.40 U:47.97 V:49.03 Avg:44.53 Global:44.45
x264 [info]: slice I Avg I4x4:54.4% I8x8:29.2% I16x16:16.4%
x264 [info]: slice P Avg I4x4:3.9% I8x8:6.2% I16x16:4.5% P:60.7% P8x8:9.0% PSKIP:15.7%
x264 [info]: slice B Avg I4x4:0.6% I8x8:0.8% I16x16:0.3% P:28.1% B:10.8% B8x8:2.3% DIRECT:5.2% BSKIP:51.9%
x264 [info]: 8x8 transform intra:41.7% inter:25.8%
x264 [info]: PSNR Mean Y:43.65 U:48.05 V:49.12 Avg:44.76 Global:44.65 kb/s:770.3

encoded 1000 frames, 3.76 fps, 770.46 kb/sq_matrix2
x264 [info]: slice I:8 Avg QP:17.38 Avg size: 18544 PSNR Mean Y:45.07 U:49.00 V:50.08 Avg:46.11 Global:46.08
x264 [info]: slice P:394 Avg QP:19.35 Avg size: 6126 PSNR Mean Y:44.22 U:47.99 V:49.05 Avg:45.24 Global:45.09
x264 [info]: slice B:598 Avg QP:20.99 Avg size: 2154 PSNR Mean Y:43.58 U:47.89 V:48.91 Avg:44.67 Global:44.58
x264 [info]: slice I Avg I4x4:55.4% I8x8:28.0% I16x16:16.5%
x264 [info]: slice P Avg I4x4:4.1% I8x8:5.9% I16x16:4.2% P:60.0% P8x8:10.4% PSKIP:15.4%
x264 [info]: slice B Avg I4x4:0.6% I8x8:1.1% I16x16:0.4% P:32.9% B:12.2% B8x8:2.8% DIRECT:7.3% BSKIP:42.6%
x264 [info]: 8x8 transform intra:41.8% inter:26.7%
x264 [info]: PSNR Mean Y:43.84 U:47.94 V:48.97 Avg:44.90 Global:44.79 kb/s:770.0

encoded 1000 frames, 4.10 fps, 770.13 kb/ssoulhunter v1
x264 [info]: slice I:9 Avg QP:18.67 Avg size: 20475 PSNR Mean Y:46.05 U:49.60 V:50.63 Avg:47.03 Global:46.98
x264 [info]: slice P:393 Avg QP:20.97 Avg size: 6324 PSNR Mean Y:44.13 U:48.18 V:49.22 Avg:45.18 Global:45.03
x264 [info]: slice B:598 Avg QP:22.68 Avg size: 1973 PSNR Mean Y:43.30 U:48.01 V:49.04 Avg:44.45 Global:44.36
x264 [info]: slice I Avg I4x4:52.5% I8x8:29.4% I16x16:18.1%
x264 [info]: slice P Avg I4x4:3.8% I8x8:6.8% I16x16:4.4% P:57.4% P8x8:7.9% PSKIP:19.7%
x264 [info]: slice B Avg I4x4:0.5% I8x8:0.9% I16x16:0.3% P:23.7% B:9.7% B8x8:2.1% DIRECT:3.7% BSKIP:59.1%
x264 [info]: 8x8 transform intra:44.7% inter:18.1%
x264 [info]: PSNR Mean Y:43.65 U:48.09 V:49.13 Avg:44.76 Global:44.63 kb/s:769.9

encoded 1000 frames, 4.17 fps, 770.02 kb/s
summary:

PSNR Mean Y:43.84 U:47.94 V:48.97 Avg:44.90 Global:44.79 kb/s:770.0 <- q_matrix2
PSNR Mean Y:43.87 U:47.80 V:48.79 Avg:44.90 Global:44.76 kb/s:770.8 <- flat16
PSNR Mean Y:43.65 U:48.05 V:49.12 Avg:44.76 Global:44.65 kb/s:770.3 <- q_matrix
PSNR Mean Y:43.65 U:48.09 V:49.13 Avg:44.76 Global:44.63 kb/s:769.9 <- soulhunter v1
PSNR Mean Y:43.62 U:48.05 V:49.12 Avg:44.73 Global:44.63 kb/s:769.4 <- jvt

[akupenguin]

flat... x264 [info]: slice I:8
soulhunter v1... x264 [info]: slice I:9
To prevent random fluctuations in frametype decision and ratecontrol, use 3pass encodes where all versions share the same 1st pass.

[bond]

To prevent random fluctuations in frametype decision and ratecontrol, use 3pass encodes where all versions share the same 1st pass.
hm, why a 3pass and not a 2pass with a shared first?
and the shared first pass should be done with flat?

[akupenguin]

I imagine that different quant matrices will affect the relative complexity (in bits per qp) of different frames. In a 2pass, the 2nd passes with different quants from the 1st would have a disadvantage. With 3pass, it's safe. Yes, the shared 1st should be flat.

[bond]

hehe now with r269 x264 supports parsing jm-style cqm matrices, so it gets much easier to spread and use cqm via the --cqmfile option!
thx a lot aku!

I imagine that different quant matrices will affect the relative complexity (in bits per qp) of different frames. In a 2pass, the 2nd passes with different quants from the 1st would have a disadvantage. With 3pass, it's safe. Yes, the shared 1st should be flat.
ok thx
will redo the test with a longer clip and these settings, once i find the time

[bond]

it seems i get slightly different results when using --cqm flat vs. --cqmfile flat.cfg

with flat.cfg looking exactly as follows:
# flat 16

INTRA4X4_LUMA =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTRA4X4_CHROMAU =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTRA4X4_CHROMAV =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTER4X4_LUMA =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTER4X4_CHROMAU =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTER4X4_CHROMAV =
16,16,16,16,
16,16,16,16,
16,16,16,16,
16,16,16,16

INTRA8X8_LUMA =
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16

INTER8X8_LUMA =
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16,
16,16,16,16,16,16,16,16


--cqm flat
x264 [info]: slice I:8 Avg QP:17.13 Avg size: 21154 PSNR Mean Y:46.36 U:49.05 V:49.95 Avg:47.17 Global:47.12
x264 [info]: slice P:394 Avg QP:19.29 Avg size: 6222 PSNR Mean Y:44.32 U:47.85 V:48.86 Avg:45.29 Global:45.13
x264 [info]: slice B:598 Avg QP:21.01 Avg size: 2063 PSNR Mean Y:43.54 U:47.75 V:48.73 Avg:44.61 Global:44.52
x264 [info]: slice I Avg I4x4:57.7% I8x8:27.0% I16x16:15.3%
x264 [info]: slice P Avg I4x4:4.1% I8x8:7.0% I16x16:4.2% P:58.0% P8x8:10.6% PSKIP:16.0%
x264 [info]: slice B Avg I4x4:0.6% I8x8:1.8% I16x16:0.7% P:32.6% B:12.6% B8x8:2.9% DIRECT:6.8% BSKIP:42.0%
x264 [info]: 8x8 transform intra:46.9% inter:28.8%
x264 [info]: PSNR Mean Y:43.87 U:47.80 V:48.79 Avg:44.90 Global:44.76 kb/s:770.8

encoded 1000 frames, 4.21 fps, 770.88 kb/s--cqmfile flat.cfg
x264 [info]: slice I:8 Avg QP:17.25 Avg size: 20760 PSNR Mean Y:46.28 U:48.98 V:49.87 Avg:47.09 Global:47.05
x264 [info]: slice P:394 Avg QP:19.29 Avg size: 6230 PSNR Mean Y:44.32 U:47.86 V:48.86 Avg:45.29 Global:45.13
x264 [info]: slice B:598 Avg QP:21.00 Avg size: 2061 PSNR Mean Y:43.54 U:47.76 V:48.73 Avg:44.62 Global:44.52
x264 [info]: slice I Avg I4x4:55.5% I8x8:29.0% I16x16:15.4%
x264 [info]: slice P Avg I4x4:4.1% I8x8:7.1% I16x16:4.2% P:58.0% P8x8:10.7% PSKIP:15.9%
x264 [info]: slice B Avg I4x4:0.6% I8x8:1.8% I16x16:0.7% P:32.5% B:12.6% B8x8:2.9% DIRECT:6.9% BSKIP:42.0%
x264 [info]: 8x8 transform intra:47.1% inter:28.7%
x264 [info]: PSNR Mean Y:43.87 U:47.81 V:48.79 Avg:44.90 Global:44.77 kb/s:770.7

encoded 1000 frames, 4.23 fps, 770.79 kb/swhy that?

[LigH]

Maybe the bitstream uses some amount of additional data for the scenario "use custom matrices, which are: 16,16,...", and this amount is not available for the content anymore, and reduces the video bitrate slightly in contrast to the scenario "don't use custom matrices". But I won't dare to guess the percentage... :rolleyes:

[bond]

Maybe the bitstream uses some amount of additional data for the scenario "use custom matrices, which are: 16,16,...", and this amount is not available for the content anymore, and reduces the video bitrate slightly in contrast to the scenario "don't use custom matrices". But I won't dare to guess the percentage... :rolleyes:
yep i thought about that too, but than it seems that in both cases there is no cqm stored in SPS, which is the case for the cqm encodes i did with the reference

[bond]

Maybe the bitstream uses some amount of additional data for the scenario "use custom matrices, which are: 16,16,...", and this amount is not available for the content anymore, and reduces the video bitrate slightly in contrast to the scenario "don't use custom matrices". But I won't dare to guess the percentage... :rolleyes:
ok its indeed that way: with an external flat 16 file x264 sets the cqm in the headers as for any other cqm, which, i assume, will lead to more overhead and therefore slightly different results than with --cqm flat, which doesnt set a cqm in PPS

the problem was that i used h264_parse to analyse the stream and it seems to not be able to display cqm in PPS (but only in SPS)

[Doom9]

hehe now with r269 x264 supports parsing jm-style cqm matrices, so it gets much easier to spread and use cqm via the --cqmfile option!Darned, and I'm halfway through with my visual matrix editor (that will of course read and write files using the same format). Oh well, I guess it'll still be useful for editing.

[Joe Fenton]

Funny, I was going to suggest someone write a matrix editor. That would be very handy for folks.

[Kopernikus]

There is alread a visual CQM Editor by LigH.

http://www.ligh.de/software/CQME_1.0b.zip

But it does not (yet) support AVC Matrices.

[LigH]

Before you ask:

No. I won't rebuild the whole tool to support 4x4 matrices, too.

[Doom9]

well.. I'm about halfway through.. it's not a separate program though but can easily be turned into one via a wrapper class.

[lexor]

Darned, and I'm halfway through with my visual matrix editor (that will of course read and write files using the same format). Oh well, I guess it'll still be useful for editing.
Just a question, but does it require a fully functional encoder to produce a preview of a matrix effect? Or can we somehow feed it an encoded clip of a say 1000 frames or something reasonably small, have it pick each type of frame from it and then show us the difference on each frame real time as we change the matrix. 'Couse that would be SWEET :D

[Doom9]

btw, I'm wondering.. how do --cqm4iy, --cqm4ic, --cqm4py, --cqm4pc match INTRA4X4_LUMA, INTRA4X4_CHROMAU, INTRA4X4_CHROMAV, INTER4X4_LUMA, INTER4X4_CHROMAU, INTER4X4_CHROMAV ?

I figure 4i = INTRA4x4 and c = Chroma, but is that CHROMAU or CHROMAV?

@lexor: I have no clue really. Personally I couldn't care less about matrices (they still haunt me from college), but since people seem to want it and until earlier today there was no other way than to specify those long commandlines, I started a window that can read that format, show the matrix visually, allow editing and save it back to a file. But then it's back to MeGUI full time for me (and naturally this window will be (or rather already is) part of MeGUI).

[LigH]

c = Chroma, but is that CHROMAU or CHROMAV?
Yes. ;)

Seems that --cqm4{i|p}c means: The same matrix for both Cb=U and Cr=Y planes.

[bond]

Note: JM expects CHROMAU and CHROMAV to be specified separately, whereas x264 forces them to use the same matrix. If U and V are specified to have different matrices, only the first is used.the .cfg file should have two chroma matrices set for each inter4x4 and intra4x4 even if they are identical

[Zero1]

Just a question, but does it require a fully functional encoder to produce a preview of a matrix effect? Or can we somehow feed it an encoded clip of a say 1000 frames or something reasonably small, have it pick each type of frame from it and then show us the difference on each frame real time as we change the matrix. 'Couse that would be SWEET :D


You know, I was thinking earlier about how avisynth might be of use.

Perhaps if someone can come up with an avisynth plugin that reads and applies these quant matrix files, or allows you to specify a matrix, then we could import the avs into virtualdub and hand tweak the values until we get the sort of output we want, it would serve as a way of previewing the effects a matrix would have on an image.

Of course I know relatively zero about programming, but if it is possible, it could be a useful tool to people.

[Kopernikus]

A Preview without an encoder could only preview Intra Coded Blocks without prediction. Inter Coded Blocks with residuals from motion estimation or intra prediction could not be previewed without building an encoder.

So I dont know how much sense a preview makes, because h264 uses prediction very much.

[Sharktooth]

Preview should be a short clip (250-300 frames) encoded with reference encoder or x264.