Custom Matrices

[*.mp4 guy]

I don't know what type of content is typical of 80's films, could you post some representative screenshots, or a short clip, also how long is the source.

[JarrettH]

how about a zip file of them? :devil:

[R3Z]

What would you recommend for older movies (80's) and a video bitrate of around 1400-1500. Movies like The Thing, Come and See etc. I'm using SharkTooth's HQ_Slower profile.

Those movies have a lot of grain in them so if you like grain use sharktooths EQM_HR AVC matrix or if you dont like it use a denoiser and then use whatever matrix you prefer.

[*.mp4 guy]

Matrices are attached in a 7zip archive, I'll add a link to the first post.

[Morte66]

M4G Smooth V1: An all purpose smooth matrix that blocks very little, gives a similar look to smooth mpeg2 video. -3:0 works well for inloop. Some sources may need to have b-frame mode set to none to work properly with this matrix

I've used M4G-V3 for pretty much everything since you posted it, so I was very interested in this one. I re-did my last encode with it, using my usual -2-2 deblocking for both, and your new matrix seems to be a useful improvment. Today I'm going to try it again with the -3-0 deblocking you suggested.

Thanks a lot for these matrices.

[*.mp4 guy]

I'm glad that you (and everyone else who uses my matrices) find them helpful, I'm not completely satisfied with them yet, but unfortunately I can't think of anything else to experiment with at the moment, so they won't be changing much for the time being.

Small thing about deblocking, it is in my experience mostly "in the eye of the beholder", so the settings I suggest are more guidelines then rules, and there is definately some room for tweaking them, depending primarily on source sharpness, display sharpness and personal preference. Basically you want higher deblocking settings the blurier your source and the sharper your display are, and lower deblocking settings the less you like denoising and its associated detail loss.

[huang_ch]

mp4, for M4G Smooth V1, didn't see there's a recommended deadzone settings, so do you mean using the default or also use 6/6? (My purpose is to remove blocks.)

[*.mp4 guy]

It is supposed to be used with the default deadzone settings, lowering the deadzone could help fight blocking but would cause a lot of extra ringing because of the way the smooth matrix avoids artifacts.

[freshNewB]

thanks
i used "mp4_guy's_AVC_Low_Bitrate_matrix_V2" for low bitrate (300~400kbps) 640x480 anime. the size/quality is amazing .
Is M4G-LRM-V4 good at this bitrate?
or is there a mp4_guy's_AVC_Low_Bitrate_matrix_V3 :D

[*.mp4 guy]

mp4_guy's_AVC_Low_Bitrate_matrix_V2 has been replaced by M4G LRM V4, I'm not sure wheather it will work as well on anime as the older versions, though, becuase the older versions were smoother.

[*.mp4 guy]

The HRM matrix has been more or less completely reworked and updated to v2 (see first post), and should be much more flexible now, it should give a smoother transition between "not trasnparent" and "trasnparent" results, feedback is welcome, and was invaluable in making this version of the matrix. I'm aware that some sources may exhibit banding with this matrix, even at very high bitrates, but I have no idea what to do about it, atleast for the time being, as other dificult sources with similar characteristics do not exhibit any problems I can see. This problem is why I delayed the release of this version, but as I see no possible causes or solutions to the problem at the moment, I figured it was time to release it anyway since the previous version had the same problems.

[edit] Also a very minor update to the smooth matrix, probably not noticible, but updated for consistency.

[elguaxo]

Thanks!

[check]

now that the xvid vs. x264 thread has sort of died down, can you give any personal experience / feedback on how these matrices preserve gradients and grain? In my particular case gradients are much more interesting, but I'm sure others are interested in the latter.

EDIT: in the smooth description, you say direct none might be needed. Is this a random requirement, or do certain types of video need it?

[*.mp4 guy]

EDIT: in the smooth description, you say direct none might be needed. Is this a random requirement, or do certain types of video need it?

Its pseudo random, mostly determined by how good your source is, with animated content it would be a better idea to turn off b-rdo and leave direct set to auto, as it will give better compression and avoid any artifacts just as well.

now that the xvid vs. x264 thread has sort of died down, can you give any personal experience / feedback on how these matrices preserve gradients and grain? In my particular case gradients are much more interesting, but I'm sure others are interested in the latter.

LRM (especially older versions) is heavily biased twards gradients, later revisions are a bit more balanced and keep more detail, but still favor gradients more then details, LRM differs from Smooth in that it tries to avoid impacting high frequencies to harshly, as ringing and bluring on lines can become an issue at low bitrates.

MRM does not keep gradients particularly well, at its target bitrate gradient artifacts shouldn't be a big issue with X264, since transparency isn't possible at this bitrate it makes sense to use higher compression on low frequencies because inloop deblocking will fix most of the artifacts to some extent. looks a bit like a sharper, more banding prone version of HVS best

HRM tries to be balanced, so that at a given bitrate its not easy to tell that a video has been recompressed, it softens prominent details slightly and has a tendency to tone down noise without completely removing it. In its intended bitrate range it keeps gradients as well as I can get it too, which is not always very well, at lower bitrates it starts to soften the entire picture as opposed to causing ringing, blocking, banding, or areas of obviously removed detail, gradients tend to be preserved about aswell as noise by this matrix.

High detail preserves gradients a bit better then MRM, it takes a stronger aproach to removing "redundant stuff" then MRM which can lead to pronounced ringing on some material, it tends to get rid of low level noise while maintaining strong noise better then any of my other matrices.

Smooth is heavily biased twords gradients, but does worse on gradients at high bitrates the HRM do to its strong removal of high frequencies, it usually preserves some of the noise from the source, but the noise it keeps is always blurier and less prominent then in the source, always softens the picture by a noticible margin, tends to have the least obvious artifacts at medium bitrates.

It all varies a lot, sources have a large impact on what artifacts a given codec will create, this of course carries over to matrices aswell. I find that with pristine sources X264 has an easy time avoiding many of the problems it encounters when recompressing mpeg2s, most notably blocking and banding artifacts are greatly reduced, and it is possible to get truely trasnparent encodes.

[elguaxo]

I never tried your HRM matrix and I want to do some tests with v2. In the previous version of this matrix I think deblocking was not recommended, but now you say this version is more flexible.

If I use some deblocking, what would be your recommended settings for a sharp picture? Thanks!

[*.mp4 guy]

-2:-4

[SealTooGreat]

@*.mp4 guy
Is there any "--deadzone-inter X --deadzone-intra Y" adjusting for M4G LRM V4 matrice.

[elguaxo]

SealTooGreat, I'm not an expert, but if you want more details you could try M4G MRM V2. It works well at low bitrates (not so low as LRM), and it keeps more details.

[SealTooGreat]

@elguaxo
I'm not an expert, too, but at lower bitrates, blocks are pain in the @ss. It seems,at about 800kbps, that M4G MRM V2 better handle this problem than M4G LRM V4. But under 600kbps M4G LRM V4 is unreplaceable.

[*.mp4 guy]

LRM was made before deadzone adjustment was available in X264, so it has only been extensively tested with the default settings, all the same it should work fine at any deadzone you set, so if you want to fiddle with the deadzone using LRM there shouldn't be any problems. At such low bitrates you are probably best off using trellis instead of manually tweaking the deadzone parameters, low bitrates are where all of X264's compresion enhancing features really become invaluable.

elguaxo is correct about MRM vs LRM on detail retention, SealTooGreat you are right about MRM blocking to much at those bitrates. Its a trade off, details, blocks, ringing, aliasing, you can't have everything, more detail leads to more of something else aswell, more ringing, blocking, aliasing or a higher bitrate.

[SealTooGreat]

LRM was made before deadzone adjustment was available in X264, so it has only been extensively tested with the default settings
Do You plan to update LRM?!
At such low bitrates you are probably best off using trellis instead of manually tweaking the deadzone parameters
*.mp4 guy, you are right...I found that LRM+Trellis2 reduce blocks more than LRM+Trellis1, but I couldn't find any proper deadzone parameters tweaking(Do you have any suggestion?!..or not to bother with deadzone ). It seems that block-reducing do not response on deadzone parameters tweaking as well as on trellis tweaking(about 600kbps)
you can't have everything
I must!:D

[*.mp4 guy]

Trellis and deadzone are mutually exclusive, you can't use custom deadzone settings with trellis. The default deadzone settings work very well for low bitrates anyway, so there isn't much (anything) to be gained by tweaking LRM for different deadzone settings; to clarify some sources may look better with higher or lower deadzone settings, but on average the defaults are better then any tweaked settings. The X264 developers may make it possible to use trellis and specify intra and inter deadzones at the same time in the future, but I am not aware of any plans to do so, with that in mind deadzone tweaking is not as usefull at low bitrates as trellis, so I won't be looking into using modified deadzone settings with LRM. Anyone else who would like to is of course welcome to make a modified version of LRM with custom deadzone settings in mind if they would like to.

to summarize:
-LRM will not be updated for daedzone settings in the forseable future
-don't bother with deadzone settings at low bitrates, trellis is better and can't be used with deadzone parameters.

[Manao]

It's not that deadzone can't be used with trellis, it's just that trellis ignore deadzone for doing the quantization. Deadzone defines how the rounding is done, but trellis tries both rounding anyway, so it doesn't matter.

What the devs wanted to do, however, was to map the relative importance of the DCT coefficients during the trellis onto a deadzone matrix, in order to make the trellis less optimal ( psnr-wise ) but better from your visual point of view.

As of yet, that has not been done.

[*.mp4 guy]

So to clarify, you can set deadzone and use trellis, but when you do the deadzone settings are ignored, which means that you can't specify deadzone settings and use trellis at the same time since when you use trellis it ignores the deadzone parameters you set...

Also, I thought what the devs were talking about doing was having the deadzone settings effect the trellis rate distortion optimisation routines via lambda?

[Manao]

Also, I thought what the devs were talking about doing was having the deadzone settings effect the trellis rate distortion optimisation routines via lambda?Indeed, hence the "less optimal PSNR wise / better from a visual point of view".

[juhu]

I get an "invalid attachment specified" when trying to get your "7zip" matrices pack . Could you repost them please ?
(mewiki.project357.com is down too, so I can't find them anywhere)

Also : What do you think is the "best" matrix for let's say Casablanca final (airport) sequence : a harsh combination of artificial fog, serious grain and moving spotlights (!!!)
the purpose is to rip hd with bitrates around 3000.
.I worked with lanczos+ xvid vhq4 (1152*848), result is ok if not transparent, but the most annoying this is all these moving halos going with the light variations (I don't know if that's what you call "gradient", my english is still "in progress"...)
.same script/bitrate with x264 (hq slower profile) gave me...worse results which came as a rather bad surprise. Clearly less visible details, even part of the inscriptions clearly readable on background with xvid cames as partially erased... and the halos were still the same....

thanks for any ideas.

[*.mp4 guy]

Huh, I must have messed something up (obviously).

Here (http://www.mytempdir.com/1244271) is a temporary link, I have also reuploaded them to the forum, but the they will take a while to be aproved.

To address the rest of your post, try HRM with direct=none and deblock -2:-4, rdo6, hex me with me range=24, intra luma quantizer deadzone=6, inter quantizer deadzone=8.

[audioman]

Hi mp4 guy

How to integrate your matrices in STAXRIP ? is it a way to do it ?

Thanks

[*.mp4 guy]

I'm not sure, Stax (I'm not sure If I spelled his name right) the author of STAXRIP should be able to answer that for you, you could try pming him or starting a thread in the guis forum. I wish I could be more helpful, but I don't use STAXRIP myself.

[juhu]

Here (http://www.mytempdir.com/1244271) is a temporary link, I have also reuploaded them to the forum, but the they will take a while to be aproved.

To address the rest of your post, try HRM with direct=none and deblock -2:-4, rdo6, hex me with me range=24, intra luma quantizer deadzone=6, inter quantizer deadzone=8.

thanks for the matrices & the suggestions, greatly appreciated

[audioman]

I'm not sure, Stax (I'm not sure If I spelled his name right) the author of STAXRIP should be able to answer that for you, you could try pming him or starting a thread in the guis forum. I wish I could be more helpful, but I don't use STAXRIP myself.

thanks

what about megui ?
can we use matrices in megui ? :)

[elguaxo]

what about megui ?
can we use matrices in megui ? :)

