View Full Version : Divx 5.1.1 problem that is still not fixed?
fedge
28th November 2003, 01:36
I have had this problem with all divx 5.1 releases.... SOMETIMES... when i try to do a test encoding in part of an avs file (not at the begining) or sometimes from start to finish of the avs (in virtual dub mod) i get a lot of macroblocking... at any setting.. (normal, slow, slowest etc)
However, when i restart it clears up this problem. So , i make sure to reboot before doing any encoding. what could be causing this.?? crashed prog or somethign.. memory problem..
acanthis
28th November 2003, 09:25
I reported this problem some time back with 5.1, but nobody believed me - with everyone basically coming back and saying "Doesn't happen for me" etc.
I still see this happening even in 5.1.1 - the symptom being a sudden and inexplicable falloff in the allocated bandwidth leading to excessive macro blocking; i.e. a 780kbps encode suddenly looks like its been encoded at 128kbps.
I have always been able to fix it by bumping up the bit rate for the encode by 100-200kbps. And before anyone starts up with their "You should have used a higher bit rate in the first place" - No. 640x480 @25fps with low motion complexity should look fine at 850kbps, it shouldn't look like a RealMedia clip streamed over a 14.4K modem!
I Don't know why it does it. DivX Networks never answer technical support questions other then to say they've been closed, so I've given up even trying to find the cause *or* trying to get someone to believe me that it happens! :)
Good luck.
dTb
28th November 2003, 10:58
Quite a few people have experienced this problem actually, it seemed to first appear with the early 5.0.3 betas iirc. They managed to find the cause and fix it but it appears it still occurs but just a lot less frequently.
Sorry I can't really help you solving it, maybe try find some old threads at divx.com in either the beta section or the labs section and bump them in an effort to bring it to the devs attention.
fedge
30th November 2003, 18:41
I find a reboot will often fix it.. but not reliable.. (the best thing to do is probably slice a movie within the avs file.. )..
Gej
2nd December 2003, 18:41
Hi,
We are happy to find and fix bugs in the codec, in this particular case we need more info. I guess it's 1 pass ? What are the codec parameters ? and what is the clip ? and how long is the piece you want to encode ?
thanks
fedge
3rd December 2003, 22:13
2 hr avs file from a dvdripped source... i am selecting sometimes a segment in the middle of the file about 500 frames to test the quality visually , in virtual dub mod 1.54, and somtimes from the start...
it happens when there are a lot of I-frames going on.. and somtimes high bitrate-b-frames... (like when water moving.. etc).. in other cases it does a good job with these clips but sometimes the same cliip will look crappy.. and then other times it looks fine..
doesnt seem to matter..
I ALWAYS do two pass encoding. I've checked the log file and the bitrate SHOULD be good enough to prevent macroblocking..(says it should be above 100kbytes/sec) but still the video doesn't look it. the macroblocks look a little like looking through a glass brick wall.
after a reboot the problem goes away. most of the time
temporance
3rd December 2003, 23:14
If you're encoding nth pass, you need to encode the exact same video, start to end, that you used to make the first pass.
If you just encode a segment, the encoder will encode it as if it was the first part of the whole move and will allocate bits and keyframes appropriate for the first, e.g. 500 frames that it saw in the first pass.
Could this be your problem?
colordog
6th December 2003, 03:52
:search:
Please remember to try to use the "search" feature. There are at least three current threads discussing this. The macroblocking appears to be a post-decoding bug.
http://forum.doom9.org/showthread.php?s=&threadid=65833
http://forum.doom9.org/showthread.php?s=&threadid=66226
http://forum.doom9.org/showthread.php?s=&threadid=65334
DigitAl56K
6th December 2003, 05:00
{Copy/Paste from another similar thread - lots of people reporting this}
Hi guys,
We've known about this issue for quite some time, its caused by the de-blocking where there are high contrast vertical edges in a block (e.g. along the edges of anime characters etc.). Turning of de-blocking (or partial PP) will prevent it until the decoder is officially updated.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.