Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 ASP

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th May 2003, 20:23   #21  |  Link
crusty
Ahhh....Nuts!!
 
crusty's Avatar
 
Join Date: May 2002
Location: Holland
Posts: 309
Quote:
I don't know why you brought QPel into this,
I figured that since they both work with the precision of motion, there has to be some sort of interaction.
Quote:
And that's exactly what all matrices already do...And since using too high values cause ringing as mentioned before, I believe the standard matrices are already quite well made.
Offcourse they are, but there certainly are certain types of film that might improve with a tweaked QM, like cartoons.

What do you think of the edge detection in the codec I suggested?
__________________
Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org
crusty is offline   Reply With Quote
Old 27th May 2003, 00:22   #22  |  Link
manono
Moderator
 
Join Date: Oct 2001
Location: Hawaii
Posts: 7,246
Hi Acaila-

while the high-motion codec could only use 4-31

It's even worse than that-the lowest quant that Hi-Mo uses is 5. Minor point though, in your informative series of posts in this thread.
manono is offline   Reply With Quote
Old 27th May 2003, 08:42   #23  |  Link
Acaila
Retired
 
Acaila's Avatar
 
Join Date: Jan 2002
Location: Netherlands
Posts: 1,529
Quote:
What do you think of the edge detection in the codec I suggested?
For one thing it would have to be done before DCT because edges no longer exist in the transformed frame (I think). All spatial information is gone after DCT, only frequency remains; high frequency can just as well mean noise or edges, there's no way to know after the DCT.
Giving a bonus to egdes sounds to me very much like sharpening, and that's not always a good idea, it either creates ringing or increases edge enhancement (->halos). But other than that I have no idea if it would be a good idea in general.

Maybe some real developer can say if it's possible/worthwhile.

Ps. Thanks Manono

EDIT: Yes, edge detection using the DCT coefficients (or another transform for that matter) seems possible but from what I have read it's very complicated too.

Last edited by Acaila; 27th May 2003 at 09:17.
Acaila is offline   Reply With Quote
Old 27th May 2003, 09:28   #24  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
Quote:
Originally posted by Acaila
And since using too high values cause ringing as mentioned before, I believe the standard matrices are already quite well made. The only reason I could see anyone using a custom QM is for increasing the amount of detail/size of a video (since for higher compression you could just as well use a higher quant, no need for a custom matrix).[/B]
Well, let me bore you with my points in using custom matrices.

The standard matrix is well designed as an all-purpose-matrix. It delivers reasonable results with all quality ranges. But obviously, it is not at all optimized for either hi-quality or hi-compression scenarios. For both, a good custom one will fit better.
On the hi-quality side, we already had the discussion "better quality at max quality" (here). Quant-2 doesn't deliver super-high quality, and quant-1 ... you know.
Moreover, I think that the bigger coeffs for the high frequencies are mostly there to deal with noise, not with image detail. (Well, intended or not, it IS like that.) But if you have a well-denoised picture, then your interest in keeping high frequencies will raise quickly, proportional to the ratio of win/loss forced by keeping them. Hah, what a sentence

Furthermore, there is an additional benefit for 2-pass scenarios:
The codec can scale the bitrate much smoother.
Usually, for really good quality, we're still aiming for an average quantizer of '3' or better - at least for P-frames. Right?
Now, with the standard matrix we have that "big jump" in filesize, or bitrate, between quant-2 and quant-3. Therefore, when the codec is working with only q2 and q3, the bitrate is not distributed smoothly: one expensive q2 equals to many cheap q3's, and the quality improvement from those seldom q2's is hard to notice. There should be something between q2 and q3 ...

ATM, I use the following matrix almost all the time. Scales well with all high-bitrate to better-medium-bitrate scenarios - but only for well-denoised material. I always use PixieDust(2|3), seldom with a little caliming-down the noise beforehand by light Convolution3D or Fluxsmooth. Undot() of course.
Since attaching seems down again, I'll do a little more typing. Perhaps you will, too.
Code:
#  "SixOfNine"

