CQ vs. CQ_VBR ... Very Interesting... - Page 18

jamesp · #**341** 01-03-2003, 07:43 PM

Quote:

Originally Posted by kwag

I think I'll stick with CQ + BETA-1 matrix + "dither": Blockbuster(method="dither", variance=.5, seed=1)
I get the best results second to none with the above line.
Maybe if I have to encode at 352x240, I would use CQ_VBR, but over 352x480, CQ just produces less artifacts and with the help of "dither" ( maybe "noise" too? ) the overall quality is superior. At least on all my latest tests, the results have been very consistent.

So far, that's my experience. Anyone else care to comment

Same results? Different results?

-kwag

Kwag,

100% Agree with CQ being better. I never go below 544x576 (and i don't use blockbuster) so i can't comment on the other resolutions. Have you tried CQ with any TV captures? I find using CQ at High quality motion search gives far better results than CQ_VBR at MUCH smaller file sizes. The Encodes are absolutley perfect! I was ready to give up on tv captures whilst using CQ_VBR.

Jim

segfault · #**342** 01-03-2003, 07:57 PM

Quote:

segfault wrote:

Quote:

At high motion search precision, there was virtually no difference in file size at 36, 37, 38, 39, and 40, with files in the 12-12.1 range. Interestingly, 36 and 37 produced slightly larger files (12.1) than 38 and 39 (12.0).

Yep, I've noticed this too. It's very weird.

I just find it totally bizarre that 35/normal produces a *vastly* superior picture at 11.6 MB than 38/high does at over 12. It appears to defy logic.

kwag · #**343** 01-03-2003, 09:16 PM

Quote:

Originally Posted by segfault

It appears to defy logic.

Call it TMPGEncTantrums

-kwag

kwag · #**344** 01-03-2003, 09:17 PM

Quote:

Originally Posted by jamesp

Have you tried CQ with any TV captures?

No I haven't Jim

-kwag

jorel · #**345** 01-03-2003, 09:44 PM

@ Sansgrip

Edit: Forgot to say, it's at the same URL as before

.

Btw, I also got rid of the version parameter.[/quote]

i can't download the _test.zip........"says" file not found.

black prince · #**346** 01-03-2003, 10:02 PM

@Kwag,

Kwag wrote:

Quote:

Anyone else care to comment. Same results? Different results?

What CQ and motion search percision are you using? I'm
using motion estimate search fast. I want to try a clip using
your settings (e.g. dither, CQ, motion search, etc.) Some are
having good results and some poor. Maybe Tmpgenc, as SansGrip
suggests, could be responding differently when CQ reaches certain
levels. All of these fixes are to fix shortcomings of Tmpgenc's
encoder or any encoder. There has to be some common settings
to get predicted results. I don't believe were not there yet

-black prince

kwag · #**347** 01-03-2003, 10:45 PM

Hi black prince,

You're right!. I think we're not done yet

I'm using Blockbuster(method="dither", variance=.4, seed=1) for 528x480 with CQ, fast motion estimation, and the new BETA-1 matrix.
I'm also using MIN=300 and MAX=2,500.

Here's my script:

Code:

LoadPlugin("C:\encoding\MPEG2DEC.dll")
LoadPlugin("C:\encoding\fluxsmooth.dll")
LoadPlugin("C:\encoding\blockbuster.dll")
LoadPlugin("C:\encoding\legalclip.dll")
LoadPlugin("C:\encoding\sampler.dll")

Mpeg2Source("K:\K19\VIDEO_TS\k19.d2v")
LegalClip()
LanczosResize(496,256,8,56,704,364)
FluxSmooth()
Blockbuster(method="dither", variance=.4, seed=1)
#AddBorders(16,112,16,112)
LegalClip()

Sampler(length=24)
## MPEG size = ((Total frames/MovieTimeInMinutes)/24) * MPEG sample file size ##

I'm commented the addborders, as per SansGrip's suggestion, and I let TMPEG worry about that

But I do use TMPEG to get my borders size and film pixel area. It just looks "cleaner" around the edges that Vdub when closing in. I get the same values with both procedures.

Edit: I'm still doing some comparisons between "dither" and "noise"

-kwag

black prince · #**348** 01-03-2003, 10:54 PM

@Kwag,

You forgot your CQ setting. It's important because a higher CQ, say 70+
could be when Tmpgenc reacts to Blockbuster dither. Below 70 it might
be ignoring dither.

-black prince

kwag · #**349** 01-03-2003, 11:27 PM

Quote:

Originally Posted by black prince

@Kwag,

You forgot your CQ setting. It's important because a higher CQ, say 70+
could be when Tmpgenc reacts to Blockbuster dither. Below 70 it might
be ignoring dither.

-black prince

62.6

Dither IS working at that value. At least at 528x480.

-kwag

SansGrip · #**350** 01-04-2003, 12:02 AM

Quote:

Originally Posted by Racer99

At what motion search precision were these samples encoded?

High quality. Anything lower produces more artifacts, while "highest quality" gives me larger file sizes with very little gain, if any.

SansGrip · #**351** 01-04-2003, 12:04 AM

Quote:

Originally Posted by jamesp

I find using CQ at High quality motion search gives far better results than CQ_VBR at MUCH smaller file sizes. The Encodes are absolutley perfect! I was ready to give up on tv captures whilst using CQ_VBR.

This lends some support to my theory that CQ mode is better for noisier sources, even at low resolutions.

SansGrip · #**352** 01-04-2003, 12:05 AM

Quote:

Originally Posted by segfault

I just find it totally bizarre that 35/normal produces a *vastly* superior picture at 11.6 MB than 38/high does at over 12. It appears to defy logic.

Is there really such a large disparity? I've never tried a visual comparison using normal motion search.

SansGrip · #**353** 01-04-2003, 12:09 AM

Quote:

Originally Posted by jorel

i can't download the _test.zip........"says" file not found.

Those are really intended only for muaddib and GFR. The latest one is here in case I forgot to post that before

.

SansGrip · #**354** 01-04-2003, 12:10 AM

Quote:

Originally Posted by black prince

What CQ and motion search percision are you using?

My tests were done with high motion search.

SansGrip · #**355** 01-04-2003, 12:14 AM

Quote:

Originally Posted by kwag

I'm using [...] fast motion estimation

I've asked in several locations what algorithm TMPGEnc uses when you choose "motion estimation". There are two that would be desirable, called PMVFAST and EPZS, but since I never got a reply I have no idea which (if either) TMPGEnc actually uses.

If it uses its own home-grown motion estimation algorithm I would not trust it. If I knew for sure it used either of the abovementioned algorithms then I would be much more inclined to use it.

Until I know what algorithm it uses, I'd rather stick to a thorough full search, as provided by the other (non-estimation) settings.

jorel · #**356** 01-04-2003, 12:27 AM

Quote:

Originally Posted by SansGrip

Quote:

Originally Posted by jorel

i can't download the _test.zip........"says" file not found.

Those are really intended only for muaddib and GFR. The latest one is here in case I forgot to post that before

.

ok,i got it.

thanks!

SansGrip · #**357** 01-04-2003, 12:30 AM

Quote:

Originally Posted by jorel

ok,i got it.

By the way, in case anyone was wondering what all this programming mumbo-jumbo is for, we're hoping to add a WYSIWYG-style cropping window to FitCD so you don't have to pull up VirtualDub or TMPGEnc to figure out how big your borders are

.

kwag · #**358** 01-04-2003, 01:00 AM

Quote:

Originally Posted by SansGrip

By the way, in case anyone was wondering what all this programming mumbo-jumbo is for, we're hoping to add a WYSIWYG-style cropping window to FitCD so you don't have to pull up VirtualDub or TMPGEnc to figure out how big your borders are

.

I can't get enough of this

Boulder · #**359** 01-04-2003, 06:25 AM

Quote:

Originally Posted by SansGrip

Quote:

Originally Posted by jamesp

I find using CQ at High quality motion search gives far better results than CQ_VBR at MUCH smaller file sizes. The Encodes are absolutley perfect! I was ready to give up on tv captures whilst using CQ_VBR.

This lends some support to my theory that CQ mode is better for noisier sources, even at low resolutions.

So you'd suggest that CQ should be used for analog TV captures even when encoding at 352x576? Or will FluxSmooth get rid of the noise completely

Edit: And what were the spoilage settings in the CQ tests?

jamesp · #**360** 01-04-2003, 06:58 AM

Quote:

Originally Posted by Boulder

Quote:

Originally Posted by SansGrip

Quote:

Originally Posted by jamesp

I find using CQ at High quality motion search gives far better results than CQ_VBR at MUCH smaller file sizes. The Encodes are absolutley perfect! I was ready to give up on tv captures whilst using CQ_VBR.

This lends some support to my theory that CQ mode is better for noisier sources, even at low resolutions.

So you'd suggest that CQ should be used for analog TV captures even when encoding at 352x576? Or will FluxSmooth get rid of the noise completely

Edit: And what were the spoilage settings in the CQ tests?

I've just finished an episode of Midsomer Murders - after taking out the adverts it is 1hr 45 minutes and it fits on two CD's at 544x576. It looks superb! I captured in AVI_IO (the best capture program available) at 544x576 so i don't have to resize. I do the Cropping in TMpeg for the time being. Here is my script:

# --- AVS Script Created by AVSMaker --- #
AviSource("D:\Captures\MSMurders\capture_1.00.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.01.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.02.avi" ) + AviSource("D:\Captures\MSMurders\capture_1.03.avi" )
Trim(1114,31165) ++ Trim(37463,55052) ++ Trim(61352,80395) ++ Trim(86662,113947) ++ Trim(120219,143573) ++ Trim(149852,180242) #Trimmed Frames make new movie
LoadPlugin("C:\Program Files\DVD2SVCD\MPEG2Dec\MPEG2DEC2.dll")
Fluxsmooth(15,15)
TemporalSmoother(2,2)
# --- End of AVS Script Created by AVSMaker --- #

By combining Fluxsmooth with temporalsmoother with these parameters, I find that all the noise is gone and the encode looks nice and sharp on the TV. By setting the CQ to around 72 ish and using B picture spoilage as 20, I can get an Hour of Full Screen TV capture at 544x576 on one CD, although at that lower quality you can see the odd artifact here and there. If the TV Cap is widescreen I set the CQ to 80-85 and then I can get 1 hour per CD at fantastic quality!

Jim

P.S - If you are wondering what the AVSMaker nonsense is in the above script, for some time now i've been writing a program called AVSMaker which is designed primarily for TV Captures because i hated using virtualdub. It allows you to load in multiple AVI files and offers a fill GUI to delete adverts and use any of AVISynths functions like tweak etc. It even includes frame previews using your filters like virtualdub does. I haven't finished it for 2 reasons. 1) All the goalposts for resizing and cropping etc using AVISynth seemed to be changing by the hour! and 2) My wife keeps getting me to do things around the house!