What's up with TMPGEnc's 2pass? / Converting MYSELF to CQ..!

[EddyH]

A story With a question waaaaaaaaaaaaaaay down at the bottom.


I never thought I'd start doing this.. but from now on I'm probably going to encode all my videos in CQ.... old-style CQ from TMPGEnc 2.5 and previous. Why? Because it seems to give the best visual quality per bitrate and the most constant too, which is less jarring on the eye. Plus it's a little faster - IF I can guess the level right within the first two tries.

This has come about because of a 2-pass encode that came out looking pretty rotten in some sections, but pristine in others, and actually had a worse balance than a constant bitrate version - which I thought wasn't supposed to happen. A bit of examining them with a bitrate tool I recently downloaded, and a *very* old CQ video I made (>18 months ) showed some surprising results. The 2-pass seemed to be getting a bit confused as to where to vary the bitrate, and stuck in a CBR-like mode about 5-10% under the 'average' bitrate for much of the file; occasionally raising the flow of bits, but not to even as much as twice the set average, and nowhere near the maximum bitrate I set. Also it tended not to 'aim' very well, rarely increasing the rate on parts that *really* needed it, and increasing it on parts that didn't, or a few seconds after where it was needed.
The rate almost never went below the 'set' 90-95% cbr level, nowhere near the set minimum.

The compression level / quantiser therefore went pretty wild, as proved by eyes; I'd been hoping for a decent quality 120m widescreen video on an 80m disc (not too much to ask as the borders would account for a lot of bitrate saving). Instead, although some parts were pristine (a 1.00 quality), others were horrendous and nearly unwatchable (qualities >20), and which parts had what quantiser seemed pretty random. In comparison to the CBR mode, which even with keeping a steady and unchanging rate, did not have a compression level of over 16, though it did have a whole lot of 1.00 .... granted my average for the vbr was only 780k/s compared to 1150 constant, but with a 2376k maximum, 32k minimum, and many many simple, still scenes, I would have thought the 2-pass encoder could spot this and compensate!

This surprised and concerned me of course, as I've been using 2-pass for all my videos and most have come out fine (although not brilliant; generally i make a 2-CD archive copy too)... I can only assume this one went bad enough to be noticed because it can get complex at times, and is an animation (with the special animation mode no longer working 'properly' in tmpgenc, I cannot use it).

The very old CQ video, which was done mostly as an experiment (only 90-odd minutes for one thing) surprised with a continual very good visual quality, and an almost concrete 2.x compression level, only peaking above this when there was a consumate bit shortage - ie the rate was pegged around 2350-2400 - or getting 'better' (almost undetectable in the final video) when the scene was so simple, such as a fade to black, that the rate came very close to minimum. Inspired by this I had a go at re-encoding my video using CQ in 2.8.....

