View Full Version : DivX 5.1.1 crash
MrDarcy
21st November 2003, 13:04
Last night I launched my first DivX 5.1.1 encoding using Gknot, and this morning I found it crashed at about 46% of the 2nd pass.
There was a popup from VDubMod with something like "Closing corrupted MV". Enter debug ? Yes/No". I choose No and the standard VDub crash info appeared.
It reported that a "Breakpoint" has been set.
Is it a kind of debug feature forgotten in DivX?
I saved the crashinfo file, if useful I can post it here...
Using the same source I completed a XViD encoding a few weeks ago, so I don't think it's a bad frame issue.
Angelus
21st November 2003, 23:01
if ur using the MV, don't. The general consensus is that the mv file doesn't help encoding speed and shouldn't be used all together. If you didn't use it, then I'm not sure, maybe try re-installing Divx.
MrDarcy
22nd November 2003, 13:06
Originally posted by Angelus
if ur using the MV, don't. The general consensus is that the mv file doesn't help encoding speed and shouldn't be used all together. If you didn't use it, then I'm not sure, maybe try re-installing Divx.
Thank you Angelus, you're right, I was using MV.
In the meanwhile I tried once again and it crashed at the same exact point as the first time. Here is the exact message in the popup window:
Type 4 MV inconsistency found
Closing MV file. Debug?
Yes/No
And here is the text from VirtualDubMod info.
A stray breakpoint occured in module 'DIVX'...
... while compressing frame 103025 from 83a6e000 to 0459000c
I'll try without the MV as you suggested.
Bye!
SeeMoreDigital
22nd November 2003, 14:54
Originally posted by Angelus
if ur using the MV, don't. The general consensus is that the mv file doesn't help encoding speed and shouldn't be used all together. If you didn't use it, then I'm not sure, maybe try re-installing Divx. It's an established fact that different encoding applications encode, and repond to a codec in slightly different ways.
Recently VDubMod users reported problems with some of the new DivX codecs especially the betas.
In fact, if you cast your mind back to some of the beta's you will find that Kaukura was capable of generating incredibly fast 2nd pass encodes when using MV!
For a trip down memory lane here are some links
DivX Kauehi: -
http://forum.doom9.org/showthread.php?s=&threadid=56805
DivX Manihi: -
http://forum.doom9.org/showthread.php?s=&threadid=58283
DivX Kaukura: -
http://forum.doom9.org/showthread.php?s=&threadid=59149
Cheers
MrDarcy
22nd November 2003, 16:01
Originally posted by SeeMoreDigital
In fact, if you cast your mind back to some of the beta's you will find that Kaukura was capable of generating incredibly fast 2nd pass encodes when using MV!
I just read the very well written DivX guide, and I learnt that using Bi-Directional encoding MV is almost useless and gives a little lower quality. Did I understand right?
SeeMoreDigital
22nd November 2003, 21:02
Originally posted by MrDarcy
I just read the very well written DivX guide, and I learnt that using Bi-Directional encoding MV is almost useless and gives a little lower quality. Did I understand right? I think it's fair to say that DivX 5.1.x.x, performs very differently from previous (5.0.x.x) versions.
Although encoding times have got faster when using some settings. In other settings, especially when enabling BiDi etc, the encoding times are sometimes confusingly slower
DivX unfortunately, confused matters further with their decision to include two more speed/quality modes. In hindsight maybe they should have ditched the headings: fastest, standard, slow and slowest. And just numbered them 1,2,3 and 4 instead!
I have to admit I have not read DivX's latest guides, so I can't confirm whether BiDi works when MV is selected. Personally I have not used BiDi all that much (apart from testing) since DivX 5.0.2 and I don't use MV either!
When the DivX betas were available for testing, I mentioned quite a few times, that I thought it might be a good idea to include 'help/warning' banners whenever the user selected modes that were either pointless or served no positive function. But that idea fell on deaf ears.
However, I'm happy to say, you can't now select MV when encoding using 'slow' and 'slowest' modes. Which is a step forward!
Cheers
MrDarcy
22nd November 2003, 22:31
Originally posted by SeeMoreDigital
When the DivX betas were available for testing, I mentioned quite a few times, that I thought it might be a good idea to include 'help/warning' banners whenever the user selected modes that were either pointless or served no positive function. But that idea fell on deaf ears.
The guide describes some of these rules, but it would be better if incorrect combinations were unselectable/greyed out (like MV with slow/slowest).
At least a short table with all valid/invalid combinations would help people to avoid hours of encoding with "wrong" choices.
Bye!
PS: any other idea about my crash?
SeeMoreDigital
22nd November 2003, 22:46
Originally posted by MrDarcy
...any other idea about my crash? Not really!
It may well just be another VDubMod problem. All I can say is, as time goes bye, others might report the same problem as you!
Have you checked GK's website to see if there's been 'any' reported issues with DivX 5.1.1?
Cheers
DigitAl56K
23rd November 2003, 01:16
A few things:
1 - Bi-directional encoding doesn't, and never has used the MV file (afaik). However, bi-directional encoding has always been on by default in DivX and there is no particular combination of settings in 5.1.1 that would make it slower than the equivelent in 5.0.x
2 - With the performance enhancements in 5.1.1 MV re-use isn't the performance booster it once was. I couldn't recommend it except for older computers or people on a very tight timeline. It can degrade the quality.
3 - Quite a lot of work was put into the 5.1.1 GUI so that it prevents you selecting options that won't work together. Many of the notes in the guide that describe option incompatibilites are already enforced by the GUI under 5.1.1 so that even if you didn't read through the guide you really couldn't select incompatible options any more.
Hope this all helps
-Al
SeeMoreDigital
23rd November 2003, 01:43
Thanks for responding Al,
I know it's a bit early to talk about new things but is there any probability of reinstating encoding to the MP4 container?
Cheers
DigitAl56K
23rd November 2003, 02:22
Actually a lot of people seem to be asking about the mp4 convertor of late. I haven't heard any mention of plans to bring it back, but if demand keeps up maybe it will be a possibility.
I'll ask around and see what I can find out, maybe even put a good word in for it :)
-Al
MrDarcy
23rd November 2003, 10:05
Originally posted by SeeMoreDigital
It may well just be another VDubMod problem. All I can say is, as time goes bye, others might report the same problem as you!
Thank you,
but in my ignorance I think the error is more likely coming from DivX than from VDubMod.
Type 4 MV inconsistency found
Closing MV file. Debug?
bond
23rd November 2003, 10:21
Originally posted by DigitAl56K
[B]Actually a lot of people seem to be asking about the mp4 convertor of late.me too :)
Stux
23rd November 2003, 16:39
Well, you can always use the 3ivx MP4 Muxer to easily convert your DivX encodings into MP4 ;)
Gives you a way to do the audio too
SeeMoreDigital
23rd November 2003, 17:58
Originally posted by Stux
Well, you can always use the 3ivx MP4 Muxer to easily convert your DivX encodings into MP4 ;)
Gives you a way to do the audio too I tell you what Stux!
If you guys could make the next version of your encoder generate an 3vix Mpeg4 video stream and provide the option to add either an Mp3 or AC3 audio stream, directly into an MP4 container (with AR flagging ofcourse). Then you'll be way ahead of DivX..... And way ahead of everybody else!
Just a thought!
Fr4nz
24th November 2003, 14:39
Originally posted by DigitAl56K
A few things:
....
2 - With the performance enhancements in 5.1.1 MV re-use isn't the performance booster it once was. I couldn't recommend it except for older computers or people on a very tight timeline. It can degrade the quality.
....
Hope this all helps
-Al
So you are suggesting to avoid the MV file use?
shitowax
24th November 2003, 18:25
You can already generate compliant .mp4 containing mp4v video with AR and mp3 audio with 3ivx D4 4.5 ...
Originally posted by SeeMoreDigital
I tell you what Stux!
If you guys could make the next version of your encoder generate an 3vix Mpeg4 video stream and provide the option to add either an Mp3 or AC3 audio stream, directly into an MP4 container (with AR flagging ofcourse). Then you'll be way ahead of DivX..... And way ahead of everybody else!
Just a thought!
SeeMoreDigital
24th November 2003, 18:42
Originally posted by shitowax
You can already generate compliant .mp4 containing mp4v video with AR and mp3 audio with 3ivx D4 4.5 ... But, don't you have to do this as a separate process? After you've first generated the encode to an .avi container!
Cheers
Stux
24th November 2003, 19:30
Originally posted by SeeMoreDigital
But, don't you have to do this as a separate process? After you've first generated the encode to an .avi container!
Cheers
Only because you're using VfW based encoding applications
An example,
you can open an avisynth thingy in GraphEdit and do this
/->video encoder ->\
avs< >mp4 muxer -> mp4
\->audio encoder ->/
The trick is dual-pass ;)
its often easier if you prefer to use vfw tools to encode into an intermediate avi and then remux that to mp4
avi=>mp4 muxer->mp4
quick and simple
SeeMoreDigital
24th November 2003, 19:52
Originally posted by Stux
its often easier if you prefer to use vfw tools to encode into an intermediate avi and then remux that to mp4
avi=>mp4 muxer->mp4
quick and simple It would be even simpler if you could have an option to select either the .avi or .mp4 container in your GUI!
Cheers
shitowax
24th November 2003, 22:37
I agree that a GUI is required, but we won't let users select the mp4 container from the VfW dialog, no way ...
Originally posted by SeeMoreDigital
It would be even simpler if you could have an option to select either the .avi or .mp4 container in your GUI!
Cheers
SeeMoreDigital
24th November 2003, 23:09
Originally posted by shitowax
I agree that a GUI is required, but we won't let users select the mp4 container from the VfW dialog, no way ... May I ask why?
Actually, I think this conversation should really be in your own thread. (http://forum.doom9.org/showthread.php?s=&threadid=64966) So that others may benefit from the info too!
Cheers
Fr4nz
25th November 2003, 17:13
I have one question: why the use of MV-file can degrade quality?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.