ReJig: Discarding high Frequencies / new QMatrix

[Malcolm]

@ Nic
From time to time people are asking if it's possible to lower the resolution during the requantization/transcoding process.
this is impossible as you know. but i'm asking myself if there's a reasonable alternative to this request.
Maybe it makes sense to set all/some high frequencies to zero during requantization. As far as my understanding goes, this would be equal to lowering the resolution.
O.k. lowering the resolution is not the final goal. What you really want to achieve is making the video more compressable! (accepting the fact that the pictures gets less sharp)
Afaik: during requantization you're processing all (or some selected) dct-blocks (esp. their quantized values), lowering all values by a somehow computed factor. the result is a smaller mpeg file.
let's assume that for this test you would do a requantization WITHOUT actually lowering all quantized values by one fixed factor (as you would normally do). Instead you would only lower the high frequency components of the dct-blocks by some factor - or alternatively set them to zero if that's allowed.
example: You have a dct block with the following values:
If you set the rightmost row to zero, the you have lowered the horizontal resolution by 2, right? (correct me if i'm wrong!) (e.g. i'm not sure how the scanning order has to be taken into account here)

07 03 06 02 09 04 08 01 07 03 06 02 09 04 08 00
05 07 02 08 03 07 01 09 05 07 02 08 03 07 01 00
04 06 01 08 03 08 03 06 \ 04 06 01 08 03 08 03 00
01 05 08 03 05 09 02 07 ---\ 01 05 08 03 05 09 02 00
09 06 04 08 03 05 09 01 ---/ 09 06 04 08 03 05 09 00
06 03 08 02 01 06 08 03 / 06 03 08 02 01 06 08 00
04 01 07 08 04 09 03 06 04 01 07 08 04 09 03 00
01 03 07 03 09 05 07 03 01 03 07 03 09 05 07 00

Like this, you have 'pre-compressed' the mpeg stream. Additionally you can requantize this pre-compressed mpeg stream further to get to the desired final size.
A more general approach to this issue would be to use an additional qmatrix that the original dct values are divided with. so the user can decide which frequency-components to lower/set to zero.
I hope you're interested in my idea. And maybe - as the author of ReJig - you can test this (with a quick modification of ReJig)? :rolleyes:
I would be interested if setting all rightmost values in the dct-blocks brings some noticeable compression.

Greetings,
Malcolm

[Malcolm]

I did some quick tests using ReStream. With ReStream you can change various parameters in MPV files. One thing you can change is the qmatrix (intra + non-intra). So you can use a different qmatrix for decoding then for encoding. this makes not much sense normally.
But like this you can simulate one part of what i've described above.
what you can simulate is how a video looks when the rightmost row(s) are set to zero.
what you can not simulate is the space that you can gain.

i have created several qmatrices where in the rightmost rows all values are set to one. then i have patched these qmatrices into a test clip and checked how the clip looked after decoding.

The intra-qmatrix for decoding looks like this:
8,16,19, 1, 1, 1, 1, 1,
16,16,22, 1, 1, 1, 1, 1,
19,22,26, 1, 1, 1, 1, 1,
22,22,26, 1, 1, 1, 1, 1,
22,26,27, 1, 1, 1, 1, 1,
26,27,29, 1, 1, 1, 1, 1,
26,27,29, 1, 1, 1, 1, 1,
27,29,35, 1, 1, 1, 1, 1,
In the original qmatrices - used during encoding values were in the range of 24 - 99 (that means the video-data is divided by these values). by using values of '1' during decoding the encoded video data for high frequencies are multiplied only by 1. this means effectively that they are (nearly) suppressed!

i found out that you can set at least the 4 rightmost rows to one before you can see a visual degradation!!

So if you alternatively set the video-data for these rows to 0/1 during transcoding then this should give a lot of potential compressability!

Greetings,
Malcolm

[Noah]

Originally posted by Malcolm
I hope you're interested in my idea. And maybe - as the author of ReJig - you can test this (with a quick modification of ReJig)?
Rejig is open-source, so if you're up to modifying it yourself, go for it. Nic has been sitting on 0.6 for a while, so I don't know how interested he is in futher development.

[Malcolm]

Sorry,
i don't have the tools, the time and the knowledge to do it!

Greetings,
Malcolm