View Full Version : DivX 5.1.1 officially released
DigitAl56K
20th November 2003, 04:08
DivX 5.1.1 was officially released today!
Please see this article (http://forums.divx.com/viewtopic.php?topic=55597&forum=5) with regards to just some of the many changes and links to download locations.
Thank you to everyone here at Doom9 for your contributions to the beta program leading up to this release, you can now enjoy the fruits of your labour!
-Al
SiXXGuNNZ
20th November 2003, 08:11
very nice! good work guys :D
Mole
20th November 2003, 08:50
In the changelog, does 112% faster encoding speed means:
1. From 10 fps to 11.2 fps?
2. From 10 fps to 21.2 fps?
If it's 1, then it should be changed to 12% faster encoding speed. If it's 2, then I'm truly impressed with the more than twice as fast encoding speed, which I assume is the same quality level as 5.1?
Gej
20th November 2003, 10:33
Hi,
We are talking about the speed of the DivX codec itself, it's yes, twice as fast as 5.1 in standard mode, and around 70% in slow and slowest. Yes the quality is unchanged compare to 5.1 and even improved in many case.
Now in real life encoding, when there is a source file to decode (like a MPEG2 source) the gain is not that big as the decoding part is not speed up. People that capture for instance will see a great speed increase.
Gej
Mole
20th November 2003, 13:04
Yes, I tried to capture with it. In 5.1, the speed was so slow, it was impossible to capture in real time. In 5.1.1, it has improved.
I'm using Athlon XP 2400+ and capture in 352x288 25fps.
DivX settings are:
1-pass quality mode, quantizer 1
Qpel on, GMC on, B frames off
preprocess = light, keyframe 25
The CPU usage is around 80-95%, so the CPU is barely enough to be able to capture in real time.
If I turn off Qpel, I can only capture in standard mode. Even at slow mode, the CPU is just not fast enough.
With DivX 5.05, same settings as above, the CPU usage is around 60-75%.
With such settings, is it worthwile at all to use DivX 5.1.1 instead of 5.05?
sillKotscha
20th November 2003, 13:09
Originally posted by Mole
Yes, I tried to capture with it. In 5.1, the speed was so slow, it was impossible to capture in real time. In 5.1.1, it has improved.
god, what are you doin' ??? what Gej ment was that your captured footage will see a great speed increase when you use DivX as a compressor for your (almost) uncompressed capture source!! :sly:
DigitAl56K
20th November 2003, 13:27
Standard mode in 5.1.1 is the equivelent of Slowest mode in 5.0.5
The new Slow and Slowest modes in 5.1.1 aren't comparable to any of the modes in 5.0.5. A lot of people keep making this mistake.
An Athlon XP 2400+ should be able to capture in 352x288 @ 25fps easily with 5.1.1 using Standard mode (the equivelent of the old Slowest mode). Of course, if you use QPel and Bi-directional encoding that is going to slow things down some...
For a description of all the available modes consult the user guide pages 48-54:
http://www.divx.com/support/guides/DivXGuide51.pdf
Mole
20th November 2003, 16:19
Originally posted by sillKotscha
god, what are you doin' ??? what Gej ment was that your captured footage will see a great speed increase when you use DivX as a compressor for your (almost) uncompressed capture source!! :sly:
What the hell are you talking about????:confused:
I understood perfectly what he meant.
What I was talking about is that DivX 5.1 was too slow to be able to capture at standard mode, even with Qpel off. The CPU was simply too slow.
With 5.1.1, the encoding speed has improved, so capture is now possible without dropped frames.
DigitAl56K
And I know the slow and slowest mode can't be compared to 5.05. However, these two modes are not available in 5.1.1 when using qpel.
If you read my post carefully, you'll notice that I don't use B frames.
DivX 5.1.1 352x288, 25fps is OK with XP 2400+, and the CPU usage is around 60-70%. If I turn on Qpel, it goes up to 80-95%. Windows and almost everything else slows down to a crawl while capturing.
With 5.05, I can use slowest mode, Qpel and GMC and the CPU usage would still be only 60-75%.
What would be preferable:
1. DivX 5.05, slowest mode and Qpel on
2. DivX 5.1.1 standard mode and Qpel off
Both of the choices, the CPU usage would be around 60-75%.
DivX 5.1.1 slow mode could not be used because the CPU is not fast enough.
dimzon
20th November 2003, 16:42
Originally posted by DigitAl56K
[b]Standard mode in 5.1.1 is the equivelent of Slowest mode in 5.0.5
Sorry, it's incorrect for DivX 5.1 (do not know about 5.1.1)
when 5.1 been relased i make 1 DVD-Rip with him (Forest Gamp).
I use STANDART mode B-frames ON, Qpel OFF GMC-OFF, PSY-OFF, PREPROCESSING - OFF (my standart settings for 5.0.5 slowest mode)
I view multiple artifacts after encoding on some scenes (gray box blocks on the image sometime). There are no such effect in 5.0.5 Slowest mode.
My friends try 5.1 too and there gray-block artifacts too...
Sorry for my poor english
Mole
20th November 2003, 16:56
I think that 5.1 just had too many bugs and too slow to be useful at all. Some bugs, such as the capture bug was quite serious. It should have been released as beta only.
Still, there is still problem when you install 5.1.1, then uninstall it, and re-install 5.05, it'll crash when manual registration is attempted, so still looks like not all bugs are ironed out.
First time this happened to me with 5.1, I ended up re-formating Windows. Luckily, somebody found workaround for it now by using regedit.
IMO, DivX is very useful with captures because it's preprocessing capabilities. It can do wonders with noisy antenna captures.
When it comes to DVD rips however, I still prefer XviD.
dimzon
20th November 2003, 17:07
Originally posted by Mole
When it comes to DVD rips however, I still prefer XviD.
Yes! I moved to XviD right after DivX 5.1 failure.
I use DivX 5.0.5 during 6 month before but now I'm using XviD for DVD-Rips and DivX 5.1.1 decoder to view XviD files :)
DivX team suggesion:
Please, add other MPEG4-compatible FourCC to your decoder:
3ivX
3iv2
COL1
Angel Portion Mpeg
Microsoft Mpeg 4.3 (DivX 3 before hack)
e.t.c.
I think it's easy but VERY usable :)
DivX team suggesion (2):
Please, remove DivX Player from your Bundle's. Make separate Bundle containing it. It weights 4MB and increase web-traffic...
DigitAl56K
20th November 2003, 17:48
Originally posted by Mole
Still, there is still problem when you install 5.1.1, then uninstall it, and re-install 5.05, it'll crash when manual registration is attempted, so still looks like not all bugs are ironed out.
This isn't a bug in 5.1.1, its a bug in the protection software that was used for 5.0.5, and we can hardly turn back time to fix it now :)
However we hope nobody will want to downgrade to 5.0.5 after trying 5.1.1. In any event, there are instructions in the DivX.Com FAQ forum for doing so and the BigFix pack includes an automated registry fix for downgrading.
Mole
20th November 2003, 17:48
I agree about the file size.
DivX 5.05 = 4 MB
DivX 5.1.1 = 6 MB
I quit DivX since 5.02. Maybe I'll try it again if they enable multiply b frames.
Mole
20th November 2003, 18:16
Well, for people who use DivX for captures, 5.05 is still better.
5.1 was useless, both because of speed and the bug.
5.1.1 is faster, but still too slow. I just recently upgraded the capture box from XP 1800 to 2400 which is barely fast enough. With 1800, I wonder if standard mode without Qpel is even possible.
I capture the audio as uncompressed wav.
But if I was using it for DVD rips, there would probably be no reason to go back to the older version.
DigitAl56K
20th November 2003, 18:54
I don't know where you are getting this idea that 5.0.5 is better than 5.1.1 for capture, unless you are using something other than Slowest mode in 5.0.5.
Sharktooth
20th November 2003, 19:13
How about creating a "capture mode" for the DivX encoder?
I mean, adding a "capture setting" (expecially optimized for usual capture resolutions that will use less CPU time) to the already available fast/normal/slow/slowest.
Mole
20th November 2003, 19:46
It is "better" in the sense that it's faster.
For people with a slower CPU 5.1.1 is just not fast enough.
For instance, I can capture with 5.05 in slowest mode + Qpel.
But in 5.1.1, normal mode + Qpel is not possible.
I can disable Qpel in 5.1.1, but I think the quality with 5.1.1 no Qpel, is still lower than 5.05 + Qpel.
There is no "optimum capture settings" simply because people capture in a variety of resolutions and the source can vary from very clean to noisy.
RadicalEd
20th November 2003, 22:06
Uh
Is performance/quality supposed to be locked at standard for multipass and only have fastest/standard as an option for single pass?
Mole
20th November 2003, 22:16
RadicalEd, I'm not sure what you mean, but if Quarter Pixel is enabled, then the slider will be locked at standard.
SeeMoreDigital
20th November 2003, 23:29
I have a special request to the guys at DivX.
Please bring back the the MP4 container capability that was dumped after DivX 5.0.2!
With it you could offer 16:9 AR flagging and bring the codec right up to date facilities wise!
I appreciate that being able to generate and combine an AAC audio stream within an MP4 container (at the same time as creating the DivX video stream) may not be an available option at the moment. However, good old Mp3 audio is!
I'm not saying dump AVI. Just please give us the option!
Many thanks
b00zed
21st November 2003, 01:03
From changelog:
"Smoother DivX logo fade."
I don't know how I ever survived without it! :P
However I was pretty happy with the improvement the 5.11 beta versions made over 5.1, so it's good to see it gold finally, that's nice work.
cjaar
27th November 2003, 09:42
Originally posted by Mole
Still, there is still problem when you install 5.1.1, then uninstall it, and re-install 5.05, it'll crash when manual registration is attempted, so still looks like not all bugs are ironed out.
First time this happened to me with 5.1, I ended up re-formating Windows. Luckily, somebody found workaround for it now by using regedit.
can i know the regedit trick!!! i 2 hd the same prob and hd to reinstall windows!!!
thx i got it on divx faq web!!!!
thx
cjaar
Soulhunter
30th November 2003, 00:25
Still no option to write a analyze log... !?! :(
Bye
Jeffster
30th November 2003, 11:00
Originally posted by Soulhunter
Still no option to write a analyze log... !?! :(
Bye
You can create an empty text file in the root of C Drive and name it "FrameLevelControl.txt"
After encoding it will contain information about that pass, scroll to the bottom for quantizer distribution etc.
Is that what you mean?
Jeff
Soulhunter
1st December 2003, 18:27
@Jeffster
You can create an empty text file in the root of C Drive and name it "FrameLevelControl.txt"
After encoding it will contain information about that pass, scroll to the bottom for quantizer distribution etc.
Is that what you mean?
I don't know... !?! But here is my request from the DivX 5.1.1 Beta thread !!!
While using this new DivX versions, I have some feature requests...
1.
Could DivX write some sort of "analyze" log-file ???
This would save up all info you can see in the feedback window...
Like the min/max/avg of Bitrate, Quants and PSNR !!!
Maybe the percentage of I,P,B frames and all other info too ?!?
2.
Why is the video preview in the feedback window not resize able ???
Its disturbing when you work with high res. video...
Because you cant reach the bottom of the feedback window then !!!
A preview resize function like in VDub would be useful...
Like 25%, 50%, 75%, 100%, 125%, 150%, 175%, 200% !!!
Anyhow, THX for the info !!! ;)
Bye
Angelus
1st December 2003, 19:12
This is related to Divx 5.1.1. I just did a couple dvd encodes the past couple days and I noticed something strange. When I use GKnot for a 2-pass encode, 1st pass being standard and second pass being slow, I notices that the speed (fps) are almost exactly the same. I thought that this was supposed to be noticeably slower? When I've used the same divx version for my capture encodes, I usually see a 50% decrease in speed from "standard" to "slow" modes. Here's an exerpt from my GKnot log file:
4:51:36 PM: Started DivX5-First Pass: D:\Tony\DVD\Bruce Almighty\Bruce Almighty.avs
6:35:33 PM: Finished DivX5-First Pass: Duration: 1 hour, 43 minutes, 56 seconds.
6:35:33 PM: Trying to open Log-file.
6:35:34 PM: Success: Log-file open.
6:35:34 PM: Encoded: 137317 Frames.
6:35:34 PM: Speed: 22.017 Frames per Second.
6:35:34 PM: Started DivX5 - Pass: 2: D:\Tony\DVD\Bruce Almighty\Bruce Almighty.avs
8:18:11 PM: Finished DivX5 - Pass: 2: Duration: 1 hour, 42 minutes, 36 seconds.
8:18:11 PM: Speed: 22.303 Frames per Second.
Any idea why it is doing this?
JensG.
1st December 2003, 22:42
Perhaps you activated QPel?
Angelus
1st December 2003, 23:00
nope qpel isn't activated. It's weird but I just did a sample run doing the enocde manually in VDM and after a couple frames of the first pass cancelled it and then started the second pass and now I was getting 7-8 fps...instead of the 20 fps I was getting when doing it thru GKnot. Maybe i'll try uninstalling then reinstalling GK and see if that works.
b00zed
2nd December 2003, 02:06
Are you sure GK's internal .firstpass and .secondpass settings reflect what you say they are?
Angelus
2nd December 2003, 02:31
They should...I set the codec settings to standard for the first pass and slow for the second pass, so I don't see why it would be any different. I will be doing the encode over tonite after an uninstall and reinstall of Gk. I'll post my findings in the morning.
I should note however that b4 I uninstalled and when I tried to do a comp. test using the "slow" speed, the speed was 7-8 fps. So it's weird that it looks like it works during the comp. test but during the actualy encoding it doesn't do it. If it doesn't work, i'll try uninstalling and reinstalling DivX afterwards. :D Hey, sometimes it works wonders!
And if you like, I can post the .firstpass settings and .secondpass settings files, but it looks like a lot of jibberish to me.
Angelus
2nd December 2003, 17:22
After uninstalling and reinstalling GK and doing an encode overnight, the speed settings seem to be working properly now: 21 fps first pass, 8.5 second pass.
len0x
2nd December 2003, 17:23
What you're looking is key "Quality" in the *.setting file.
Value 5 is normal speed. 0x40 (64 decimal) is slower mode.
*Edit*
Always delete *.settings from GK root folder after codec upgrade btw.
(and reselect defaults on option tab)
Soulhunter
4th December 2003, 18:53
Short DivX Pro 5.1.1 test...
Source:
The Matrix - Lobby Shootout / 3:07 min. @ 25fps / 720x400 pix. (Lanczos)
Results:
Quantizer2 / No B-Frames / No PVE / Slowest
Size: 073.848.832 Bytes / Avg. PSNR: 45.51 / Overall PSNR: 45.31
Quantizer2 / No B-Frames / No PVE / Slow
Size: 073.959.424 Bytes / Avg. PSNR: 45.50 / Overall PSNR: 45.30
Quantizer2 / No B-Frames / No PVE / Standard
Size: 070.029.312 Bytes / Avg. PSNR: 45.04 / Overall PSNR: 44.88
Quantizer2 / No B-Frames / Fast PVE / Slowest
Size: 097.114.112 Bytes / Avg. PSNR: 46.18 / Overall PSNR: 45.97
Quantizer2 / No B-Frames / Fast PVE / Slow
Size: 097.513.472 Bytes / Avg. PSNR: 46.18 / Overall PSNR: 45.97
Quantizer2 / No B-Frames / Fast PVE / Standard
Size: 090.609.664 Bytes / Avg. PSNR: 45.82 / Overall PSNR: 45.65
Quantizer2 / No B-Frames / Slow PVE / Slowest
Size: 119.869.440 Bytes / Avg. PSNR: 45.11 / Overall PSNR: 44.92
Quantizer2 / No B-Frames / Slow PVE / Slow
Size: 119.967.744 Bytes / Avg. PSNR: 45.11 / Overall PSNR: 44.91
Quantizer2 / No B-Frames / Slow PVE / Standard
Size: 102.141.952 Bytes / Avg. PSNR: 45.09 / Overall PSNR: 44.88
Note:
The "FrameLevelControl.txt" seems to give wrong PSNR info when you use B-Frames... :eek:
SeeMoreDigital
4th December 2003, 19:12
Hi Soulhunter,
720x400 is a strange frame size for a 2.35:1 source!
Did you crop off part or all the matte away?
Cheers
Soulhunter
4th December 2003, 19:52
Hi S.M.D. !!!
Hi Soulhunter,
720x400 is a strange frame size for a 2.35:1 source!
Uhm, I remember this dialogue... :rolleyes:
Oh yeah, the 5.1.1 Beta Reloaded test encodes (http://forum.doom9.org/showthread.php?s=&threadid=63690&perpage=20&pagenumber=4) !!!
Must be a error in the matrix, because there is a modification... :D
Did you crop off part or all the matte away?
No, kept all matte and did only 16:9 (1.8) resize with mod16 (AE of 1.3%) !!!
Not what I would use to encode this movie, only a quick test... ;)
PS:
Has Matrix a AR of 2.35 or like Reloaded a real AR of 2.40 ???
Because 16:9 resizing and cropping matte gives me again a AR of 2.5 !!!
I feel it again, something is changing in the marix... :D
Bye
SeeMoreDigital
4th December 2003, 20:14
Originally posted by Soulhunter
Has Matrix a AR of 2.35 or like Reloaded a real AR of 2.40 ???
Because 16:9 resizing and cropping matte gives me again a AR of 2.5 !!!t would appear that the PAL version of the Matrix is 2.35:1. And the PAL version of Matrix Reloaded is 2.40:1
You could have a go at generating an anamorphicly cropped encode. If you did this, you could use a frame size of 720x432. For both 2.35:1 and 2.40:1 sources.
Cheers
Soulhunter
4th December 2003, 20:21
Ok, maybe this is a bit offtopic now...
But can normal DVD players show/recent other AR's than 4:3 & 16:9 ???
Bye
jggimi
4th December 2003, 21:55
As far as I know, Soulhunter, the only valid DARs are the size of television screens, 4:3 (Standard) and 16:9 (Newfangled). The content will contain letterboxing to return the content to the original AR, regardless of DAR value.
And yes, it's off topic.:rolleyes:
TotalChaos
5th December 2003, 08:18
I'm not sure if I even know what I am talking about, but I have been ripping and compressing DVD videos into DivX since v4.11. Through out this time I've only used the latest gordian knot and the acompanying codec pack or latest divx codec. As any who compress full movies knows the proccess takes a long time. As a being of NO patience I created and finaly finished my latest toy. I used a P4C 3.0GHz with HT and over clocked it a tad to 3.25GHz 868FSB. It would seem to me sufficient to kill these long compression times. With the DivX 5.05 and gordian knot I could compress a full length movie doing two passes at 900Kbps in about 1-hour 45-minutes. Now with this new POS (Divx 5.1) My encode times are like 6+ hours. I'm useing the EXACT same set up as I always have, and YES I did use the slowest setting for DivX 5.05 and am now using the standard setting for this new DivX 5.1. Can anyone tell me WHY this thing is so slow. I have ZERO patience for this!!!
JohnMK
5th December 2003, 09:17
Did you bother reading the first post of this thread? DivX 5.1.1? 5.1? Spot the difference there . . . oh, and welcome to doom9. :D There is a search function to your avail, use it!
Fr4nz
5th December 2003, 11:33
Hello folks! I've encoded the 25th hour, but I've noticed this strange bug in the encoded video:
http://users.libero.it/i3ltt/Cazzate%20varie/Image1.jpg
Another image is this:
http://users.libero.it/i3ltt/Cazzate%20varie/Image1.jpg
As you can see there are some macroblocking on vertical lines (these strange effect occurs only sometimes and generally when these vertical lines are bright, dunno why).
When you see the film in motion, you can clearly observe that these squares goes up and down the vertical lines, and this is very annoying.
The overall quality of the film is excellent if we don't consider this strange effect.
The options I've used are: 2-passes, bitrate 1330kbps, bitrate modulation 0.02, update log file, profiles disabled, b-frames, max keyframe interval 300 (maybe I have to change this to 250 because the film is PAL??).
Thanks for any help!
dimzon
5th December 2003, 11:40
try last FFDShow to decode your movie - maybe it's decoder bug
i view such macroblocks when use 5.1.1 final decoder to decode XviD movies:
http://forum.doom9.org/showthread.php?s=&threadid=64075&perpage=20&pagenumber=2
Sorry for my poor english
Fr4nz
5th December 2003, 12:01
Probably you're right, when I play the movie on my kiss 450 this macroblocking doesn't occur.
dimzon
5th December 2003, 12:19
Originally posted by Fr4nz
Probably you're right, when I play the movie on my kiss 450 this macroblocking doesn't occur.
there maybe 2 solution's
1) use FFDShow to decode your DivX content or
2) use divxdec.ax from 5.1.1 beta 1 package
Fr4nz
5th December 2003, 13:38
Yes yes yes, luckily it's only a decoder-bug, so it's not a big problem.
acrespo
5th December 2003, 18:12
Originally posted by DigitAl56K
I don't know where you are getting this idea that 5.0.5 is better than 5.1.1 for capture, unless you are using something other than Slowest mode in 5.0.5.
I am using iuVCR for captures. I can capture only with Fastest mode. Standard mode hangs iuVCR and I want to end the process with Task Manager.
My computer is Athlon XP 1800, Winxp PRO SP1, 1Gb RAM
Fastest mode use 80% CPU in 352x480 resolution.
Soulhunter
6th December 2003, 19:23
@jggimi
As far as I know, Soulhunter, the only valid DARs are the size of television screens, 4:3 (Standard) and 16:9 (Newfangled). The content will contain letterboxing to return the content to the original AR, regardless of DAR value.
And yes, it's off topic.
Sorry mate... ;)
But this means all content that is not 4:3 must be 16:9...
Right... ???
So when I resize it to 16:9 and then crop the matte, I should still have the right AR...
Right... ???
So has "Matrix" and "Matrix Reloaded" a real AR of 2.5 then... ???
Got the same confusion with other movies... :confused:
Back to the topic now... ;)
Has someone else noticed that the "FrameLevelControl.txt" gives strange info about PSNR when using B-frames... ???
Even with Quant2 encodes, I cant get better results than 30... :eek:
Any idears ???
Bye
jggimi
6th December 2003, 19:58
The "Official DVD FAQ" agrees with my DAR recollection:
http://www.dvddemystified.com/dvdfaq.html#3.5
There is a discussion of pixel shape near the end, with additional links, as well.
When resizing for encoding, you will rarely, if ever, reach the exact aspect ratio, since you resize to a limited set of resolutions. Gknot, for example, defaults to resolutions divisible by 16/32.
SeeMoreDigital
6th December 2003, 21:33
>Soulhunter,
What goal do you want to achieve with your encode?
Do you want to fit it on to an CD-R?
Do you want to crop only?
Do you want to crop and resize?
Do you require an anamorphic encode?
Do you require your encodes to be at the correct aspect ratio when you open it?
Are you viewing your encode on a TV via DivX standalone player?
Are you viewing your encode solely on an PC monitor?
As I may have mentioned earlier, if you want to generate encodes that preserve all the vertical pixels of the original PAL DVD source. Then for an 2.35:1 AR movie, you require 436 vertical pixels (432 to the nearest 16th pixel). And for an 2.40:1 AR movie, you will require 427 vertical pixels (which is again 432 to the nearest pixel).
For all the newbies out there who may be reading this, there's no real need to get confused about 'film transfer' aspect ratios or how anamorphic film camera lenses work. All you need to understand is how the image is stored on the DVD.
For example PAL DVD's marked as 'widescreen' whether they are 1.77:1, 1.85:1, 2.00:1, 2.35:1 or 2.40:1, all contain 720x576 (414,720 in total) pixels. And are 'laid over' an anamorphic 16:9 (1.77:1) frame background.
However, as soon as the aspect ratio of the movie becomes greater than 1.77:1, black bands (also known as mattes) will appear above and below the image. Meaning, as the aspect ratio increases the quantity of vertical image pixels decreases but are replaced by vertical matte pixels!
The horizontal (width) quantity of pixels will always remain the same, because the image is stored on the DVD anamorphically or 'squashed up'!
In the case of an PAL DVD they are 'squashed up' at a ratio of 1.25:1. For a NTSC DVD they are 'squashed up' at a ratio of 1.50:1. Which I know, confuses matters even more but that's why they are known as anamorphic 16:9 (1.77:1) frame DVD's and not true 16:9 (1.77:1) frame DVD's!
If you decide to say, encode an anamorphic 2.35:1 PAL DVD to an image pixel frame size of 640x272 by cropping away the mattes and resizing the image. The image will no longer be an anamorphic frame size, it's now a true frame size. And as a result will look normal when viewed. 640 divided by 272 = 2.35:1
Other true frame sizes are of course possible, however care must be taken that they are increased in blocks of 16. However, when you generate encodes with more pixels, it's usual to assume that more bitrate will be required also!
Hope this helps to all those that can be bothered to read it?
Cheers
Soulhunter
6th December 2003, 22:25
What goal do you want to achieve with your encode?
Overall said, quality counts more than file size for me !!!
Do you want to fit it on to an CD-R?
Usually 3-4 CD-R's or 1/2 DVD-R !!!
Do you want to crop only?
No...
Do you want to crop and resize?
Yes, 90% Ill do so...
Do you require an anamorphic encode?
Not till AR flags work in AVI container !!! Or maybe later with MP4... ;)
Do you require your encodes to be at the correct aspect ratio when you open it?
Yes, I'm to lazy to config the AR manually, every time I open a Video... :D
Are you viewing your encode on a TV via DivX standalone player?
No, till now I use my gaming PC for playback... But I'm looking froward to build my own HTPC next year !!!
Are you viewing your encode solely on an PC monitor?
Monitor at night with my headphones, because I don't wanna get trouble with my neighbours... ;)
And at day on TV with my 3 x 2.0 + 1 x 2.1 speaker setup !!! :D :D :D
For the other stuff... THX for all this info !!!
PS:
What do you think of holding the vertical resolution and increasing the horizontal resolution... Like 1024x576 for a anamorphic 16:9 PAL movie ???
Bye
SeeMoreDigital
6th December 2003, 23:32
Originally posted by Soulhunter
Overall said, quality counts more than file size for me !!!
Usually 3-4 CD-R's or 1/2 DVD-R !!!
No, till now I use my gaming PC for playback... But I'm looking froward to build my own HTPC next year !!!
Monitor at night with my headphones, because I don't wanna get trouble with my neighbours... ;)
And at day on TV with my 3 x 2.0 + 1 x 2.1 speaker setup !!! :D :D :D
For the other stuff... THX for all this info !!!
PS:
What do you think of holding the vertical resolution and increasing the horizontal resolution... Like 1024x576 for a anamorphic 16:9 PAL movie ???
Bye OK then!
For starters, your in luck. As a PAL DVD user if you decided to generate encodes using a true 16:9 frame size of 1024x576, your encodes will work fine in any PC software media player.
The bad news is, if you later decide to purchase a stand alone DVD/Mpeg4 player and burn your encodes to CD-R or DVD R/RW, they won't work. This is because the total quantity of pixels exceeds 414,720. And no hardware player chipsets support this.... at the moment!
So whats left. Given that you've got around 2100MB (3No CD R's or just less than half a DVD R) to play with. You can use high bitrates, to obtain good quality.
Personally, I would keep my encode frame size as the original frame size (eg 720x576). Which I know is anamorphic but there is a very easy way to get most of your software media players to open your anamorphic encodes at the correct 16:9 aspect ratio!
All you need to do is visit DivX Config / Quality Settings and set the Aspect Ratio to 16:9... And presto chango, they look as they should!
The main thing to bare in mind is that as soon as you elect to resize an image, quality suffers!
Cheers
Soulhunter
14th December 2003, 13:46
Seems to be Sunday again... ;)
Source:
The Matrix - Lobby Shootout / 3:07 min. @ 25fps / 1024x576 pix. (Lanczos)
Results:
Quantizer2 / No B-Frames / No QP / No PVE / Standard
Size: 122.812.416 Bytes / Avg. PSNR: 45.98 / Time: About 4:20 min. (2600XP)
Quantizer2 / No B-Frames / No QP / Fast PVE / Standard
Size: 158.230.528 Bytes / Avg. PSNR: 46.86 / Time: About 5:30 min. (2600XP)
Quantizer2 / No B-Frames / No QP / Slow PVE / Standard
Size: 182.900.736 Bytes / Avg. PSNR: 46.23 / Time: About 7:30 min. (2600XP)
Quantizer2 / No B-Frames / QP / No PVE / Standard
Size: 128.841.728 Bytes / Avg. PSNR: 45.42 / Time: About 14:10 min. (2600XP)
Quantizer2 / No B-Frames / QP / Fast PVE / Standard
Size: 170.446.848 Bytes / Avg. PSNR: 46.23 / Time: About 15:30 min. (2600XP)
Quantizer2 / No B-Frames / QP / Slow PVE / Standard
Size: 206.211.072 Bytes / Avg. PSNR: 45.66 / Time: About 17:30 min. (2600XP)
Quantizer2 / No B-Frames / No QP / No PVE / Slowest
Size: 133.623.808 Bytes / Avg. PSNR: 46.68 / Time: About 29:40 min. (2600XP)
Quantizer2 / No B-Frames / No QP / Fast PVE / Slowest
Size: 173.719.552 Bytes / Avg. PSNR: 47.42 / Time: About 30:13 min. (2600XP)
Quantizer2 / No B-Frames / No QP / Slow PVE / Slowest
Size: 216.211.456 Bytes / Avg. PSNR: 46.29 / Time: About 30:18 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / No PVE / Standard
2nd Pass: Size: 58.718.208 Bytes / Avg. PSNR: 43.28 / Time: About 04:02 min. (2600XP)
3rd Pass: Size: 58.677.248 Bytes / Avg. PSNR: 43.29 / Time: About 04:11 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / Fast PVE / Standard
2nd Pass: Size: 58.673.152 Bytes / Avg. PSNR: 43.03 / Time: About 04:57 min. (2600XP)
3rd Pass: Size: 58.681.344 Bytes / Avg. PSNR: 43.04 / Time: About 05:02 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / Slow PVE / Standard
2nd Pass: Size: 58.742.784 Bytes / Avg. PSNR: 42.74 / Time: About 07:19 min. (2600XP)
3rd Pass: Size: 58.667.008 Bytes / Avg. PSNR: 42.74 / Time: About 07:26 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / QP / No PVE / Standard
2nd Pass: Size: 58.679.296 Bytes / Avg. PSNR: 42.76 / Time: About 14:13 min. (2600XP)
3rd Pass: Size: 58.703.872 Bytes / Avg. PSNR: 42.76 / Time: About 14:17 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / QP / Fast PVE / Standard
2nd Pass: Size: 58.726.400 Bytes / Avg. PSNR: 42.39 / Time: About 14:49 min. (2600XP)
3rd Pass: Size: 58.679.296 Bytes / Avg. PSNR: 42.39 / Time: About 14:52 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / QP / Slow PVE / Standard
2nd Pass: Size: 58.728.448 Bytes / Avg. PSNR: 42.12 / Time: About 16:27 min. (2600XP)
3rd Pass: Size: 58.710.016 Bytes / Avg. PSNR: 42.12 / Time: About 16:28 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / No PVE / Slowest
2nd Pass: Size: 58.673.152 Bytes / Avg. PSNR: 43.60 / Time: About 28:43 min. (2600XP)
3rd Pass: Size: 58.697.728 Bytes / Avg. PSNR: 43.61 / Time: About 28:45 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / Fast PVE / Slowest
2nd Pass: Size: 58.744.832 Bytes / Avg. PSNR: 43.15 / Time: About 28:48 min. (2600XP)
3rd Pass: Size: 58.679.296 Bytes / Avg. PSNR: 43.17 / Time: About 28:49 min. (2600XP)
MultiPass @2500 kbps / No B-Frames / No QP / Slow PVE / Slowest
2nd Pass: Size: 58.730.496 Bytes / Avg. PSNR: 42.98 / Time: About 30:59 min. (2600XP)
3rd Pass: Size: 58.740.736 Bytes / Avg. PSNR: 42.99 / Time: About 31:00 min. (2600XP)
@S.M.D.
Any progress with your T2 encode... Or does Recode2 eat up all your free time ??? :D
Bye
SeeMoreDigital
14th December 2003, 14:00
Eeeek!
Thanks for the nudge Soulhunter. I've just started the ripping process on my other PC now!
Cheers
SeeMoreDigital
14th December 2003, 23:39
Well the NTSC anamorphic DivX encode of T2 @ 2700kbps looks great. But it should do at 3.00GB!
Cheers
Soulhunter
15th December 2003, 00:09
Well the NTSC anamorphic DivX encode of T2 @ 2700kbps looks great. But it should do at 3.00GB!
Good to hear...
Maybe Ill try a 1024* encode with my T2 UE PAL version to 1x DVD-R next week !!! :D
PS: Could you give some info (DivX settings and Avg. Quant/PSNR) about your encode ???
Bye
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.