08 10 11 12 12 13 14 15     10 10 11 12 12 13 14 15
10 11 12 13 13 15 15 16     10 11 12 13 14 14 15 16
11 12 12 14 15 15 16 17     11 12 12 14 14 15 16 17
12 13 14 15 15 16 17 18     12 13 14 14 15 16 17 18
12 13 15 15 16 17 18 19     12 14 14 15 16 17 18 19
13 15 15 16 17 18 19 19     13 14 15 16 17 18 19 20
14 15 16 17 18 19 19 20     14 15 16 17 18 19 20 20
15 16 17 18 19 19 20 20     15 16 17 18 19 20 20 20
- This' matrix quantizer range q2-q8 eaquals about the standard matrix range 'q1.4'-'q4.5'
- q3 is a tad better as q2(standard)
- q4 is between q2 and q3 (std)
- q5 is a little weaker as q3 (std)
- ...

For the same bitrate range, the codec simply has more quantizers available for scaling.


Regards

Didée
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 27th May 2003, 11:26   #25  |  Link
JimiK
just me
 
Join Date: Sep 2002
Posts: 158
@crusty
I agree with Acaila, that imho there is no use for detecting edges. Even if would be possible, what benefit would you have? You would know there is an edge, and now? This is not meant to sound rude.
Now I always thought a bit different about quantizer matrices. Why do they have higher coefficients for higher frequencies (lower right of the matrix)? Well, I thought it is, because you cannot notice a loss in detail that easily. That's why you can quantize it more. It's dependend on the human visual system. Ever noticed macroblocks in evenly colored areas? Of course that's because the whole block gets the same value which is another problem. But why do we see these blocks, even though the difference is not big (blue block in the sky next to another blue block with almost the same color). That's because the human eye notices differences in a colorgradient much easier than differences between two completely different colors.
So it's not possible to quantize low frequencies even more, you would easily notice. You can of course quantize high frequencies less and get more details and maybe less mosquito noise, but you would have to pay with a much higher need of bitrate, while it's quite hard to see the difference to the other picture.
Again (as I always say): I don't now much about QM's, so maybe that's wrong, but I think I read that somewhere.
@Didee
Thats interesting, with the more even distribution. But there is only a slight difference between the quantization of low to high frequencies (ratio 2:1) which would leed to the problem (bitrate) I just mentioned. Strange, didn't you say you put LOTR on one CD with decent quality? And another point: doesn't this matrix cause problems with ffdshow? As far as I know, it does not like values below 16.
Best regards,
JimiK

Last edited by JimiK; 27th May 2003 at 11:28.
JimiK is offline   Reply With Quote
Old 27th May 2003, 12:43   #26  |  Link
vinouz
Grüt Power Maintainer
 
vinouz's Avatar
 
Join Date: Mar 2002
Location: france
Posts: 111
Theoretically you could notice edges on the DCT, as it produces a fair amount of odd coefficients. Computing pow(odd*odd) - pow(even*even) could maybe give a serious hint about edges. And then the corresponding matrix could be one special for edges (I once before talked of it).

