CQ VBR vs. 2-PASS VBR for SeVCD

[Sefy]

Sorry for not being here long, i've just went through all you said, and i'm curious, is the Detect Scene Changes realy that bad ? should I release updated Templates with that feature Deselected ? does it help for any movies at all, or is it just bothersome ?

I never thought my Templates would become a topic on VCDhelp

[homerpez]

Sefy: Yes, "Detect Scene Changes" is that bad. I tried the movie Raising Arizona. It experienced stuttering motion throughout the movie, every time it would change scenes or have a lot of motion it would stutter.

So I raised my MAX bitrate to something like 2000 (this is using 2-pass VBR). This eliminated the fast-motion stutters, but the lag before scene change remained. Take off the "Detect Scene Change", and voila! No more stutters...

Well... at least with this one...

I'm now having one movie with "Detect Scene" off, 850k AVG, 2100 to 2250 MAX bitrate. I'm getting similar stutters again, even with these settings... so maybe this is all bunk.

Would CQ_VBR help at all with motion search/encode without stutters, or does VBV buffer mean anything? (I still don't understand what it's for)... ?

<font size=-1>[ This Message was edited by: homerpez on 2001-07-05 19:32:48 ]</font>

[Sefy]

homerpez, i'm gonna try what you said regarding the Scene Detection and i'll update the Templates accordingly, as for the VBV, I believe it helps to put it on auto, so the encoder will choose the needed buffer for the movie. also for CQ_VBR, I think it's better then CBR.

[VidGuy]

I had this same problem with low bitrate XVCDs on my Pioneer DV-333. Interesting solution to the problem - burn the VBR MPeg1 as a non-compliant SVCD, not as a non-complient VCD (this was with Nero). All stuttering went away.

Not sure this will work for everyone, but it definitely did the job for the DV-333.
Cheers.

[SatStorm]

I tested the "detect scene off"...
It is really better than "detect scene on" expecially if you using the "motion estimate search" option to encode...
and that is really fast!
I also now testing that "soften block noise" feature... What is "intra block" and what is "non-intra" block?
I tweak it a bit randomly, and I had great results some times! But never go beyond 45!

[homerpez]

Just an update...

the problem with stuttering I had with stuttering (where I said it might be all bunk)... well, the STUTTERING is what's bunk.

I went ahead and burned the VCD I made (that stuttered on my PC), then played on my Apex machine. No stuttering!

Apparently this was a fluke on my hard drive, I think because I needed to defrag. I just assumed that because it stuttered at the same spots every time, it was the encoding I did. But it was actually the playback on PC.

Didn't want anyone else with a problem on a standalone to panic, since there ARE NO problems on my standalone.

So, this means Sefy's template (using 2-pass vbr instead) is a 100% success so far for me!

[tacosalad]

It sounds like it's coming together.

By the way guys,

Thanks for listening to my rant about "detect scene changes". That one's been bugging me a while, and I just sort of let it out in a yell!

It isn't intuitive at first, but "detect scene changes" can cause a sudden drop in picture quality immediately before a scene change. The picture just turns really blocky for a fraction of a second, then it cuts to the next scene.

It took me a long time to figure it out, but in retrospect it makes sense. This setting has nothing to do with quality--it's for making editable streams. In a constrained VCD or SVCD environment, it just adds another I-frame to the stream, squandering those precious bits!TMPGEnc apparantly compensates as best it can by over-quantizing the frames in the GOP immediately prior to the surplus I-frame.

SatStorm,

Each B or P frame is made up entirely of "intra" or "non-intra" blocks. The "non-intra" blocks are copied from somewhere within the previous frame, usually with minor adjustments. (This is what motion-estimation is about--searching the frame for a good match.) The "intra" blocks are used when there's not a good match, so a particular block has to be described "from scratch".

When the blocks aren't precise enough, their edges don't match. It's sort of like seeing the seams between strips of badly hung wallpaper. The blocks are sometimes branded "macroblocks", although the term "block noise" would be more accurate. (Technically macroblocks are the wallpaper itself, not the seams.) TMPGEnc's "soften block noise" option works by shifting high-frequency energy into improved low-frequency precision, so the edges of the block fit more precisely but there's less detail within the block.

Sorry if my answer is a bit obtuse! Your question really hits on several esoteric areas of mpeg, and I can't think of a very succinct explanation.

[Sefy]

And some of the people here say I know everything! thanks for all that information tacosalad!

homerpez, i'm glad to hear you are now fully satisfied with the Template and that there are no more problems for now anyway!

[SatStorm]

Thanks also for the explanation of "intra" and "non-intra" blocks.
I still test it: If you set intra to 5 and non-intra to 15, you have good results, with no quality loss!
That fuction needs hardcore test!!!!