Yes! Here:
http://img244.imageshack.us/img244/2847/meguipq9.th.png (http://img244.imageshack.us/img244/2847/meguipq9.png)

[audioman]

thanks mp4guy

Just a question
What is the difference between your matrices and those integrated in megui ( HQ SLOW, SLOWEST )
Which matrix would you advise me to choose for a 1000 Kbs movie ?

Do I have to make a compressibility test or can I avoid using it when making a H264 movie ?

Thanks

[*.mp4 guy]

1 - HQ Slow, and HQ slowest aren't matrices, so I'm not sure how to answer your question

2 - its not the bitrate value that matters, the quantization value is a much better indicator of quality (though still not perfect)

3 - Since you already have picked a bitrate a compressability test is not necessary, just use 2pass mode with your desired bitrate.

4 - elguaxo answered your last question, not me

5 - you might want to read a guide on mpeg4 avc, death the sheep has a pretty nice one



I would like to be more helpful, but I'm not entirely sure what your asking, and I want to avoid confusion.

[audioman]

Thanks mp4guy

I just wanna know what kind of settings do you use to have a great mp4 quality file , near DVD quality
I want to back up my own movies

You are talking about quantisation values , how do you see this value in megui ?

Thanks again

[*.mp4 guy]

http://img80.imageshack.us/img80/3532/meguimh0.png