Odd armonics code for a square signal (multiplied by their order's inverse). The only thing is I don't know how this pure square 'signature' resists to noises and geometric distortions. But sure it's good to take a little look at it.
__________________
A psychotic thinks that 2 + 2 = 5.
A neurotic knows that 2 + 2 = 4... but it worries him!
vinouz is offline   Reply With Quote
Old 27th May 2003, 13:34   #27  |  Link
Acaila
Retired
 
Acaila's Avatar
 
Join Date: Jan 2002
Location: Netherlands
Posts: 1,529
@Didee:

JimiK made some valid points there. I agree with him that the coefficients should not be scaled so linearly as you've done in your matrices, because high frequencies are harder to notice than low. With those matrices you rely almost solely on quantizers to scale the bitrate, while I believe you should rely on both QM and quantizers. What I mean with that is that a matrix with higher values in the bottom-right and lower in the top-left should give better scaling (with higher quality possible at quant 2 and less filesize distance between quants, see below). Once a frame gets encoded with higher quantizers you don't want to loose (relatively) just as many low frequencies as high ones because the low have a lot more impact on visual quality.

Also ffdshow indeed has problems with values less than 16, however as far as I can tell it only has problems with the top-left value being lower than 16. Whenever I put a 16 in the top-left corner everything played just fine no matter how low the other values were.

Something else I've noticed is that VHQ doesn't seem to work very well (lower PSNR) on custom matrices compared to H.263 and MPEG. Can anyone confirm this?

The matrices I would recommend:
Code:
Intra:                    Inter:
08 09 10 11 12 13 14 15   16 08 10 12 14 16 18 20
09 10 11 12 13 14 15 16   08 10 12 14 16 18 20 22
10 11 12 13 14 15 16 17   10 12 14 16 18 20 22 24
11 12 13 14 15 16 17 18   12 14 16 18 20 22 24 27
12 13 14 15 16 17 18 19   14 16 18 20 22 24 27 30
13 14 15 16 17 18 19 20   16 18 20 22 24 27 30 33
14 15 16 17 18 19 20 20   18 20 22 24 27 30 33 36
15 16 17 18 19 20 20 20   20 22 24 27 30 33 36 40
Filesize and PSNR are distributed as below (high to low):

Code:
Matrix       Quantizer
Mine	         2
H.263	         2
Mine    	 3
Mine    	 4
H.263	         3
Mine      	 5
Mine    	 6
H.263	         4
Mine    	 7
Mine    	 8
H.263	         5
As you can see this gives better bitrate scaling just like Didee suggested and the option for better quality at quant 2. It also doesn't scale low and high fequencies linearly because I don't think that's right.

Last edited by Acaila; 27th May 2003 at 13:41.
Acaila is offline   Reply With Quote
Old 27th May 2003, 14:54   #28  |  Link
ssaga
Registered User
 
Join Date: Nov 2002
Posts: 29
Acaila's QM has a very interesting feature, the number on the same
line are the same, does it have any special meaning?

Another question, since the right site and the bottom site both mean higher frenquency, what's the difference between the numbers on the same diagonal? (such as (3,5) vs (5,3))
ssaga is offline   Reply With Quote
Old 27th May 2003, 14:57   #29  |  Link
Acaila
Retired
 
Acaila's Avatar
 
Join Date: Jan 2002
Location: Netherlands
Posts: 1,529
Quote:
Acaila's QM has a very interesting feature, the number on the same
line are the same, does it have any special meaning?
I like symmetry .

Quote:
Another question, since the right site and the bottom site both mean higher frenquency, what's the difference between the numbers on the same diagonal? (such as (3,5) vs (5,3))
From left to right is increasing horizontal frequency. From top to bottom is increasing vertical frequency.
Acaila is offline   Reply With Quote
Old 27th May 2003, 19:22   #30  |  Link
crusty
Ahhh....Nuts!!
 
crusty's Avatar
 
Join Date: May 2002
Location: Holland
Posts: 309
JimiK:
Quote:
Ever noticed macroblocks in evenly colored areas? Of course that's because the whole block gets the same value which is another problem.
Well, I read in one thread that Chroma Motion Estimation is designed especially for less color-blocking in almost evenly colored spaces.
I don't know exactly which thread it was, try using the search.

Acaila:
Quote:
For one thing it would have to be done before DCT because edges no longer exist in the transformed frame (I think). All spatial information is gone after DCT, only frequency remains; high frequency can just as well mean noise or edges, there's no way to know after the DCT.
Well I already knew that it would have to happen before DCT, perhaps I was not clear enough on that, no problem.

Quote:
Giving a bonus to egdes sounds to me very much like sharpening, and that's not always a good idea, it either creates ringing or increases edge enhancement
Well the idea was really to decrease compression artifacts.
Giving a bonus to edges does seem like sharpening on first sight, but since we would be using it for edge enhancing anyway, that's basically what we would be doing. For normal or oversharpened movies this would not come in handy, but it would be good for movies that are too soft. I personally like sharpness and crispness a lot.
And if you think about it, it's only the REAL edges, determined by the to-be-programmed edge enhancement, that get the bonus. So you wouldn't be adding noise or artifacts, just enhancing the real footage.

But I was thinking a bit more about what would really be usefull, and I figured something else.
Maybe edges don't need a bonus on the current frequency like this:
Edge detection --> determines bonus for DCT coefficient --> DCT --> DCT coefficent gets bonus added --> final value goes trough QM......
Which was what I first had in mind...
But this would indeed increase the visibility of the edges but would not reduce the noice.
Instead I am now thinking about assigning edges a LOWER frequency based on an edge detection bonus than they would have gotten without the edge detection.
If mosquito noise is created by the codec thinking there is TOO MUCH detail (ergo, noise) than there really is, then assigning a lower frequency would reduce the noise now, wouldn't it?
So instead of the edge detection bonus upping the DCT value for the determined frequencies' treshold, it would now instead assign the macroblock a different frequency, based on a more precise estimate of the real content, created by the edge detection algorithm.
So it would instead look more like this:
Code:
Edge detection --> assigning extra (internal to codec) value to edges -->
DCT algorithm -->assigning different frequency to macroblock determined by internal value --> QM
It would probably be hella slow, but you might get right of a lot of noise
Just some food for thoughts...

Vinouz:
Quote:
And then the corresponding matrix could be one special for edges
Wouldn't that entail more than one QM per frame, and is that a) possible and b) Mpeg4 compliant?

Didée:
Quote:
The codec can scale the bitrate much smoother.
Could you elaborate a bit more on that? I'm not entirely sure on how that would be affected by a different QM.
Quote:
For the same bitrate range, the codec simply has more quantizers available for scaling.
So you're saying that by lowering the QM values, you give the codec more freedom to allocate bits when needed and when not? How good do you find this effect in practice?
Quote:
I always use PixieDust(2|3)
Slightly off-topic:
Pixiedust created artifacts with me when using it at resolutions lower than 576xXXX. Have you experienced the same or haven't you used Dust with that low resolutions?
/slightly off-topic.

Acaila:
Quote:
Also ffdshow indeed has problems with values less than 16, however as far as I can tell it only has problems with the top-left value being lower than 16. Whenever I put a 16 in the top-left corner everything played just fine no matter how low the other values were.
So what DOES happen when you use a value less than 16? Does it refuse to play or do you get artifacts?

Also @ Acaila:
I see that your QM for P/B-frames has twice the values for the higher frequencies than your I-frame QM. This would result in your B/P-frames having a bigger bias to low frequencies.
Compared to the standard H263 or mpeg QM, did you adjust the B-frame settings (Q-ratio, offset, treshold etc) to compensate for different end result created by your custom QM?

Acaila:
Quote:
From left to right is increasing horizontal frequency. From top to bottom is increasing vertical frequency
So from left to right it goes something like: 1 prison bar, 2 prison bars, 4 prison bars, etc etc.
And from top to bottom it goes something like: 1 stairstep, 2 steps, 4 steps, etc etc.
Right?

Also it would not always be prudent to use a symmetrical QM, based on the type of footage.
Say you've got a jungle scene. Most of this would be trees and leefs.
I'd say that would have a bias towards vertical objects, ergo a lot of horizontal frequencies (think about the texture on the trees).
And if you've got a scene with a lot of stairs in it, it would be a lot of horizontal objects, so a lot of vertical frequencies.
Offcourse these are normally just small clips in an entire movie, but I hope it proves the point.
__________________
Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org
crusty is offline   Reply With Quote
Old 27th May 2003, 20:23   #31  |  Link
Acaila
Retired
 
Acaila's Avatar
 
Join Date: Jan 2002
Location: Netherlands
Posts: 1,529
Quote:
So what DOES happen when you use a value less than 16? Does it refuse to play or do you get artifacts?
It's like pieces of the frame stay put while others start moving around. All I know is it's ugly .

Quote:
Compared to the standard H263 or mpeg QM, did you adjust the B-frame settings (Q-ratio, offset, treshold etc) to compensate for different end result created by your custom QM?
I haven't tested B-frames yet with that matrix. It's mostly theoretical, I haven't done any extensive testing with it, but it seemed to perform great on what few tests I have done.

Quote:
Also it would not always be prudent to use a symmetrical QM, based on the type of footage.
Say you've got a jungle scene. Most of this would be trees and leefs.
I'd say that would have a bias towards vertical objects, ergo a lot of horizontal frequencies (think about the texture on the trees).
And if you've got a scene with a lot of stairs in it, it would be a lot of horizontal objects, so a lot of vertical frequencies.
Offcourse these are normally just small clips in an entire movie, but I hope it proves the point.
The trees create vertical frequencies, the leaves create horizontal frequencies. So you see things are not as simple as that . Some scenes in a video might have more horizontal other scenes might have more vertical frequencies. So the best matrix is one that can accomodate for both types equally. That is why I always make my matrices symmetrical. If we could have something that creates QM's on the fly optimized for each frame we wouldn't go through such trouble to make a good QM, now would we? We can only have one QM, so it must be optimal for as many different scenes as possible, hence symmetrical.

As for your custom edge enhancement theory I'm still not convinced it is actually useful or will even have a different effect from sharpening for that matter. Edge detecting during filtering: very useful. Edge detection during encoding: doubtful. I believe it's not the codec's job to reduce noise (unless it is done with preprocessing filters).
That doesn't mean it might not be useful, just that this is my opinion.
Acaila is offline   Reply With Quote
Old 27th May 2003, 22:13   #32  |  Link
Didée
Registered User
 
Join Date: Apr 2002
Location: Germany
Posts: 5,394
Back from some testing. However, there is much more to test and compare than available time

I took 1500 frames of a 5%-snip through chapter 2 and 3 of LOTR Fellowship SEE, with a snipsize of 100 frames (4s, PAL).

Treatment was

crop(8,80,-8,-80).undot().LanczosResize(640,272).undot()
\ .ConvertToYUY2().pixiedust(limit=2).ConvertToYV12()

XviD (14052003-1) settings were basicly default, +chroME +qpel +chromaOptimizer. And custom quants, of course ...
Destination was 9200 kB, what was 75% of the 1st-pass with standard-mpeg.

Quote:
Originally posted by trbarry, some time ago
Ah, a table!
Code:
	  |          | PSNR      PSNR      PSNR    | MeanAbsDev |
	  | 1st-pass | min       avg       max     | (avg)      | q-distrib.
============================================================================
Standard  | 12542 kB | 41.6922   45.5240   50.1203 | 0.9432     | q2:541
	  |	     |			           |            | q3:956
	  |          |			           |            | q4:4
----------------------------------------------------------------------------
SixOfNine | 20544 kB | 41.5405   45.5355   49.9382 | 0.9384     | q3:388
	  |	     |			           |            | q4:970
	  |	     |			           |            | q5:138
	  |          |			           |            | q6:5
----------------------------------------------------------------------------
Acaila	  | 19438 kB | 40.9498   45.0723   50.1547 | 0.9900     | q3:466
	  |	     |			           |            | q4:906
	  |	     |			           |            | q5:128
	  |	     |			           |            | q6:1
Acaila,
my matrix is not so flat as you may think. In fact, SixOfNine was originally designed to behave very much like the standard matrix, just to get a differently scaled quantizer range in the end.
I also tested around with bigger values in the critical upper-left cell some time back. But I got the impression of flat areas becoming more blocky by that strategy, and so I dropped the idea again. Also it has its pro's in reducing the raised bitrate. Erh, what?
And I don't forced to let ffdshow decode my videos ... it is sufficient as postprocessor only.

Too tired for analyzing now ... perhaps tomorrow with more test results.

Good night, gentlemen,
please try to not post more than 2-3 additional pages on this thread in the next 24 hours, okay? (Crusty!! Carry on!)

Didée
__________________
- We´re at the beginning of the end of mankind´s childhood -

My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!)
Didée is offline   Reply With Quote
Old 28th May 2003, 01:09   #33  |  Link
LoKi128
Registered User
 
