[quote="SansGrip"]
Quote:
|
This is starting to get hairy now 8O , like the case of the chicken and the egg. Which came first :?: The CQ_VBR or the GOP size :?:
-kwag |
Quote:
-kwag |
Quote:
|
Quote:
|
Quote:
-kwag |
Quote:
|
Thinking Thinking ....... Thinking ..... :lol:
-kwag |
Got something :!:
This is what I'm doing manually, and it seems to work correctly. Start your encode with regular file size prediction. Say at CQ_VBR=25 and a GOP of 1-18-3-1-18. ( Half way between 1-36-3-1-36 ) Keep encoding as usual to target your wanted predicted file size. Then after you're done, go into TMPEG and select a 5 second range. Take something in the beginning of your 100 second window. We still haven't removed the file prediction script, so your range will be within 100 seconds. Now encode this 5 second clip. Take a look at file size. Now change your GOP and encode again. See if file size is larger or smaller, and adjust GOP up or down a couple of MAX P's accordingly. The 5 second sample clip is very fast to encode, so you can play up and down pretty fast until you find the optimal max number of frames. Now after you're done, remove the frame range in TMPEG and go back to regular file prediction once more. After one or two runs, you should have your target again, with a slightly higher CQ_VBR value, but not that high to make a difference for a new GOP calculation. Hopefully this is what needs to be automated :wink: Edit: I'm doing this right now, as I want to compare the original predicted file size with bit rate viewer, and then the new optimized mpeg. Because both file sizes will be about the same, I want to examine both mpegs to determine if the optimized mpeg has a lower Q factor meaning higher quality. Maybe not visually, but mathematically. If this is true, then we have achieved a GOP optimizing method. If the quality is the same, then CQ_VBR is playing a trick on us, and what we're doing is not worth it. -kwag |
I'm also encoding The Cannonball Run for the second time. The first one had 8 frames/GOP and this one 15. The first one is a couple of megabytes short of a full CD, let's hope that this other one is as well. Then I could check the files both visually and with Bitrate Viewer. Hopefully this will provide some extra information.
And what comes to bad compressionists, nothing can beat Future Film's remasters of Time Bandits and Monty Python's Life of Brian.. they both look more like a really bad XVCD than a DVD to me. The only good thing about them is that they were cheap. |
LOTR
Sansgrip
On the LOTR subject. I just watched the region 4 PAL Special Edition which has the movie on two discs. It looks as if it needs a bit of blockbuster to me.!!! For 2 discs it should look WAAAY better. |
Re: LOTR
Quote:
What makes me laugh is these people have over 8 gigs to play with. |
Quote:
|
Re: LOTR
Quote:
I've not looked very closely at it, but from my regular viewings with family etc. it looks pretty darn good. |
Re: LOTR
Quote:
What gets me is that I don't believe I've ever watched one of those "extras" more than once. Most of the discs I've bought, I've not even watched them at all. Very annoying. |
Quote:
|
Quote:
The tighter the GOP, the more visible artifacts on low bit rates. So the higher GOP shines on smoothing artifacts. So the 1-36-3-1-36 is good enough to provide descent quality vs. file size. The smaller file sizes with different GOPs drop the overall quality too. I noticed it on a specific scene on "Red Planet" and after playing it over and over, I finally see that the longer GOP helps A LOT. So CQ_VBR is playing tricks on us as we change the GOP size. One more thing that should be tried is to find how long can we go in the GOP before we loose quality. In the original KVCD templates, this size was 48, and it caused problems with some DVD players. The "flashing" effect. With a GOP size of 36, I don't see anyone complaining. Could we jack this up more? How much more? Or is 36 good enough for what we are getting now? -kwag |
Quote:
Quote:
|
Quote:
Quote:
-kwag |
Quote:
-Christopher |
Site design, images and content © 2002-2024 The Digital FAQ, www.digitalFAQ.com
Forum Software by vBulletin · Copyright © 2024 Jelsoft Enterprises Ltd.