View Full Version : Hybrid matrices
lithoc
4th July 2005, 02:54
Hi,
Is there anyway that I can do hybrid matrices?
Examples:
EQM V3UHR = Low motion scenes/ dark scene
EQM V3ULR = High motion
Basically, I'm asking is there anyway treat matrices as a way to improve efficiency of XVID?
Just my 2 cent thought
:cool:
Teegedeck
4th July 2005, 08:22
Nope, there is no way to do this, it would break MPEG-4 compliancy.
And matrices are things that scale by design, according to the strength of quantization. If you use stronger quantization on scenes with high complexity ('high motion scenes') you reach just what you are asking for. Use curve-compression for that.
Sagittaire
5th July 2005, 06:01
Different matrix for each GOP is not compliant ... ???
Teegedeck
5th July 2005, 08:41
Edit: Now that I think about it, yes you may be right, it could be compliant when the new matrix comes with a new GOP! I'd thought of the old uncompliant 'modulated quant'. (Thanks.)
Mug Funky
5th July 2005, 12:15
hmm. my 2 cents on auto-matrixing is that it's useful in these situations:
- CBR encoding (when q1 just doesn't use enough bits, you need a CQM with lower values)
- whenever min/max rates need to be adhered to - min bitrate enforcement is the same deal as CBR - when the current matrix is giving all it can. max bitrate areas could benefit if the matrix agressively drops high freqs to avoid blocking (though inter-blocks would still block this way, intra-blocks would benefit).
this may not make it seem too useful, but there's plenty of applications i've not thought of yet (per-scene psychovisuals! weeeee!) where custom matrices would be very cool indeed.
one thing that confuses me is what range of numbers are legal in a custom matrix. i hear lots about using "sane values", and understand what that means, but there seem to be lots of exceptions, and no rigidly set values that people should stick to.
Soulhunter
5th July 2005, 20:12
this may not make it seem too useful, but there's plenty of applications i've not thought of yet (per-scene psychovisuals! weeeee!) where custom matrices would be very cool indeed.
Yeah, would be cool! You could use a "aggressive" matrix for the fast-motion scenes, coz there you wouldnt notice the high freqs anyway. Then you could use the saved bitrate to use a "high quality" matrix for the low motion parts where a high freq drop would be much more visible...
Bye
buzzqw
5th July 2005, 21:18
yea, something as dctune (as autoqmatenc).
Would be great
BHH
Teegedeck
5th July 2005, 21:21
Don't forget that it isn't so easy - high-bitrate scenes don't necesarily equal high-motion scenes where you could get away with quantizing coefficients agressively. As for the 'could', there is a second problem even when your high-bitrate scene is at the same time a high-motion scene: I still remember that 'taking from high-motion-scenes' strategy from Nandub-days; looked especially interesting when the high-motion scene was a car-chase where the actor's face was about the only thing not actually moving fast but nevertheless got compressed quite strongly. Yeah, the power of curve-compression... ;) So I would not expect miracles from combining two matrices with very different characteristics here but rather using slight variants of the same matrix could yield some benefit - like SixOfNine and SixOfNine-HVS.
Soulhunter
5th July 2005, 22:38
Don't forget that it isn't so easy - high-bitrate scenes don't necesarily equal high-motion scenes where you could get away with quantizing coefficients agressively. As for the 'could', there is a second problem even when your high-bitrate scene is at the same time a high-motion scene: I still remember that 'taking from high-motion-scenes' strategy from Nandub-days; looked especially interesting when the high-motion scene was a car-chase where the actor's face was about the only thing not actually moving fast but nevertheless got compressed quite strongly. Yeah, the power of curve-compression... ;) So I would not expect miracles from combining two matrices with very different characteristics here but rather using slight variants of the same matrix could yield some benefit - like SixOfNine and SixOfNine-HVS.
Well, Nandubs "stealing bitrate from high motion scenes" strategy is quite different from my idea imo! Nandub uses higher quants for high motion scenes to use lower quants for low motion scenes iirc, no? This means you get less details and more blocks in high motion scenes... But in my example you just get less details (ok, and a little bit more ringing), but not more blocking, coz you just drop more high freqs which lowers the bitrate without raising the quantizer! I guess the real problem with my idea is not the "car-chase" thing, but that the used matrices have to match the compression level. Using 6of9 HVS for high motion scenes and the "standard" 6of9 for low motion would work for high bitrates (ie. Q2, Q3, Q4). But it would really suck for low bitrates (ie. Q7, Q8, Q9). In this case it would be better to use ie. EQMv3ULR + EQMv3LR instead. But unfortunately there are not only high (black) and low (white) bitrates (you'd need matrices for all the grey shades as well). So, if something like this gets ever implemented in XviD, there has to be a option to set the matrices that match the "compression level" you aim for!
Bye
amof, 'real' hi-mo scenes are very rare, and in most cases they are scans, rotations, zooms, so sg better fit to gmc than to 'matrixing'. in most instances only a part of the frame is moving/changing fast (just as teegedeck described).
if so, what about extending 'aq' towards this? i mean, let the user select adaption based on 'lumi' (present way) or based on 'motion' (say, on block mv), or both. or any, of course ;)
imho, a tunable adaptation of this kind would be more beneficial than any matrix combination.
the bests
y
Teegedeck
6th July 2005, 12:55
:D 'Motion-masking'? That's exactly the thing I proposed years ago (http://forum.doom9.org/showthread.php?p=68158&highlight=motion-masking#post68158). But Isibaar made it clear to me in 2002 that stronger quantization of moving parts of the picture would be too visible but that coefficient-removal could be a good thing. This would be altogether different from the 'hybrid CQM' idea though (as it would happen within the same frame and you cannot compress a couple of macroblocks with a different matrix than the rest of the picture and stay standard-comliant) and I believe it would be quite complcated to do; thus - still no such thing implemented.
Soulhunter
6th July 2005, 14:08
'Motion-masking'? That's exactly the thing I proposed years ago (http://forum.doom9.org/showthread.php?p=68158&highlight=motion-masking#post68158)...
Lately there was also a discussion about this "ROI based AQ (http://mf.onthanet.com/forum/index.php/topic,181.0.html)" idea...
But I guess without Syskin (and his HVS plugin) it will never be implemented!?
Bye
i am pretty sure that its not allowed to have varying matrices in mpeg-4 asp (in avc i would say its allowed)
i say that because the mpeg-4 standard expects the VOL (which carries the matrix) to be placed only once with the video stream!
it was only a funny workaround that in .avi the codecs place the VOL on every keyframe, every new GOP
if the VOL is stored only once with the stream, there is also no way to store varying matrices
maybe someone finds some more explicit words to that in the mpeg-4 standard
on the contrary in avc the SPS/PPS (which carry the matrices) explicitely can vary throughout the stream and therefore i assume the matrices can too
Sharktooth
6th July 2005, 19:12
yup but i think that's useless coz the default quantization is already adaptive.
Custom matrices are needed when standard quantization fails to give the desired results.
Didée
6th July 2005, 22:29
Besides, where are the people implementing the genious ideas. May I remind that by now it's more than half a year that XviD is *not able to decode its own content correctly* - the bug in decoding interlaced coded content is still there. If nobody manages to fix "trivial" bugs, who is supposed to do the sophisticated stuff (like better psychovisual coding), then?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.