Join Date: Jun 2002
Posts: 37
Well, since we are talking about matrices here, I have a question.

When encoding an anamorphic source... would a matrix with higher detail in the horizontal axis provide better quality? Most matrices that I've seen are pretty even in both the horizontal and vertical... but in an anamorphic encode it is important to keep the higher horizontal frequencies, since sqishing the image in essense shifts any lower frequencies up.
LoKi128 is offline   Reply With Quote
Old 28th May 2003, 05:16   #34  |  Link
Defiler
Asker of Questions
 
Join Date: Oct 2001
Location: Florida
Posts: 433
Acaila:
Ouch, the first pass is huge with your matrix.
__________________
"The real trick to optimizing color space conversions is of course to not do them." --trbarry, April 2002
Defiler is offline   Reply With Quote
Old 28th May 2003, 06:38   #35  |  Link
MrBunny
Registered User
 
Join Date: Oct 2002
Posts: 82
Quote:
Originally posted by Defiler
Acaila:
Ouch, the first pass is huge with your matrix.
There isn't an issue with large first pass sizes. In a two pass situation, a large first pass will simply cause a higher average quantizer. However, since the Acaila and Six of Nine QMs have relatively small coefficients compared to others QMs, even if the average quantizer is larger (as shown to be true in Didée's table), the actually value used for quantization is still comprable to "normal" QMs.

