• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

DivX encoding TIPS

Page 3 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
wow this thread took off!

I've downloaded a few Star Trek episodes (yeah I know, DVD isn't the source). the largest size for one was 184 megs, and it was 44 minutes long. it is 384X274 resolution. that translates into only about 4 megs a minute. or 0.558 megabits a second.

I gotta say, the quality is CRAP, but would look almost normal on TV if I decoded it to AVI and played it through my Hollywood + (perfect TV signal).

I have DVD's on my computer (DVDROM), and I can't get over how sweet it is vs the TV quality.. I'd like to see what DivX can do, however I suspect that DivX was built with low bitrate in mind, thus it might not be very good at higher bitrates (like your 2000kbit/second rates).

just to show, you have to remember that DVD also has the full 5.1 channel sound capabilities..

of course, if I had enough CPU time, and a nice fat pipe to the net (I'm currently on a 56k), I would do a comparison myself, checking out all the different settings etc..
 
guys,
how many different divx encore software are there
i find many but the only one that work is flashmpeg
the rest, just bring out the ms dos window and then do nothing or just do nothing.
 
GL,

When using mpeg2avi, try not to use the 32-bit MMX iDCT (-r1). Instead, use the -r2 option (16-bit MMX Chen iDCT). The 32-bit MMX iDCT is buggy, *still* in the latest and PX3-optimized versions. It adds macroblocks to certain scenes, that won't be there if you use the 16-bit Chen iDCT.

Also, the different color modes have an impact on speed. -o8 should be the fastest, followed by -o9 and then -o7. However, certain people's Window's installations become "damaged" and only -o7 works, so you'll have to live with that. Quality difference between the 3 modes is indiscernible. There shouldn't be any, really.

Also, if you resize using an encoder other than mpeg2avi, use Bilinear resizing. Bicubic tends to introduce anti-aliasing where there are jaggies - but this is BAD because the MPEG4 encoder smooths jaggies out on it's own, and functions best with a "pure" image, such as that delivered by a Bilinear resizing algorithm. And yes, your point about downsizing is very important. The smaller the frame size, the less pixels there are (640x272 = 174k pixels, as opposed to 720x480 = 345k) so the easier it is on the MPEG4 encoder.

640x272 is a good resolution for 2.35:1 movies, and I find 512x272 is good for 1.85:1 movies.
 
Hmm i'd use mpg2avi but i got video/sound sync problems using that🙁 Havn't touched it for a long time, just noticed that flask was easy😛

Soccerman,

Don't forget bonus features/separate audio tracks for commentaries/foreign languages/subtitles besides the obvious loss of awsome video/surround/sound quality.. hehe, i only use divx to dump movies and anime to my laptop. Otherwise its so inferior its laughable🙂 At 1800-2000kb/s it does seem to hit a brick wall, it gets pretty much artifact free, but it doesn't improve after that point.
 
LocutusX

Wow! That's a lot of info. you shared. Thanks a lot, dude! I'll read up on DivX and get those utils as soon as I can. Perhaps the only way to make the perfect DivX movie is to cut up the original stream, encode each section with the appropriate method, and recombine them. I operate on a TBird 900MHz, BTW.
 
I've been working with DivX for a while now and have produced what I believe are some very nice videos.

Here's what I do:

Encode with Flask. Yes, it's slower than AVIMPEG but most (go to Doom's site, I'd link but it's down now) agree the quality is better.

Use mmx encoding, there is NO differnce using the reference encoding. Again go to Doom's for a comparision.

If you have a fast CPU (750+) encode widescreen at native resolution (640x272 I believe). Remember to keep multiples of 16.
Normal should be reduced to 512x384. I like the bicubic interpolition, I think it's a little sharper (higher order), but bilinear is fine.

For NTSC use 23.97fps, select deinterlace and reconstruct progressive frames. This is produce the best output. I have not had a problem with these setting yet. I have had the banding problems with other settings.

Set bitrates for 1 or 2 CD's, your preference. I usually go 1 CD under 100 minutes or so.

Don't compress audio! Audio should go straight to PCM at 44.1KHz. Do this later with Virtual dub.