Though, of course, CQ in 2.8 is now only available as some strange hybrid between the old style and loose VBR... it works *better* than 2-pass, but still plays fast and loose with both the quality AND the bitrate. Quality levels don't go quite so out of control (it's comparable to the CBR at least) but the encoder seems to care little for the maximum set rate, peaking up above 3000 for three or more consecutive seconds in places with a set rate of 2376 (which with 224 sound is the hardwired maximum rate for my DVD player...). This seemed better but still not brilliant, so I hunted out my oldest surviving copy of TMPGEnc... 2.5
(i'd like to go back maybe to 2.4, 2.3 when I have a chance, to have an operable animation matrix).

This has a full, pure CQ mode, though it has confusing P- and B-frame spoilage settings added in. However the documentation says the default settings should work fine for everything, so I left them.
The results compared to VBR and CBR were incredible; compared to "CQ_VBR", still better. Using the bitrate viewer, the quality level could be seen to follow a similar pattern to the old file - staying at, or at least close to, a certain level dictated by the quality percentage (this level appears to change in large chunks, maybe every 8%, with variability being finely tuned by the in-between percentages), again only rising - ie becoming lower quality - when the encoder was bit-starved, or becoming better quality in the quietest, simply-can't-encode-it-any-worse moments. Which is good, as slight blockiness is less likely to be noticed when things are flying around at high speed, and more so when everything's stopped.

Guessing at a suitable quality for my video - 67% - I set it all up, all the filters and everything, maximum motion search, and let fly. Ten or so hours later (instead of 20!), return to try it out. Find a file that's only 490mb instead of the preferred ~670mb... no bad thing, if the quality's alright, but may as well use the extra bits if possible. (Even with extra HQ 256k sound, there'd be another 90mb to burn). Quality turns out to be quite surprisingly good, quantiser sitting around q3.5 for the most part, only going as 'high' as 6 on the most demanding, 3-second part. Compared to 21+ that's quite a coup! Most of it looked excellent, even the high-motion scenes. Still parts looked just like uncompressed RGB, no compression artifacts at all. But, slight and noticable MPG 'crinkliness' on the edges of slow-moving characters........

So, after running a few more short test clips (about a minute of representative scenes at 5% Q intervals) and building a little graph, i've plugged it back in at 75% and a little extra contrast to try and hide the crinkles in the darkness and brightness Another 9 hours to go. If only I can get the PC to stay upright, it's becoming more and more unreliable of late....


So.

The questions, after that little tale of one man's damascus..

1. Why doesn't CQ get covered more in the tutorials?

2-5. Just what's going on with TMPGEnc's 2-pass encoder? Is it something to do with it only being two-pass? Would a multipass encoder such as CCE work a bit better, eg doing 3 or 4 passes to figure out it's mistakes (eg q of 1 to 21, when a steady 2.5 would work)?? And why was CQ removed from the later versions (is it present in the Plus version?)?

6. Any other CQ veterans out there, is it worth it in the long run, having to guess at % levels rather than plugging in an approximate bitrate and letting VBR spit out a proper sized good-enough file? Any tips and tricks for getting it closer first-time?
(i'm thinking... a min-quality CBR encode at about the required bit rate... then analyse it and base CQ off the average quantiser?)

7. And why, please why, does my computer fall over if I try to combine Internet Explorer with any other program these days? This has developed over the past couple of weeks and is VERY ANNOYING. Double click Internet Explorer without closing EVERYTHING else, voila, instant hard-as-rock locked up computer 9 out of 10 times. Ctrl-Alt-Del will reset it 40% of the time, the rest of the time, it's _completely_ dead. Every other prog works fine with every other, even if I'm converting a 2-hour film 2-pass at max quality, doing complex filtering on an unsaved 80 minute CD quality wave file, manipulating a flashcard's worth of digital photos, and burning a CD at 16x, all at once!
I'd get a different browser, if only I could think to do it BEFORE starting an encode/sound processing/backup/etc... and I didn't suspect it to be something to do with the network connection anyway.

Grurgh.

[EddyH]

* just to pre-empt anyone asking why I was aiming for a 670mb file, not ~800... I encode my audio separately 670 + 135mb audio (160kb/s) + 5mb multiplex overhead = 810mb = just the right size with about 30-45s overburn

[LanceSteel]

Maybe the poor quality of the Svcd stream is due to the lower bitrate? I don't know for sure. All I know is that I use 2-pass VBR when I am encoding MPEG2 streams for burning on a dvd-r. I am usually using an average bitrate of 4500 (vs. 1800-2000 for svcd's) and the streams look damn good.

[sterno]

I don't like CQ encoding myself, but...

1. Why doesn't CQ get covered more in the tutorials?

What really needs to be covered? The general procedure for encoding a disc isn't significantly different from one encoding method to another.

2-5. Just what's going on with TMPGEnc's 2-pass encoder?

What you describe actually matches what I've seen recommended for 2-pass encodes. I've read that it's best if your minimum and maximum are set to be around 15% on either side of the average. I've also read that tmpgenc has a bad tendency to mess up the quality of an entire clip just to give all the bitrate to one complex scene, instead of sacrificing the quality of that scene to keep the overall quality higher. I've never seen the problem you describe, though.

6. Any other CQ veterans out there, is it worth it in the long run, having to guess at % levels rather than plugging in an approximate bitrate and letting VBR spit out a proper sized good-enough file? Any tips and tricks for getting it closer first-time?

You can use some type of file size prediction to trial-and-error your CQ level with 10-20min per test instead of several hours. I would suggest looking around the KVCD site (http://www.kvcd.net/) for some information. Since those templates are intended to use CQ they have quite a bit of information on size prediction, mainly on the forums.

I've tried CQ size prediction, it works reasonably well but is pretty labor-intensive if you don't get it right in 2-3 tries. It also does a terrible job if you're doing something like IVTC that changes the number of frames. I have found that keeping the video bitrate below 2500k requires setting the maximum to about 1800k - more than once I've found the average bitrate on a CQ encode to be higher than the maximum I set (gee, no wonder the quality is good, if I just crank the bitrate on my 2-pass encode up to that level it'll probably look good, too).

[EddyH]

Lance, that's a fitting picture, you just went backwards as to my entire point I suppose the post was long, but still.....!!

Yeah, I know it's not a fantastic bitrate for good quality video, but with VBR, I was expecting something at least as good quality as a standard, medium rate, CBR video CD (it's a plain MPG1 VCD by the way, guess I shoulda said that. PAL, 25fps 352x288, with a centred ~16:9 movie), with a fairly constant visual appearance - maybe not as fine as it could be in the still sections, but not as blocky as CBR in the high-motion parts. Instead TMPGEnc's 2-pass codec, if anything, has actually amplified the quality differences instead of squashing them. Still parts can't be told apart from the original DivX*, except for the rez. High motion parts actually looked just as bad as CQ at 'zero' percent quality, which had an average bit rate of about one eighth of the VBR (ie 100kbps instead of 775)... Quite shockingly crap!

If I was using DVDR I wouldn't be having this kind of problem as my quantiser would probably be hugging the 1.00 line anyways Then again if I could afford a dvd recorder and the media I'd probably be buying the actual films instead of downloading, until the prices (of burners and media!) dip just a little further.


* and it's an -incredibly- good quality, two-CD DivX that I wouldn't think is very far removed from the original DVD, barring a few percents resolution and the loss of two 5.1 streams and a 2.0... looked my hardest but dammit if i couldn't find a single identifiable bit of distortion! (just the standard divx black-isnt-black murkiness)

[EddyH]

Sterno..... in resp to your resp to my questions;

1/ Eh, I dunno, I just remember trolling thru all the tutorials and only seeing CBR or 2-pass stuff, much like only seeing audio tutorials involving TooLame or TMPGEnc.... maybe I need to look harder A lot of my stuff was self taught using tools leeched off my net-head brother before I found this site so I didn't look so thoroughly!

2/ Hmmm even that wouldn't be -so- bad, if it would go down to 15% under (you sure about that 15% over thing?)... or be a bit more accurate when allocating the higher bits.
As for TMPGEnc going crazy and spewing all it's bits at one scene, after doing this analysis it seems credible, if strange...! After all you set a max and min rate, shouldn't it vary tween the two? Again the constant quality wins because it actually touched my maxima and minima several times without going past them and didn't foul things up because of it!

My previous idea of how 2-pass works, I dunno how accurate it is:
Encoder goes through and encodes whole film at CBR of the average rate, notes what quality comes out for each frame (or at least each GOP/each second) with this setup in a log file. On the second pass, after a bit of maths, it gives proportionally more bits to the more complex (ie lower quality at cbr) parts and takes them away from the less complex parts to keep everything in balance, going as far as the maximum and minimum if neccessary, though it doesn't "normalise" to them. Generally aiming for a constant, or at least reduced range, quality level. What's happened, as i just said, is the reverse, or randomness. Argh. My file, especially the part I chose to test, has some fairly well defined areas of extreme complexity and extreme uncomplexity (is that a word!?), particularly over one scene where they intermingle in 10-ish second bursts. CBR kept a constant bitrate with the quality going up and down. CQ kept a constant quality with the bitrate going up and down. VBR tried to strike a happy medium between the two but went mental. I suppose it's a bit hard on the encoder to do that as well as keep a final file size at least within 5% of the set one, but why keep the buggy mode and throw out the working one?

One thing I forgot to do is encode the whole thing at 775k CBR and see how it looks... probably pretty awful.


3/ The little tests I did were sort of file prediction. Basically what I have now is a somewhat blocky curve showing how the 'constant' quantiser (what the encoder seemed to be 'aiming for' and flatlining on for a number of places) and the average bitrate for that particular 2-minute scene worked out at each % level. It's quite a nice inverse exponential shape... it needs refinement with a few other files etc, but if the same shape and relative proportions hold true at least (i expect the quantiser level to stay the same even though bitrate wont!) I can use it to extrapolate how much to change an unsatisfactory file by... After all with the quality benefit it seems to bestow i'd be happy to aim for 20mb less than i currently do, and take anything 25mb either way that looked good.

Of course just taking a random segment and then multiplying by the length of the film is a bit silly...

The CQ you seem to be using, though, I must say sounds more like the tricky new CQ_VBR in TMPGEnc 2.5 and above. The 'old' CQ i'm thinking of switching to respected the bitrate limits utterly; the only time it ever went over 2376 or under 32 was when the next lot of frames were higher/lower enough to mean that the '1 second average' at any point was actually still within limits... and even then I don't think it peaked higher than about 2450 or lower than 25 (very hard to do anyway!). Whereas new CQ_VBR went wild and up to ~3200.... The only care I'm really taking with the old one is that I'm aiming for a file of a size to be used with 160k audio, but limiting the video low enough to allow for 224.. both to keep it well inside of limits but also to allow the possibility of better sound if it comes up short enough whilst still looking good.

As for cranking the bitrate, I have little argument with the 2-pass encodes done for the 2-disc version of this film but then one is a little under twice the single disc bitrate, and the other is quite a bit over it... with 1480 and 1840kbit/s average the quality swings more from a lot of 1.00 to maybe ~8.0 max, which is far less noticable than 1-1.5 up to 20+....

(heck, CBR probably would have looked ok)

[LanceSteel]

I never thought I'd start doing this.. but from now on I'm probably going to encode all my videos in CQ.... old-style CQ from TMPGEnc 2.5 and previous.

When I see "old style" it makes me want to ask you a question. What version of of Tmpeg are you using? The old method of 2-pass with Tmpeg gives horrible results in my opinion. I'm using 2.56 and there is an option under the VBR section to use the "old method" or "old style" (something like that.) If you are using that it will look like crap. The standard new method works a lot better.

[EddyH]

I'm using 2.5 for CQ, because that's the newest one I have on my HD that supports it... for the 2-pass I've been using 2.8...

Ahhhhhh, dammit, that's one step i forgot, testing the 2-pass with older versions hehe.. perhaps thats why it's only just manifested visibly! Good of you to raise the point.

If so, add that to the list of technical and output things that have gone wrong with the program in the last few versions as the speed has gradually increased and the interface has got better. Animation matrix suddenly causing wierd blocking problems? Check. Nonstandard multiplexing no longer working any different to standard? Check. And maybe now 2-pass no longer allocating bits accurately?

I have been wondering where the 'old/new' switch went. I was using the program with 2-pass being just one model, then it sprouted an old/new switch for just one version (that i dont seem to have), and now it's 'old' or nothing. Hmmm... for twice in one short post you may be on to something!

Course if I wasnt lazy and disorganised I'd go download all the old versions to play with

[sterno]

15% is a rule of thumb for settings to use. It's not set in stone, not everybody uses it (especially with XVCD/SVCD where you don't have much space), it's just a recommendation I've seen for multipass VBR encoding. I did notice that VBR encoding in tmpgenc 2.58 was not as good as 2.56 and earlier. I never upgraded past 2.56 because of that and because of the support for only "approved" MPEG-2 codecs - my MPEG2 codec works reasonably well as a directshow source but they don't support it.

I was using CQ, not CQ_VBR, in 2.56 (and a few earlier 2.5 versions). The only way I got it to honor the maximum bitrate I set was with a low CQ setting. Of course, considering how bad my results with CQ have been a low setting doesn't really matter....

The more sophisticated file-size prediction methods don't just grab a random 2-minute sample of the movie. They use a couple different techniques with avisynth scripts to take samples from throughout the entire movie for a much more accurate prediction.

[energy80s]

I use CQ coding all the time for my "half DVD" files. It gives me a bit more space than CBR and keeps the high quality. Normally I use 4000 max and 2000 min (as MPEG 2 looks dreadful below about 2Mbps) with CQ of between 95 and 99. This allows for about half an hour on a CDR disc. The reason for choosing the bitrates is that I am encoding at half the DVD spec, so that's 352 instead of 720 horizontal resolution and 4000 instead of 8000 max video bitrate. This gives the equivalent quality of a standard DVD file in half the file size.

[Dodzzz]

Yes, the other VBR methods in TMPGEnc give really bad results per bits used compare to the Constant Quality method.

Using my own Quantize matrix, I use Quality 50, maximum 8000, and minimum 1200. (note that different matrixes affects these settings)

[EddyH]

(without reading any more responses yet)
Gack, it would help if I could actually get my own facts right

The versions I have are not 2.8 (not yet released!!) and 2.5, but 2.02 and 2.58. I think I will have to consult a psychiatrist to find out why I thought the numbers were different... maybe a mixup with Winamp
Is there anywhere on the web to download earlier versions? I guess I need 2.00 or earlier to get a working animation setting. Apparently the matrix setup was changed in 2.02 according to the changelog, to fix some problem that wouldn't affect me anyway..

Using the blocky graph to alter encode quality came out quite well, I ended up with a file that was only 10mb too big (as I didn't accurately take off of the graph, just did close-enough; should have used 74% not 75% )... and the result was fantastic.

Ah well, I needed to re-encode it anyway - forgot to re-enable outputting of the sequence header every 10 or so GOPs (PC crashed, setting wasnt saved) so the resultant file isn't easily searchable. Poo.

[EddyH]

I was using CQ, not CQ_VBR, in 2.56 (and a few earlier 2.5 versions). The only way I got it to honor the maximum bitrate I set was with a low CQ setting. Of course, considering how bad my results with CQ have been a low setting doesn't really matter....

That's pretty odd... it worked fine for me... even to the point that there was hardly any difference in size or quality from about 90% up because it was hitting the limiter all the time... Mebbe cause my own version is so much older than I realised! Or you're using MPG2 and i'm sticking solidly to MPG1 VCD.

Oh, so many MPG2 tips from people, I just spotted in this thread
(I don't really notice the lower rez, apart from a sparse few scenes where there's e.g. really fine text or anime outlines that get jaggies because of extra small detail.. Plus my PC is slow, I don't have registered programs, and my DVD's maximum CDR speed is only 2x... MPG1 with SVCD bitrates on VCD are pretty much neccessary)


(as MPEG 2 looks dreadful below about 2Mbps)
Heh, tell me about it... (remembers making SVCD of 85 minute film... even discounting the messed up matrix, motion scenes looked awful and as if they were built from lego. VCD was like silk )

[EddyH]

Ooh, how strange.

Played around with a short clip, basically the first 1500 frames of the movie, with many different encode modes, matrices and the two versions. It may have been because of the blockiness and bugs and all, but the Animation matrix actually came up having about five percents worse efficiency either quality-for-bits or bits-for-quality compared to TMPGEnc's 'default' matrix. MPEG standard came out maybe 20% worse!! Good job I don't have anything that requires it's use then.. wow. Also the 2pass in 2.02 was... -slightly- better, didn't lose quality as badly on complex parts as the 'new' (ie old... ah... brainpain) type, but still lost to CQ. The only difference being, at the same average bit rate, it had maybe 10% better average quality, but all the same it flailed on complex scenes and didn't give them enough bits to avoid obvious break-up, while allocating 'far too many' bits to quiet segments, eliminating the barely visible distortion as before.
However, the up-and-down of the bitrate graph followed the quality change, which is different.

[SatStorm]

CQ for DVD?

With TMPGenc, you have to learn things beyond typical settings. The problem is that most users load a template and hit encode and they expect miracles.
Well bad news. It's not working that way with TMPGenc. Expecially with the 2 Pass VBR mode.
That's why I never publish any CVD templates. You have to determine the settings yourself, depending the source you are using, the leght it has, your target filesize, the -X- or non -X- factor, etc...
You want the best results with no trouble? Use CBR. You want to play it clever on filesize? Try your luck with CQ modes. You want perfection? Study TMPGenc, test a lot and go 2 Pass VBR.

The bottom line is that with CQ you have excellent results the easy way. For most users, that is the way to go, expecially if they don't care for filesize.
With 2 Pass VBR you can succeed always BETTER results. But, you have to know how to do it. It isn't easy, it isn't automatic, it isn't for anyone...
The way I see it, if you simply want to do your job done, then use CQ. It is easier to use, automates many things and the results are great.
If you want to push it to the limits and you have time to spent testing, go multipass VBR. It worth it, but you gonna see the results after some time...
The silly thing, is that this subject is for TMPGenc users only. And that because TMPGenc changes a lot in every update and because it looks easy to use, but it isn't! There are those small things doing the huge difference in the results.
Like the new TMPGenc rule: On 2 Pass vbr, the minimum and maximum value, must be equal distant the average value. Unfortunatelly, that means -X- for any CD based media, but you are OK if you burn on DVDs.
There are also some older TMPGenc rules, I don't see anyone follows. Like the lower minimum you have to use to support your encodings. When I read that users are using as minimum 500kb/s for SVCD, which is totally faulse. SVCD needs about 1300kb/s to support good picture on a multipass VBR.

Anyway, the easy way always is sweeter that the hard work one. But the best and that's my point. Choose: Easy and excellent, Difficult and perfect. CQ or 2 Pass VBR. Depending your needs and your targets, thats your choice!

[EddyH]

Satstorm, your new rule looks interesting, I'll have to try it. As for CQ on DVD, unless I was trying to squeeze six hours of tracking shots in I think 2-pass would be fine

As for now... tinkering with TMPG and 2-pass (i dont use templates ) simply didn't look as good as my CQ encode no matter what I did.. just for this once anyway. If anyone can recommend somewhere to look I'd like to find the version with 'new' 2pass, or one of the older ones before it split, to see if this film would come out better with 2pass in them...

Mmm, CQ74, minimum 32, max 2376, so on and so forth, looked great, fitted into 79 minutes and 58.7 seconds in the end including menu and CDi, leaving a whole rack of overburn to put in stillframes, etc. Lovely.

Now I'm on a personal challenge... to see if I can get the same film in watchable quality on an -8cm- CD, messing with the modes again. Yes. Inside of 230mb, probably not even possible with DivX Already got the audio sorted, 56k mono with a 12khz low pass filter sounds 'good enough', clip the view port down to 320x192 from 352x224... hehe....

only problem is, i don't think I can actually set my lower bound video rate far enough down with this audio to get the action scenes even 'watchable' let alone 'good' without either the file overspilling or the dvd player crashing
wish me luck...

[sterno]

Doing CQ encodes, do you ever see sort of a tearing or stretching during horizontal motion? ie motion that should look like this:

---XX-    --XX--    -XX---
---XX-    --XX--    -XX---

ends up looking like this:

---XX-    --XX--    -XX---    -XX---
---XX-    ---XX-    --XX--    -XX---

or this:

---XX-    --XXX-    -XXX--    -XX---
---XX-    --XXX-    -XXX--    -XX---

or some combination of those, usually with noticable flicker at the same time. I've seen something like that with most of the CQ encodes I've tried, and I'm not sure how to get rid of it. That's one of the main things that keeps me from using CQ more often, I can't say just from the source material and CQ level whether or not it'll happen.

[Baldrick]

I think this belongs in the advanced conversion forum...so I'm moving it...

[EddyH]

Baldrick - right you are, it seems to be heading that way

Sterno - can't say as I ever have. Sounds like an interlacing or more precisely a 3:2 pulldown type of problem, not something I have to deal with a lot in PAL-land
Plus I convert a lot of animes, "true" fast motion isn't so common, and I've only just started with CQ anyway (heck I think I only have one live film and one anime using it!). When I get back to college from this short home trip I could test my old copy of Swordfish...

Mebbe its the encoder messing up, mebbe its your player, i dunno, but it's looked fine and dandy to me so far. Apart from the pulldown, maybe it's a sync problem, like in a game where the frame rates are getting quite high but VSync/buffer flipping isn't turned on - is this occuring on a TV, or on a PC? And when it does happen, whats the setup like, ie are you trying to watch an NTSC movie on a PAL TV, or a 60hz source on an 85hz PC screen?

Why it should only be happening with CQ.... -shrug- ... maybe it's suffering a bitrate shortage where VBR or CBR might have over-sauced the pudding, or getting enough bits to show the real motion where the other methods would have smeared it into invisibility... got an example file I could look at?


* on the pulldown note, i've noticed that whoever made the UK TV trailer for I-Spy was quite lazy, they've just run the NTSC trail through a scan converter instead of re-cutting it from the film, and a cheap one at that... nasty telltale pulldown 'smooth jerks' all over the place. Fast-slow-fast-slow... hopefully this doesn't bode badly for the US DVD being a 30fps interlace knockoff...

[SatStorm]

Hi Sterno,
I don't think that this is a CQ mode problem only.
I see this problem when I turn a 29.97 NTSC source to 23.97, using virtualdub's field adaptive method and frameserving in realtime to TMPGenc. There, if I encode to PAL, I have this problem.

The only way to solve it, is to do the convertion the right way (ITC with virtualdub, save to new avi, boost it with avifrate, encode with TMPGenc. But this requre lot of HD and also, the speed up may not be pleasent on some situations (it is O.K. for movies)

[DJRumpy]

The adaptive method in VirtualDub isn't flawless. I still see interlacing aritifacts from IVTC'd film done with this method. They usually only show up in high motion scenes though. It sounds like your seeing a single frame, with one field from the previous frame, and one field from the current frame. It gives you an offset picture like the one your describing.

Conversions to and from PAL should use a strech method, and not a drop/add frame method.

There isn't really nice way to take a true interlaced source at 29.96 fps, and reduce it to 25.976 frames per second (or vice versa). The jump is simply too noticable. If your source is telecined to 29.976 though, using the method SatStorms describes will yield good results 95% of the time.

It's also important to note that VirtualDub has a problem with using the Adaptive setting, and applying filters at the same time. You tend to get a mess as a result. Run it through and save it using adaptive setting before applying anthing else.

[sterno]

Well, since I've seen it with progressive FILM source from a ripped DVD used to create an NTSCFilm disc to play on an NTSC TV, I don't think that it's only related to IVTC/interlace/field order/etc. I don't see it in alternating lines, it's usually more of a top-to-bottom thing.

I suspect that it has something to do with a bitrate shortage, but I don't really see why it would be almost unwatchable in CQ and just blocky in 2-pass VBR. I don't think I have any of those encodes left, though, there isn't much point in keeping something around that gives me a headache (if there were I'd go find a girlfriend ). I still use CQ sometimes, but I'm very careful about what I use it for and I usually don't see a problem.

[DJRumpy]

Well, since I've seen it with progressive FILM source from a ripped DVD used to create an NTSCFilm disc to play on an NTSC TV, I don't think that it's only related to IVTC/interlace/field order/etc. I don't see it in alternating lines, it's usually more of a top-to-bottom thing.

All of these things are irrelevant. If the wrong field order is picked during the ripping process, the problem will exist, regardless of what you end up converting it to. Using the wrong pulldown options (i.e. switching the field order) during, or after encode, again, could also introduce problems before the burning phase. Ripping the DVD at 29.976, and then performing IVTC can also introduce the problem. Just because your sticking to NTSC doesn't mean the problem can't exist.

I'm not sure what you mean by 'top-to-bottom' thing though. Can you describe this in more detail?

[EddyH]

DJ I concur on the Virtualdub adaptive thing, it can be a right pain in the proverbial. Had to split a film into five parts once as it kept "drifting out" of sync with certain scenes and then sticking where it had drifted for the rest of the film >_< something not quite right there.

What sterno means though, as far as I can tell, is the top half of the picture shows the source out of one frame, and the bottom shows source out of another - like the player or encoder is switching to the next frame at the wrong time, halfway through the beam scan rather than during the blanking period. Otherwise known as 'tearing'....

As for PAL conversions - pull it down/up (?) to 24 frames if possible/neccessary and then time compress, ie accelerate it all a few percent. Works pretty well for films. TV shows a little more tricky.