and back a few posts...
Quote:
Originally posted by crusty
Wouldn't that entail more than one QM per frame, and is that a) possible and b) Mpeg4 compliant?
As I'd mentioned in a post in the previous page, Syskin talks about switching QMs on the fly in this post: http://forum.doom9.org/showthread.p...5827#post305827

Keep up the interesting discussion (Sorry if we overwhelm you Didée )

Last edited by MrBunny; 28th May 2003 at 06:44.
MrBunny is offline   Reply With Quote
Old 28th May 2003, 13:21   #36  |  Link
Acaila
Retired
 
Acaila's Avatar
 
Join Date: Jan 2002
Location: Netherlands
Posts: 1,529
@Didee:

I just finished a dozen tests on a 5000 frame Collosseum scene from Gladiator and my findings support yours for 100%, so I won't post them here. In 2-pass my matrix had a (0.5 dB) lower PSNR than the standard or SevenOfNine matrices on all occasions.

But it looked nice in theory .

I've also tried some variations on your SevenOfNine matrix, but no matter what I tried, PSNR always dropped. So I believe you've got quite a good matrix there .
Substituting the top-left value 8 with a 16 (in the interframe) to make it ffdshow compatible didn't seem to harm quality at all and PSNR only dropped a little for chroma, not luma. So I see no harm in doing that if anyone wants to use that matrix and uses ffdshow to decode.

