|
|
With 5.1.1 I always do two pass encoding with both passes at slowest setting. Each encode takes a hell of a long time, but I want the best possible quality and since I'm only going to back up a movie one time I really don't care if it takes 24 or 30 hours.
Now I find out that in 5.2.1 they've removed the slowest speed setting and I can't find much about this change in any of the release info. Is the slow setting in 5.2.1 supposed to create quality equal to the quot;Slowestquot; in 5.1.1?
I haven't installed 5.2.1 but a friend that used it said that the slow setting is much faster than the slowest in 5.1.1, which leads me to believe the results will be of lesser quality.
Some people may find it extreme to do two passes at slowest setting with 5.1.1, but I find that produces the very best quality and I don't need to back up DVDs so frequently that I can't wait 24 or more hours for the encode to complete.
Yeah, they removed Slowest because it was incredibly slow and didn't provide much, if any, improvements over Slow.
Originally posted by obieobieobie
Yeah, they removed Slowest because it was incredibly slow and didn't provide much, if any, improvements over Slow.
I see. How shortsighted of them. Now if you want the best possible quality, even though it takes a long time, you no longer have that option. For the record, I encoded some difficult (bright, fast moving) clips at the various speeds, including 1st pass in slow or standard speed and only 2nd pass in slowest, but found that 2 passes at slowest speed was significantly better than any other speed combination.
Here's one person who won't be upgrading to 5.2.1.
Slowest mode is still possible thru the CLI...
Unofficial tweak: You can use quot;Slowestquot; mode (ala 5.1.1) by manually modifying the -pq value on the CLI to 192. However, Slow mode will give near identical results and is an officially supported/tested mode.
5.21 slow mode is not the same as 5.1x slow mode...Theoretically, we could do a whole bunch of stuff that would make the codec slower but give you better quality. We could re-introduce slowest mode. We could make more decisions RD-based. We could have full search. We could use a different block matching algorithm. We could do all of these things, and a lot more, and have the codec spend 5 days instead of 2 hours running an encoding, for as little as a 0.25db increase in PSNR.
Our codec engineers run literally hundreds of tests when they evaluate features and optimizations - Slowest mode was not removed on a whim.
@DigitAl56K: Maybe you could add an quot;ultra-slowquot; setting (warning the user it is REALLY slow) enabling all the stuff you mentioned for the quot;best possible qualityquot; freaks...
Originally posted by Sharktooth
@DigitAl56K: Maybe you could add an quot;ultra-slowquot; setting (warning the user it is REALLY slow) enabling all the stuff you mentioned for the quot;best possible qualityquot; freaks...
**profanity edited out by moderator**
Originally posted by ZZZERO
**profanity edited out by moderator**
Heh! We can certainly look into the available modes
Poll: What pq mode breakdown would be most useful to you? Give me your top 5.
Originally posted by DigitAl56K
Theoretically, we could do a whole bunch of stuff that would make the codec slower but give you better quality. We could re-introduce slowest mode. We could make more decisions RD-based. We could have full search. We could use a different block matching algorithm. We could do all of these things, and a lot more, and have the codec spend 5 days instead of 2 hours running an encoding, for as little as a 0.25db increase in PSNR.
Our codec engineers run literally hundreds of tests when they evaluate features and optimizations - Slowest mode was not removed on a whim.
Maybe not on a whim, but with no mention of its removal in the 5.2.x announcements. If you're going to make a change that involves removing a feature, it really ought to be explained and mentioned in the press release. For example, if it were the case that in 5.2.1, the slow setting has been tweaked to give better results than slow did in 5.1.1, and slow is now very close in quality to slowest in 5.1.1 but much faster then I doubt slowest would be missed. Is that the case? I have no idea because there has been no info on this from divx.
To simply remove a feature in an upgrade without mention or explanation, as if to say quot;Let's take this out and hope nobody noticesquot; is unprofessional. It reminds me of when the Diskeeper deframenting program came out with its 8.0 upgrade. The main difference in the upgrade was the removal of boot time defragmenting. (They moved that feature to the more expensive professional edition.) So, understandably, those that did the quot;upgradequot; were pissed off to find out that a key feature had been taken away from them without warning.
For the record, nobody likes it when something is taken away unless there is a very good reason or something better takes its place.
Originally posted by ZZZERO
Maybe not on a whim, but with no mention of its removal in the 5.2.x announcements. If you're going to make a change that involves removing a feature, it really ought to be explained and mentioned in the press release. For example, if it were the case that in 5.2.1, the slow setting has been tweaked to give better results than slow did in 5.1.1, and slow is now very close in quality to slowest in 5.1.1 but much faster then I doubt slowest would be missed. Is that the case? I have no idea because there has been no info on this from divx.It's in the version history:
divx/divxpro/versions/
and typing quot;Slowestquot; into our support system will return this:
cgi-bin/divx...hp?p_faqid=730
Hope that helps. |
|