|
|
| Feņiz |
 Posted: May 5 2003, 09:50 AM |
 |
|
Unregistered
|
I'm using Virtual Dub 1.5.2 and DivX 5.05 under Windows XP to compress a video.
The video is MPEG-2, and it's frameserved using DVD2Avi and Avisynth.
I use the Job Control to program the 2 passes. Firs pass is done correctly, but when doing second pass, Virtual Dub remains at 99%, and a Windows message appears saying "The system Virtual Memory is out".
I tried with some videos, and always the same problem. I always made the same procedure, and it worked perfectly with older versions of V. Dub.
Do you know if it's a bug?
|
|
| Tyvol |
| Posted: May 8 2003, 09:36 AM |
|
|
Unregistered
|
 I experienced exactly the same problem, while Nth-pass encoding with DivX 5.0.5. with batch job control.
I'm using VDub 1.5.2 on Win2000. The video is (as described above) MPEG-2 frame-served with AviSynth2.
The first pass is going fine, but when the 2nd pass finishes all virtual memory is consumed (so I get these f**king error messages).
If I abort the dub, all memory is released, but avi is unreadable.
If somebody knows a workaround, I'd be thankfull.
|
|
| Kinthalis |
| Posted: May 8 2003, 01:02 PM |
|
|
Unregistered
|
I'd like to add that this is also happenning to me. Using Divx 5.05 and Virtual dub 1.5.2 and encoding a 2-pass movie. VirtualDub will freeze upon reaching 99% completion on the second pass and virtual memory will get swamped. |
|
| alb460 |
| Posted: May 9 2003, 07:15 AM |
|
|
Unregistered
|
I'd like to add that this is also happenning to me. Using Divx 5.05 and Virtual dub 1.5.2 and encoding a 2-pass movie. VirtualDub will freeze upon reaching 99% completion on the second pass .... on the log I see that there is a livelock and VirtualDub is looping every 10 sec to see if the lock is still there ... and it is .
I'd like to know if :
1) Is it possibile to know WHO is locking WHAT ? (but why always and ONLY at the end of the job ....)
2) May be the old Panasoinc codec I'm using to read the AVI file to compress ?
HELP !
Thanks
|
|
| Aros |
| Posted: May 9 2003, 03:45 PM |
|
|
Unregistered
|
I am also having the same problem with v1.5.2 on windows XP pro At the very end of the second pass it stalls at 99% complete shows 0 FPS and virtual memory starts to be used up. the resulting AVI is large enough to be the complete file but it won't play. I was using the job control to automate the 2 passes
I have tried it on 2 different AMD 2400+ systems one with ATi radeon 9700 + sb Audigy, the other with geoforce 3 and sb live.
I am encoding using divx 5.4 and MP3 audio (Franhaurer ?sp)
The reason I tried 1.5.2 was to use the fractional decimation to get at lower FPS for my pocketPC
The wierd thing is that it happens most times - but occasionally it worked if I manually saved each pass rather than using job control feature. But just last night it happened with manually saving each pass.
I have given up for now - but would really like to encode at 18-20 fps for pocketPC
thanks
Al |
|
| jalves |
| Posted: May 9 2003, 04:52 PM |
|
|
Unregistered
|
Hello,
I will start by saying a big "Thank You" to the Developer(s) of VirtualDub and everyone that provides support to it.
I'm also using v1.5.2 (on WinXP Pro) and when recompressing a DivX movie (using DivX Pro 5.0.5) using Nth pass, VirtualDub stops at the end of the second pass. VirtualDub starts to allocate memory and the entire system suffers. Yesterday I increased my windows pagefile to 1GB, and VirtualDub only stopped when it was using all of the memory - VirtualDub was using 1.3GB of memory wich is more than each of the movies I was using (source-900MB, dest.-700MB).
As an answer to 'alb460' I believe it's Windows virtual memory manager that is locking 'the memory' since it has none more to give to VirtualDub.
I was uncertain if this was a problem with VDub or DivX, but by the reports on this thread it may be from VDub.
----------------------------------------------------------------------------
Information that may be useful:
The original movie is in DivX (DIV3 I think) with MP3 audio (48KHz, stereo)
The settings on VirtualDub are:
- using the null transform filter to do a crop
- video compression: DivX Nth pass with bitrate set to 555kbps
- audio conversion to: 44Khz, stereo
- audio compression: DivX audio 64kbps (44Khz, stereo)
As additional info I tried to compress another movie (a small MPEG) using DivX Nth pass and it worked fine. VirtualDub didn't even tried to allocate a lot of memory at the end of the second pass.
bye,
JAlves |
|
| Tyvol |
| Posted: May 12 2003, 09:18 AM |
|
|
Unregistered
|
 I'm now a little bit wiser than last time.