Quote:
Originally posted by LoKi128
When encoding an anamorphic source... would a matrix with higher detail in the horizontal axis provide better quality? Most matrices that I've seen are pretty even in both the horizontal and vertical... but in an anamorphic encode it is important to keep the higher horizontal frequencies, since sqishing the image in essense shifts any lower frequencies up.
Honestly I have no idea. But I don't think it makes much difference.

If only we had a way to see the DCT coefficients before they get quantized...I bet that would help a lot in creating a good matrix.
Acaila is offline   Reply With Quote
Old 28th May 2003, 13:53   #37  |  Link
Defiler
Asker of Questions
 
Join Date: Oct 2001
Location: Florida
Posts: 433
Quote:
Originally posted by Acaila
If only we had a way to see the DCT coefficients before they get quantized...I bet that would help a lot in creating a good matrix.
Yes, and it would also be nice to be able to enter values in the matrix, and instantly see the changes previewed on an I-frame. That would be extremely cool.
By the way.. I know the large first pass is irrelevant, because what matters is the actual coefficient, not the quantizer value itself. I just had to up the disk quota in that folder to make room for the first pass. Heh.
__________________
"The real trick to optimizing color space conversions is of course to not do them." --trbarry, April 2002
Defiler is offline   Reply With Quote
Old 28th May 2003, 13:56   #38  |  Link
Defiler
Asker of Questions
 