Set mode to constant quality, or constant quantizer, then set the quality level to control the quantizer. In constant quality mode you specify the average quantizer, whereas in constant quantizer mode you specify an absolute constant quantizer, constant quality mode gives better quality at the same bitrate.

You can also see the average I, P, and B quantizers of an encode by looking at the stats window.

[Keepitsimple]

an extremely noob question but what are matrices(ie matrices in this scenario, i know what a matrice is)?

[JarrettH]

If you don't choose a custom one it uses the default (flat) matrix which is very very good!

[SealTooGreat]

@*.mp4 guy
In your first post, You forgot to put the comma at the end of the rows in INTRA8X8_LUMA and INTER8X8_LUMA for M4G MRM V2, M4G HRM V2, M4G Smooth V1 and M4G High Detail V3.1

[*.mp4 guy]

Thanks, I'll fix that. (Just so people know they work fine without them in X264, but they should be there anyway)

[SealTooGreat]

Yes it works fine with x264, but recently I've tried using ffdshow encoder via VirtualDub with your custom matrices and ffdshow encoder refused to load them, just because of comma missing.
BTW what matrice do you use with above mentioned constant quality 20.0? Is there any other tweak?

[*.mp4 guy]

20 is right around where HRM starts to outperform MRM in most cases, so usually with Q20 I would use HRM.

