View Full Version : Output resolution 1920 x 1080?
pidhead
26th March 2004, 10:44
I am trying to use GK to encode HDTV movies to divx. I think the source is 1080i, but not sure. I would be happy with output files anywhere in the 2G - 4G range.
I realize that GK is optimised for DVD encoding, but is it possible to output to a higher resolution than 800 x 384? That seems to be about as high as it will go with the slider all the way over.
Any hints? Thanks.
manono
26th March 2004, 13:50
Hi, and welcome to the forum.
You can choose any resolution you wish, but only by editing the .avs, either at the time it's created, by using the Edit button, or later on, after you've saved it. Just go and find the resize line and change the numbers inside there.
piscator
29th March 2004, 00:47
Originally posted by pidhead
I am trying to use GK to encode HDTV movies to divx. I think the source is 1080i, but not sure. I would be happy with output files anywhere in the 2G - 4G range.
Any hints? Thanks.
Note that the 2G-4G range is not so easy to achieve with such resolutions. 1920 by 1080 has almost 7 times more pixels than the 'standard' encodes of 640 by 480. Taking a filesize of 700MB for medium quality for movies, you would get around a file of 4.9GB. If I remember correctly, files larger than 4GB are not possible with GKnot/VDub/DivX/XviD or the filesystem.
greetz,
Piscator
pidhead
30th March 2004, 06:30
Thanks for the input. My test encode is still running and looks like it will be done in another day or so. Time to upgrade the encoder pc I guess...
I'm doing some calculations to see what bitrate / filesize I am looking at for various output resolutions. With the bits/(pxl*frame) formula, am I aiming for a number between .30 and .17?
So, for instance, my source is 23.976 Fps, 1920x1080. Does that mean, if I want a .30 ratio, I would be looking at almost 15 Mbps? (.30 x 23.976 x 1920 x 1080)
Am I thinking about this right? Where does the Divx compression help me out here? The source is around 15-18 Mbps Mpeg-2, so I was hoping Divx at the same resolution would be significantly lower bitrate.
Thanks.
Soulhunter
30th March 2004, 18:25
Originally posted by piscator
Note that the 2G-4G range is not so easy to achieve with such resolutions. 1920 by 1080 has almost 7 times more pixels than the 'standard' encodes of 640 by 480. Taking a filesize of 700MB for medium quality for movies, you would get around a file of 4.9GB.True, but higher resolution means also smaller blocks... ;)
Originally posted by piscator
If I remember correctly, files larger than 4GB are not possible with GKnot/VDub/DivX/XviD or the filesystem. Maybe this is OS related... I can encode n' play even 10GB files on WinXP !!!
Originally posted by pidhead
Where does the DivX compression help me out here? The source is around 15-18 Mbps MPEG-2, so I was hoping DivX at the same resolution would be significantly lower bitrate.Assume so (guess 10-12 Mbps), but playback should be choppy anyway... ;)
Bye
piscator
30th March 2004, 21:20
Originally posted by pidhead
I'm doing some calculations to see what bitrate / filesize I am looking at for various output resolutions. With the bits/(pxl*frame) formula, am I aiming for a number between .30 and .17?
So, for instance, my source is 23.976 Fps, 1920x1080. Does that mean, if I want a .30 ratio, I would be looking at almost 15 Mbps? (.30 x 23.976 x 1920 x 1080)
Your calculation is correct. But how did you determine the .30 number? I guess it could well be that the source already has less bits/(pxl*frame) (in which case you would get an undersized file and a final result smaller than 15 Mbps).
So do a comp. check to determine max bits/(pxl*frame) for the source (with manually updated resolution in the AVS file). Take 80% of that to encode your source and my guess is that it should be at least 2 to 3 times better than 15Mbps.
To make a comparison. An encoded movie at 640 by 480 having a bitrate of 1Mbps is usually quite good. Since 1920 by 1080 has almost 7 times more pixels, a bitrate of 7Mbps at that resolution should be easy achievable. Anyway, let us know your results. I'm curious.
Originally posted by Soulhunter
True, but higher resolution means also smaller blocks... ;)
What do you mean by smaller blocks and why would higher resolutions relatively give more advantage? I'm under the assumption that the result is quite linear with the amount of pixels.
Originally posted by Soulhunter
Maybe this is OS related... I can encode n' play even 10GB files on WinXP !!!
True with NTFS there is no 4GB restriction. But I thought that the tools used 32-bit addressing, which makes 2^32=4GB limit. But anyway, it's nice to know that limit is not there anymore.
greetz,
Piscator
Soulhunter
30th March 2004, 21:44
Originally posted by piscator
What do you mean by smaller blocks and why would higher resolutions relatively give more advantage? I'm under the assumption that the result is quite linear with the amount of pixels.Lets assume a 512* source gets fullscreen resized (lets say to 1024*) that would doubles the frame-size but the block size as well (bigger blocks) !!!
Now a 1920* source gets fullscreen resized (also 1024*), that would "closely" half the frame-size and therefore also half the block size (smaller blocks) !!!
Hope this makes sense... :)
Originally posted by piscator
True with NTFS there is no 4GB restriction. But I thought that the tools used 32-bit addressing, which makes 2^32=4GB limit. But anyway, it's nice to know that limit is not there anymore.Can only say it works for VDubMod + XviD n' DivX... ;)
Bye
pidhead
31st March 2004, 08:03
Originally posted by piscator
Your calculation is correct. But how did you determine the .30 number? I guess it could well be that the source already has less bits/(pxl*frame) (in which case you would get an undersized file and a final result smaller than 15 Mbps).
Thanks Piscator,
I got the .30 number from this guide:
http://www.divx-digest.com/articles/dvd2divx5_gordianknot.html
it is in step 11. Maybe I don't understand the details though.
Originally posted by piscator
So do a comp. check to determine max bits/(pxl*frame) for the source (with manually updated resolution in the AVS file). Take 80% of that to encode your source and my guess is that it should be at least 2 to 3 times better than 15Mbps.
To make a comparison. An encoded movie at 640 by 480 having a bitrate of 1Mbps is usually quite good. Since 1920 by 1080 has almost 7 times more pixels, a bitrate of 7Mbps at that resolution should be easy achievable. Anyway, let us know your results. I'm curious.
Ok, I have a 2min45 sec clip I am going to test on. I did a compression test, hit the edit button, changed LanczosResize(800,368) to LanczosResize(1920,1080)
Results were:
Bits/(Pixel*frame)
[1.016] [ ]%of[ ] First pass stats
[Load]->[39.8]%of[2.552] Compress Test
the 39.8 has a red background.
What does this tell me? I did this test with the bitrate set to 7000 Kbps, is that the rate the compression test was run at?
I changed the bitrate to 14 Mbps, which raises the 39.8 number to 79. I'll encode and see what that looks like. This clip is a trailer for Underworld, so it is high motion -- maybe that makes this a bad segment to test on?
I'm starting to think that this is not going to work like I'd hoped. I was hoping to keep HD resolution, and just get better compression, but 14 Mbps doesn't cut down file size much, and I'm not sure my Xbox or PC can play that anyway. Worth a try I guess.
Thanks.
piscator
4th April 2004, 13:01
Ah, well that guide you read is not so accurate. Try the guides on this forum ;-)
The 'Bits/(Pixel*frame)' depends on the source. Read this (http://forum.doom9.org/showthread.php?s=&threadid=72818) and this (http://forum.doom9.org/showthread.php?s=&threadid=73141) for what those numbers mean and the relation to the percentage (1.016 / 2.552 = 0.398)
Anyway the numbers you get are unrealistic. Probably because it's auto-corrected for the current resolution in your gknot settings. Bypassing that is quite simple. After the comp. check, use the load button to directly load the comp. check results. It's in your gnot directory and has the name "vdenc.log".
Furthermore, check your comp. check settings. You are definately not supposed to do this at a fixed bitrate (perhaps this is also the problem with your numbers). It should always be done at a fixed quantizer 2. Futhermore, set the advanced options the same as your 1 and 2 pass settings, except always disable psyvis for the comp. check (gives inaccurate results).
Another pointer. You did encode the clip with 2-pass and not at a fixed bitrate, right? Make sure to enable B-frames since it saves space. My further personal preferences are to enable GMC, psyvis=fast but no Q-pel. If you do that, you should see the following settings in the CLI options:
First pass (multipass 1st-pass, standard, write log, use MV, PsyVis Fast, GMC, bidirectional encoding)
-bvn1 XXX -psy 2 -key 300 -log "XXX" -mv "XXX" -b -g -sc 50 -pq 5 -profile 0 -nf
Last pass (multipass nth-pass, slowest, write log, PsyVis Fast, GMC, bidirectional encoding)
-bvnn XXX -psy 2 -key 300 -log "XXX" -w -b -g -pq 192 -vbv 100000000,3145728,2359296 -profile 0 -nf
I also have an Xbox, but I guess that 14Mbps is way too much for the XBox to playback. Anyway, that's kind of useless since the xbox can't playback a 1900 by 1080 movie anyway (it's certainly rescaled. max is 720 by 520 for PAL, the DVD standard).
greetz,
Piscator
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.