Set keyframes at 1 so that you can seek within movie easier and have keyframes to edit the end of the movie. I get rid of the credits to save space. Plus, I have them on the original DVD 😉

Open the movie in Virtual dub and set beginning and ending points to save space. Save both audio and video in direct processing mode to avoid and generation loss.

Save audio file and open in a audio editor. Compress, limit, and normalize the audio so you can hear all the dialog on a noisy airplane without blowing your head off on loud scenes. I use Sound Forge, it can open avi files directly.

Now open the edit video and audio files in Virtual Dub and compress the audio. Leave video set to direct stream and compress the audio with the mp3 codec. You can't use the DivX audio at 48khz sampling rate, DivX is only hacked at 44.1khz for DivX. You can convert the sampling rate but the sound track will be off a bit by the end of the movie. I usually calculate the audio for 48kbps since DivX always is conservative then I move up from there to either 56 or 64kbps. If the soundtrack is really important I'll make sure I have enough room for 96kbps joint stereo.



 
For everyone's info, 3ivx will be released in a few days (tommorrow?) and it "promises" a number of advantages over DivX that might convert Zucchini over to our side. 😉

Also, Microsoft will be releasing yet ANOTHER Windows Media Encoder package soon (version 8!) and this time they are making a number of promises that seem discreetly pointed at the DivX community. i.e. DVD-quality video at 500kbps, DVD-quality audio at 64kbps. Since a user at Doom9's forum mentioned the "frameserving" technique he used to use WME7 to create flicks, WME8 might be interesting and have a use, *if* Microsoft lives up to the hype.

3ivx -> www.3ivx.com
Microsoft -> you know where

BTW Zucchini, you can use DivX to make umm "Backups" of the stuff you rent from Netflix... but I guess you already know that. 😉 Oops there I go again...

Edit: For those of you who want to check out some flicks encoded with Microsoft's newest encoder, go to http://www.microsoft.com/windows/windowsmedia/en/compare/quality.asp

I played the DVD-quality video @ 500kbps and it doesn't seem *THAT* much better than something DivX could do, although at that LOW bitrate (video is 448, audio is 64) it is certainly quite impressive. Also note the large framesize.
 
LocutusX,

Thanks on those tips. I actually did have one half-second garbled scene (I suppose they were just overly-big macro blocks) when I encoded at 32-bit. I'm suffering through finals so I haven't had much time to look into it, but this sort of thing really interests me...I'd like to start learning about the programming side as the math related side seems to make sense.

Can't wait until the ultimate low-bandwidth codec can use a 3D accelerator to offload the CPU requirements...or of course, the other ultimate low-bandwidth codec that is easy on the CPU in the first place😉 Anyway, if I'm not mistaken there are already efforts under way to have "3d accelerators" do some of the decoding (I guess encoding as well) of low-bandwidth movies. Apparently MPEG4 involves some vectorizing of "shapes" and then texturing of them (I could be totally off but I recall reading this somewhere). So I guess it makes sense that it would be possible, at least in theory, for my GF2 MX to do some hardcore decoding (probably not for MPEG4...some future variant).

-GL
 
so that 3vix codec is still DivX compatible correct? just using your own code..

is there any program out there that supports all of this.. sortof like winamp, but for DivX, yet more fully featured then WMP..

btw, I seriously think that my Mpeg2 decoder card (hollywood plus) is helping out.. I'm playing 384 x 274 25 fps with the quality slider all the way to the right (setting 4) in windows media player, without slowdown at all..

can someone point me to a short (1 minute in length or so) yet full resolution (640X480 or greater) DivX file, so I can test this?

during this christmas break, I'm probably going to try some encoding from my DVD's, just to find the best way to do this stuff..
 
locutusX,
"BTW Zucchini, you can use DivX to make umm "Backups" of the stuff you rent from Netflix... but I guess you already know that. Oops there I go again...
"
Heh 😛 Yea i've already tried that out. Its just that i get spoiled by the dvd and never watch the divx😛 Well that and i ussually don't watch movies twice anyways, especially after rewatching the dvd to hear commentary😛 hehe, as the 3vix, i'll be surprised if it lives up to the hype. Wonder how long encodes will take.