[SealTooGreat]

@*.mp4 guy
When you compare two different h264 encoders or one h264 encoder with different settings, does inloop(deblocking) postprocessing have to be ON or OFF?!

[*.mp4 guy]

Inloop filtering is part of the AVC standard, it can be on or off, aslong as the same settings are used for both encoders.

[SealTooGreat]

I don't get it, when deblocking postprocessing is used during playback, there's less blocks, but on the contrary there's more blocks. Which solution is better for comparison?
Or, for example, when I say one h264 encoder is better then other, do I have to say, also, that I have (not) used deblocking postprocessing during playback or not?
Especially at the low bitrate, there's a HUGE difference between switching ON and OFF in deblocking postprocessing during playback.
I don't get it how you guys compare different h264 setting/encoders without mention this thing.

[check]

h264 inloop deblocking is not post processing, it's part of the normal decoding process. If you encode the video with it enabled, you should decode it with it enabled, and vice versa.

[SealTooGreat]

If you encode the video with it enabled, you should decode it with it enabled, and vice versa.
Check, thanx for very clear clarification.
But I've read somewhere on doom9 that is not recommended encoding without inloop, and also all presets that I came on have inloop enabled so is there any case where it should be disabled during encoding?!
If I've downloaded h264 movie from net how do I know if it was encoded with or without inloop?! Or inloop is something that is "must have".
*edit*
I've opened new thread h264 encoding/decoding inloop filtering questions (http://forum.doom9.org/showthread.php?p=969265#post969265) to keep this one clean. Mods move #93-98 posts

[check]

if inloop was disabled when the video was encoded, it will NEVER be enabled during playback, no matter what the decoder preferences say :). Because of this, you should always leave the inloop deblocker in decoder prefs on, unless CPU limitations prevent you from doing so.
There are probably some cases where not using inloop makes sense, but there aren't many. What often does make sense is reducing the power of deblocking during encoding, the x264 defaults at least are often too strong for videos.

(btw mods, you might want to split this into a new thread and keep this one clean).

[elguaxo]

Is it ok to use 2 different matrices in a same encode?

I just encoded a movie with a very good overall quality using M4G High Detail V3.1. But there is just a particular scene where the main character is in a low contrast/dark backround that shows a lot of blocks in the encode.

I encoded that scene again using this (http://forum.doom9.org/showpost.php?p=920050&postcount=33) script and used M4G Smooth V1 with very good results. And then I pasted everything together.

Playback is fine with my current setup (ffdshow version Feb 14 2007, Haali Media Splitter 1.7.77.5, Zoom Player v5.00), but I wonder if using 2 different matrices is just a 'hack' that is not officially supported.

[akupenguin]

Multiple matrices are supported. Like any other mixed settings, you have to use different values of --sps-id if you want to mux the result into mp4 or mkv.
Most global settings are stored in the sps/pps, and mp4/mkv store only 1 copy of each sps/pps. But if you give them different ids, then the muxer knows to keep both. (If you mux them first and then concatenate, mkvmerge should notice any different sps with the same id, and refuse to concatenate in that case.)