It seems to me that this prob is some bug in VDub.
I downloaded version 1.5.1 and gave it a second try (used same parameters as above)!
Well, it works!! 
So from my point of view, this prob must be related to the changes in ver 1.5.2.
|
|
| Ook |
| Posted: May 21 2003, 09:22 AM |
|
|
Unregistered
|
I have exactly this problem in 1.5.2 & 1.5.3 when encoding from a tv capture avi to divx5.0.5, I`ve since gone back to 1.5.1 with no problems.
|
|
| phaeron |
| Posted: May 22 2003, 03:46 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
OK, here's what I know so far:
For the problem to occur, you have to be using DivX 5.0.5 Pro, have B-frames enabled, and be running the second or subsequent pass of a multipass operation. It doesn't happen with DivX 5.0.5 Free or with Pro when either using 1-pass or multipass with B-frames disabled.
DivX's B-frame support works by producing special padding frames that the client identifies and discards; this allows the codec to produce output ahead of its input, which is necessary for the codec to do backward prediction (pull data from future frames). The client counts the number of buffered frames and then flushes the final frames out of the codec by passing in that many more frames. Well, for some reason I haven't identified yet, DivX 5.0.5 is putting out padding frames while VirtualDub is trying to flush out the buffer at the end! This causes VirtualDub to loop endlessly trying to flush out a codec delay that never gets shorter.
You can identify this situation in the real-time profiler by the Processing thread getting stuck running "V-Compress" tasks over and over again. (Left and right arrow keys change the resolution of the profile.) Unfortunately, you cannot abort the operation because the queue flush loop doesn't check the abort flag. I'll fix that for the next release. The memory usage is mysterious -- VirtualDub doesn't allocate memory in that codepath. Unfortunately, as DivX runs in VirtualDub's process, you can't tell who allocated the memory by looking at the process stats.
The reason why 1.5.1 and earlier are not affected is that those versions only expect padding frames to appear at the beginning of the operation -- the count of frames needed to flush out the codec delay is held in a volatile variable that is shared between the I/O threads and the processing thread. At the end of the operation, the I/O thread has already long finished by the time the processing thread receives the padding frame, and never gets a chance to push the corresponding flush frame. In 1.5.2+, this flushing is done entirely in the processing thread and is always accurate. Thus, you'll always hit the bug.
|
|
| insomnia |
| Posted: May 24 2003, 08:16 PM |
|
|
Unregistered
|
Just want to add I've been using 1.5.2 with no problems encoding to Divx 5.05. However just switched to 1.5.3 and hit the above problem.
Insomnia |
|
| Aros |
| Posted: May 24 2003, 11:51 PM |
|
|
Unregistered
|
Hi This problem ocurs for me with both non pro versions of divx 5.04 and 5.05 - I don't use B-frames or any of the pro features.
Maybe it is more than one bug that that gives the same symptom
Al |
|
| Feņiz |
| Posted: May 25 2003, 03:29 AM |
|
|
Unregistered
|
I just tried new Virtual Dub version (1.5.3), with DivX 5.05, and the problem persists. |
|
| phaeron |
| Posted: May 25 2003, 09:08 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| QUOTE |
Just want to add I've been using 1.5.2 with no problems encoding to Divx 5.05. However just switched to 1.5.3 and hit the above problem.
|
Well, 1.5.2 had a bug where it wouldn't always finish flushing the pipeline... which bypassed this problem.
I tried pinging DivXNetworks help desk on this problem, since their "submit bug" form is missing, and the help staff just closed my request with some useless links to FAQs. I guess I'll have to code a workaround on my end. It's ironic considering they asked me to add B-frame support for their codec in the first place.
|
|
| Rippee |
| Posted: Jun 21 2003, 02:11 PM |
|
|
Unregistered
|
well i get that "possible livelock" message at the end of my 2nd pass!! the job window says its at 100 percent but the main virtualdub window shows it to be at 99 percent and then it just hangs up. I run windows 98 and use virtualdub 1.5.2 and DIVX Pro 505. My problem is that most of the time this program combo worked great with a widescreen anamorphic dvd image (for back-up purposes) so I could watch the movies, without dragging my DVDs around, on my laptop. Now with a fullscreen NTSC image I am suddenly having these problems. I wonder if I get the Virtualdub will this problem dissapear  |
|
| schnogg |
| Posted: Jul 21 2003, 06:01 AM |
|
|
Unregistered
|
I believe I am having the same problem here with encoding. The new peice of information I have is that it is related to the audio codec. I am running WinXP Pro on an Athlon 1.3 with Divx Pro 5.0 and encoding lame mp3 160kbps audio and after 14%, the frame rate drops to 0fps and i get an error: Possible Livelock repeated over and over until the virtual memory fills up. if i change the audio codec to uncompressed pcm, it encodes fine. I am not sure if this problem is the same or if I am doing something wrong but I am still testing.
Thanks for the work.
It seems worth mentioning that the problem persists with divx 5.05, 5.0 and 4 codecs. The aforementioned video codecs are the only ones that I have tested with.
|
|
