bad suggestions in TMPGEnc Games-Realm guide

[lordsmurf]

It's nice to see guides, but that one strikes out at the plate.

The proper way to speed up encoding is by going into the environmental settings and turning on all the options. Also increase the task priority to highest and leave the computer alone.

Step 4B suggests Lowest quality, which is a horrible hit to quality. Use Estimate mode for best speed, not lowest. While it has been said by several people before, and I agree, the "Highest" and "Lowest" settings are speed settings, not so much quality. But the lower ones CAN affect quality. The Estimate/High/Highest do about the same thing (the excepttion is that HIGH or HIGHEST needs to be used on 1150k VCD MPEG1).

Step 4F suggests that detect scene change be unchecked because of speed concerns. The speed is barely affected by this setting. And it is best to ALWAYS keep it on, otherwise a P or B frame will exist where an I frame should have, and you'll get this messy macroblock/blur effect (like you see on VCD).

Step 4G I/P only is not even an option for MPEG2 for DVD. It is not supported.

Step 4H. Never use No Motion For Still unless you're working with still frames. A movie is motion frames. Using this setting will cause jerkiness in the playback.

Don't get me wrong. I feel bad ripping this guy's or gal's guide apart. But I foresee a whole bunch of TMPGEnc quality questions around the corner because of some of the settings mentioned in it.

My TMPGEnc Plus guide is around the corner, and it directly opposes from of the things in the Games-Realm guide. And I get near-real-time encoding speeds. I would never hurt quality to save time, and this Games-Realm guide is unfortunately going to have that adverse effect on video if used.

[adam]

Well I agree most of these speed optimizations come at the expense of quality, but that seems to be the whole point of the guide. For just about every step, the person says, in their opinion, how significant the quality hit is relative to the speed increase, and simply says "you decide."

All of the things he/she listed should have at least some effect on encoding speed, so if people want to cut corners then they have that option.

As for the motion search precision, the guide IS flat out wrong there. The motion search precision option is literally exactly a quality setting. This is obvious just from the tooltip you get when you hover over the option in TMPGenc. If you consider how mpeg encoding works then it is easy to see why this setting directly prioritizes speed versus quality. Mpeg encoding is really nothing more than motion searching and grouping/removing data according to that motion. I don't know what a "speed setting" is. I can't think of any reason why someone would choose a slower speed over a faster one.

Once again, this setting is literally a QUALITY setting. The resulting encoding speed is simply a byproduct of how stringent you set the encoder to search for the redundant data that it removes, which again is all mpeg encoding is, ie: removing redundant data, or in other words, the part that doesn't "move."

As far as the visible differences between different motion search settings, it is like night and day. You can plainly see a difference between lowest and high or highest. I totally agree with you that this is one corner than should not be cut.

One thing I will say to the author of this guide, next time don't use such an incriminating source for your example.

[SaSi]

Regarding motion search and Quality and Speed:

Adam said that the motion search setting is a quality setting. I agree with this, in that it affects quality. However, it is important to understand how before one can select a different setting to their benefit.

The motion search, as Adam pointed out, is looking for blocks of picture repositioned to other coordinates so that a motion vector can be calculated. This allows the MPEG encoder to encode the new position of the matching block as a 2 byte motion vector plus some difference in pixels, which essentially is the predicted frame contents.

This helps quality because it requires less bits to encode. Meaning that bitrate utilization is better and more bitrate is available for other parts of the video where motion search and estimation cannot find too many matching patterns.

Now, If one encodes a rather stationary movie (i.e. not sports) or can encode using a rather high bitrate (e.g. 8Mbps avg for video), then motion search does not become so critical a tool to reduce bitrate.

So, if you encode for VCD or SVCD (where bitrate is rather limited), motion search is an invaluable tool to ensure that quality is not a total waste. But for DVD and relativelly high bitrates, motion search becomes less important.

It's easy to prove the above.

Encode a low action DVD movie part at 8Mbps two pass VBR (with min set to 200bps and max to 9,5Mbps) with motion search set to lowest quality and once more with motion search set to highest quality. You will most likely not notice a difference.

Then encode a high action (sports) video at 2,5Mbps average with the two extremes in motion search. You will most likely notice quite a difference.