Join Date: Oct 2001
Location: Florida
Posts: 433
Also.. are there a pair of tools that can:
1. Create XviD-compatible QM presets from their text equivalent.
2. Load a saved QM into the Custom page via the command-line?

It would be nice to be able to schedule a large set of test encodes, rather than having to load and save manually between each one.
__________________
"The real trick to optimizing color space conversions is of course to not do them." --trbarry, April 2002
Defiler is offline   Reply With Quote
Old 28th May 2003, 16:10   #39  |  Link
crusty
Ahhh....Nuts!!
 
crusty's Avatar
 
Join Date: May 2002
Location: Holland
Posts: 309
Acaila:
Quote:
I haven't tested B-frames yet with that matrix.
It looks like B-frames would be compressed even more than normal with this QM, so it might produce a lower quality end result if B-frames are enabled.

Quote:
If we could have something that creates QM's on the fly optimized for each frame we wouldn't go through such trouble to make a good QM, now would we? We can only have one QM
Why? I want more !!
No seriously, even if it would not be mpeg4 compliant, if we could have more QM's in one movie, it would probably improve quality at the same compression level or improve compression at the same quality level. That's what modulated QM did do, even if the modulation decision was as dumb as hell.

Quote:
I believe it's not the codec's job to reduce noise
Well it's the codec's job to reduce size, and noise adds size. So reducing noise, especially when it's created by the compression itself, would be the codec's responsibility.
Reducing artifacts created by the compression proces is different from reducing noise already present in the original footage. It's the difference between preserving the original picture and altering the original picture.
The process I suggest is to preserve the original picture, while improving compressibility.

Didée:
Quote:
please try to not post more than 2-3 additional pages on this thread in the next 24 hours, okay? (Crusty!! Carry on!)
Working on it...processing....processing...please stand by

MrBunny, I couldn't find the thread you posted.
Quote:
In a two pass situation, a large first pass will simply cause a higher average quantizer.
You mean, because a large first pass tells the codec that the end result would be bigger than allowed if it used a lower quantizer, right? Just to get this straight...

I was just thinking....
When I started encoding a few years ago I had a really hard time encoding the movie '2010: The year we made contact' end I ended up using both the DivX 3 Fast-motion and Low-motion codecs.
It's a space movie and on the whole it looked better with the Low-motion codec but there where two or three scenes of fast motion that looked blocky.
I encoded the whole movie with both codecs and then used a tool (cannot remember it's name) that would merge the best parts of both.
The end result was very good.

Now I also have used different QM's recently inside one movie, by using a Heavy Compression matrix on the end credits and using H263 or modulated on the main movie.
It may not be mpeg4 compliant, but it works like a charm.
So using different QM's in one clip is quite possible.

This leads me to the following idea (you're probably guessing it already):

Encode the entire movie with several different QM's and then use a tool to switch between the best looking/best compressed parts and merge those. Then you would have a modulated end result.
And with this process you can easily alter the algorithm for choosing between the QM's without altering the codec itself, as it's just a standalone tool.
This way you could use up to a zillion different QM's in one clip, depending on how you make the decision. So you could automatically use different QM's for end credits, low motion and fast motion scenes and dark and light content etc etc.

Any thoughts on this?
__________________
Core 2 Duo intel, overclocked at something (can't remember what i set it at), about 2 TB in hard storage, nvidia 9800 GT and a pretty old 19tftscreen.
Crusty007 at en.Wikipedia.org
crusty is offline   Reply With Quote
Old 28th May 2003, 16:15   #40  |  Link
Defiler
Asker of Questions
 
Join Date: Oct 2001
Location: Florida
Posts: 433
Can you merge two different AVI files that use different custom XviD quantizer matrices? I've never tried.

By the way.. B-frames work fine with Acaila's matrix. At least, they did for me.
__________________
"The real trick to optimizing color space conversions is of course to not do them." --trbarry, April 2002
Defiler is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.