TMPGENC PLUS encoding error at high quality mode

[inuyasha]

Hello all.
My recent project was to convert some home DV movies to DVD mpeg2 files by ulead visual studio 9, then resized them from 720x480 to 696x480, frame serving to Tmpgenc plus to make a final mpeg2 for final authoring. The reason to resize is purposely distort the final image aspect ratio so the ladies in the movie would look slimmer per their request! Anyway, that's another story. :P
The mpeg file was from DV source, converted by Ulead to DVD mpeg 720x480, 8000kbps VBR. It was then opend by Virtual Dub, applied the Lancoz3 resize filter then frame served to Tmpgenc.
In Tmpgenc I used the calculated bitrate of 6800kbps, no filters, default resolution 720x480, center arranged, 2 pass VBR with max 8000 and min 0, using highest quality (slowest speed) motion detection. It took about 15 hours to finish the 50min footage.

I test burned it onto a DVDRW and watched it on my regular TV. The quality was amazing, with good details and resolution of objects with complex textures, like waterfalls and a forest of tree branches without leaves. However, as I was paying attention while watching it, I noticed there were 6 incidences each of which lasted about 1 to 2 seconds, where a few tiny rectangles of noise blocks appeared briefly in a cluster, or in a horizontal line on the screen. They are sort of like the garbaged data from playing a dirty DVD movie disc. However, when I played the mpeg file outputted from Tmpgenc that I used to burn the DVD, those "noise" blocks also appeared at the same time line and same location on the computer screen. Looks like the problem stems from the final mpeg file (The original mpeg fed to virtualdub to fram serve Tmpgenc played fine on computer, or burned to DVD and played on TV).
I looked at those "noise" blocks/lines in still frame, and noticed they contained distored image info from the area of the normal image close by to the noises. For instance, there could be a noise bar about 40x15 pixels across the forehead of a person in the picture frame, and you could find a hint of eyes in those "noise" pixels.
I redid the whole thing (frame served by VD and encoded by TP) with the same settings 3 more times, and each time ended up getting "noise" pixels at all different parts in the movie, but the number of incidences were about the same (5 or 6 ) in each repeat.

I then tried re-do with "high quality" and "normal" and "motion estimate", everything else remained the same each time, twice per each motion search option, and I found:
1. At high quality mode (second best), the "noise pixels" sighting frequency decreased to about 2-3 times. At "normal" and "motion estimate" modes, it decreased to 0-1 time.
2. The location of the "noise pixels" is constant within each encoding, i.e. playing the same output mpeg from TP or dvd over and over again would re-create the same pattern of noises at the exact time and co-ordinates on the screen. But once re-encoded, even with unchanged setting, the noises moved randomly to other locations.
3. "motion estimate" or even "high quality" mode do not give the kind of clarity and finess obtained by the "best quality".
4. The input mpeg file by Ulead had noticeable blockiness in dark areas, like a tree stump, but after re-encoded by TP, even in just "normal" mode, the overall picture quality improved, and the blockiness went away. This is just a side note, not really part of my problem here

I don't think I noticed such a behaviour with TP before (points 1-3), but I only started to work with hour long footage lately weeks ago.
Did you folks have similar experience with TP with longer movie lengths particularly related to possible encoding error by TP in highest quality mode?

I couldnt experiment other modes like CQ, or CBR cause everytime I got a "divided by 0" error. I only wanted VBR anyway for supposedly better quality at a given bitrate

Any thoughts / experience to share?
Looking forward to any comments.

[jimmalenko]

I'd suggest that since your source is homemade DV, you should have probably looked into some denoising and possibly some deshaking filters (if it's handheld), as I'm led to believe that these two factors can eat up the bitrate quite significantly if not filtered out.




and BTW, I don't get this poll ...

My answer is Yes. When I was a NOOB and I didn't know what I was doing in TMPGEnc, of course I got some pretty ordinary results - especially when I didn't understand the importance of bitrates used in the whole scheme of things - all just part of the learning curve