I have used divx for old anime and stuff, that really doesn't require need the extras/quality.
 
I personally don't think ripping DVD's is the 'ultimate app' for DivX. sure it could be useful, but I'd much rather own the DVD (easier to get, quality is guaranteed, I'm on a 56k modem).

I would (and DO) use it for TV shows (HDTV would be the killer app for this) the most..

Edit: from my original post:

"btw, I seriously think that my Mpeg2 decoder card (hollywood plus) is helping out.. I'm playing 384 x 274 25 fps with the quality slider all the way to the right (setting 4) in windows media player, without slowdown at all.."

I forgot to mention I'm running on a K6-2 400.. which is the sole reason I'm surprised this thing runs so well..
 
Hulk,

Not to get on your case or anything, but I've heard the exact opposite of everything you've said (i.e. I've heard avi2mpeg is better than flask and I'd agree and to encode at lower resolutions so as to provide as much data allocated to a macroblock as possible). I'm not saying you're wrong - to each his own and this is a really unscientific practice right now - but you might want to try doing the opposite of what you're doing now to see if you get even better results.

Soccerman,

There's no way your H+ is doing anything😉 Mine isn't. The H+ is a dedicated hardware MPEG1/2 decoder. Unless MPEG 4 has strong roots in MPEG 2 (I don't really think it does) then it'll probably be useless at trying to decode MPEG 4 assuming drivers could be written for it to decode more than it already does. But hey, I'd like to see it happen!

-GL
 
GL,

I agree, the programming associated with MPEG video is really cool... Whenever a new flask variant comes out, I like downloading the source code, messing around with it and recompiling it and using *my* executable rather than the distributed one. Sometimes I enable some optimization flags that the author's binary had disabled and I end up getting a measly performance increase. 😉

Anyways it seems as if Microsoft's sudden interest in the field is because they want to be the providers of the vehicle that Hollywood uses in the near future, when they start releasing for-rent movies over the net. It's definitely going to happen, they just need to make efforts to better the broadband infrastructure, and we may soon be seeing Blockbuster video come out with an E-Commerce initiative, featuring movies for "download" (encrypted of course, and only plays for a day or something) using either a future Windows Media codec or perhaps Apple QuickTime. I know a lot of college students who'd rather pay half the price (or less...) of renting a DVD so they can stream/download a DVD-quality movie off a commercial OC3/ATM-backbone server rather then wait forever in queues on IRC downloading pirate flicks at the speed of a capped DSL modem.

 
That's right, there is no way the H+ can help out in MP4 decoding. The MPEG4 standard is really quite different from MPEG2 (which is actually much more similar to MPEG-1 than you think!) so it seems to me to even be impossible to *HACK* the H+ so that it acceleratest MP4 video.

Also, I think that 384x256 videos ran fine on my PPro166 @ CPU usage of 1, so it does not seem farfetched that a K6-2 400 with 3Dnow and MMX acceleration enabled can handle the same video @ CPU usage of 4. I *believe* that the DivX decoding algorithms use MMX or integer instructions, rather than FPU instructions, so your K6-2 fares well.
 
Zucchini, I highly doubt it!

the reason being, people before have reported trying that setting, on machines as fast as 1 ghz. of course, they were probably on a much higher resolution video..

I would NOT doubt that DivX has roots in MPeg2. after all, DivX was created from the MPEG4 format, and therefore I wouldn't be surprised if it basically built on at least SOME of what was done in MPEG 2.

the other reason why I feel it is possible (no special support is needed btw), is because my Hollywood plus accelerates ALL Mpeg 1 or 2 files, when played through media player. I know this for a fact, they run super smooth, and react the same way as when I'm playing them through the Realmagic DVD station software.

I even remember seeing something (readme file? I don't remember where) about it accelerating MPeg1 and 2 videos.. at least within Windows Media player.

it also explains why I can output ANY mpeg 1 or 2 file I've encountered to the TV when using the Realmagic Hollywood plus playback software.
 
Sorry Soccerman😉 You have succombed to what is known as the placebo effect🙂 There are exactly two players that take advantage of the Hollywood+. One is the Sigma Designs player itself. The other is one called Eugene's DVD Player if I remember correctly (a third if you count whatever comes with the Creative card).

I'll give you a quick run-down of how the H+ works and how you can verify that this is the case. The Hollywood+ uses an overlay technique whereby it locates a certain colour fed to it by the VGA adapter, and replaces these pixels with its own video before sending the modifed VGA "picture" out to the monitor. It is usually an obscure, underused colour and the video window of the H+ software is filled with this colour. So when the VGA adapter sends the picture of the H+ software screen (and the rest of the VGA signal or "picture&quot😉 to the H+, the H+ recognizes the special colour filled area, and knows to replace it with its own video. Now, weired things can happen sometimes. While surfing the web once and watching a DVD through my H+, I noticed that a banner ad had this same colour in it and so the video popped right through the areas of the banner ad filled with this colour. Pretty weird at first...couldn't understand why until I learned how the H+ worked.

Anyway, the video data is sent to the H+ and the H+ decodes this data, streaming it to your monitor without having to go through your VGA monitor (because it uses the video overlay technique described above!).

OK, to prove your normal media player (I assume MS Media Player?) isn't being accelerated by your H+, unplug your H+ from your monitor and plug your monitor straight into your video card. If the H+ is accelerating the video in MS Media Player, you will not get any video...merely a window filled with an obscure colour (I think an off-gray or black). If you're seeing video, you can thank your CPU for doing a good job of producing such smooth video.

And to reiterate, it is 99.999% impossible that the H+ will ever do MPEG 4 decoding. The reason being that MPEG 4 is, as LocutusX pointed out, so much of a drastic step away from standard MPEG video. In fact, you'd have a better chance of having your Voodoo5 or Geforce 2 decode MPEG 4 than your H+. Whereas MPEG 1/2 deal mainly with looking at individual pixels and determining how they change/remain over time and throwing away redundant data (this is a gross over-simplification though), MPEG 4 is more smart in that it can actually distinguish between background inanimate objects and animate objects and deal with redundancy and compression on individual objects in a scene.

I wish my H+ would do a bit more, but I think it is now relegated to the task of DVD TV-out as all its other functions are now redundant.

-GL
 
so does it decode divx to tv output? My old p2 400 could run divx, but not at full quality. Course the higher the bitrate/resolution the harder to decode, it had trouble only with the very high end.

and yea, that would be one @$^##% powerful decoder card to handle mpeg4😛
 
Good explanation, GL.

The fact that cards like the H+ can't handle MPEG4 is one reason that startup consumer electronic companies are reluctant to make a standalone MPEG-4 player. Computing power required is far more than that of MPEG1/2 and the current MS-MPEG4 implementation has deviated so much from the ISO MPEG-4 standard that M$ might as well give it it's own name - and Gej did, he hacked 8 bytes off it and renamed it "DivX ;-)".
 
It doesn't handle divx. A hacker took Microsoft's MPEG-4 codec implementation distributed with media player, opened a hex editor and changed a couple of values, then released these hacked codecs under the title divx. They're really just Microsoft's MPEG 4 codecs.

That's one of the pitfalls of the H+. It can output to TV only what its decoder chip can output and that's just MPEG 1/2 video🙁 I wish my H+ could output VGA from my desktop...that'd be sweet as it has the best TV-out of any "video" card out there.

-GL
 
GL-

I have found that 640x272 (widescreen) looks very good if the bitrate is above 800 or so. Assuming there isn't too much action in the flick and you have a fast enough processor to decode with the CPU slider at 4. At this resolution I can't see any artifacting at the native playback size. Full screen playback looks very good (obviously not perfect)as well.

640x272=174,080 pixels, 512x384=196,608 pixels. Both very close which is why I use these resolutions when encoding. Go much higher and more bandwidth (>1200 or so) IS required. Plus, my PIII850 can't decode with full CPU slider quality at full 640x480, every now and then a frame is dropped.

Like you said, to each his own. To my eyes/computer/movies these resolutions/bitrates seem optimal.

As far as the reference vs. MMX encoding issue you'll have to check out Doom9's site when it's back up. His extensive test showed NO DIFFERENCE except a longer encoding time!
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top