[ta2]

Thanks for all your comments.

This is my first guide, and as you can see from my post count, I am a bit of a newbie.

As for your comment on I/P Frames only, there a discussion about a week ago...

https://www.videohelp.com/forum/viewtopic.php?t=178601

IPPP is a sony spec. I did note in my guide that it might not work on all players.

Anyway, about the motion search estimate, can you think of something I could say instead of what I did say. (Minimal effort here, I just want something I can cut and paste :P).

Thanks

ta2 (Games-Realm)

Also, I may need to transfer the guide to this site, since I am getting too many hits now - I've had about 300MB of bandwidth in the last 12 hours.

[ta2]

My TMPGEnc Plus guide is around the corner, and it directly opposes from of the things in the Games-Realm guide. And I get near-real-time encoding speeds. I would never hurt quality to save time, and this Games-Realm guide is unfortunately going to have that adverse effect on video if used.

My comp is only an Athlon XP 2100+ and with settings configured for top quality, It takes about 9 hours per (VBR) encode - too long for me.

thing I will say to the author of this guide, next time don't use such an incriminating source for your example.

LOL... Sorry, I know a lot of people don't like the movie... or were you refering to the quality of the source? The purpose of the guide was really from AVI to DVD, but it works for others aswell. If I was gonna go DVD(9) to DVD, then I would be using DVDShrink... loses a noticable amount of quality, but for 1 hour for the whole process, its not bad.

[lordsmurf]

I plan to thoroughly explain the Motion Search in my guide, but you won't be able to cut'n'paste from it. Just read it over when it's done, and update yours as needed. It'll appear as a new guide when I'm done with it.

Lots of misconceptions about speed, filters and quality of TMPGEnc.

Believe it or now, we are all right about the Motion Search Precision. However, many factors affect its importance and how it operates. SaSi got close to explaining some of that, and adam knows what it does. It's a pretty complex little concept.

As far as the source, I think adam is talking about the legality.

[ta2]

Nice, when d'you think your guide will be out?

What speed is your computer?

Thanks

ta2

[BJ_M]

Thanks for all your comments.

This is my first guide, and as you can see from my post count, I am a bit of a newbie.

As for your comment on I/P Frames only, there a discussion about a week ago...

https://www.videohelp.com/forum/viewtopic.php?t=178601

IPPP is a sony spec. I did note in my guide that it might not work on all players.

Anyway, about the motion search estimate, can you think of something I could say instead of what I did say. (Minimal effort here, I just want something I can cut and paste :P).

Thanks

ta2 (Games-Realm)

Also, I may need to transfer the guide to this site, since I am getting too many hits now - I've had about 300MB of bandwidth in the last 12 hours.

when i said its a sony spec -- i didnt say it was dvd ... it is a TAPE format called Sony MX ...

[lordsmurf]

Nice, when d'you think your guide will be out? What speed is your computer? Thanks ta2

Click on COMPUTER DETAILS by my name. Probably another week or so. I've got about 10 more pages to add.

[adam]

[quote="ta2"]

one thing I will say to the author of this guide, next time don't use such an incriminating source for your example.

LOL... Sorry, I know a lot of people don't like the movie... or were you refering to the quality of the source?

Incriminating as in giving away the fact that you are using an illegal source. That movie has not been commercially released yet, so you obviously have a bootleg copy.

[flaninacupboard]

My comp is only an Athlon XP 2100+ and with settings configured for top quality, It takes about 9 hours per (VBR) encode - too long for me.

Surely that's not right? on my athlon 650 i get one third realtime per pass, so a two hour movie is 12 hours. on my XP2000+ with 256Mb ram i get a smidge over real time, so 4 hours. anyway, 9 hours is exactly the right length of tme to begin before you go to bed and be done when you get up, that's what most of us home-encoders tend to do.....

[LeTrout]

Sounds about right. I get about 1-2x realtime / pass on my XP-2200 I think, never really timed it though. I have all the quality settings pretty much maxed (motion sense, DC prec, etc). I'm of the "encode once, watch forever" mindset. Spending a few extra hours once upfront is worth it compared to watching a lower quality video over and over. I suppose if I had to process like 20 hours of footage / week it might be different though.