|
|
| freedomdwarf |
 Posted: Jul 16 2011, 12:55 PM |
 |
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
Sorry for the duplicate post but I inadvertently posted this bug in the news section.
It's a nice lot of fixes but has anyone noticed the bug in Job Control in v1.9.11 and v1.10 releases??
I have emailed Phaeron (twice) a while back (2 weeks ago) but got no reply as yet.
For those that haven't spotted the problem, this is what I get -
In essence, I cannot get it to do a folder/directory and keep the settings between each job to be processed.
I set everything up (audio & video settings, compression, filters etc) and when I start JC the video compressions are completely reset to uncompressed on every job in the list and the filters are being ignored
The audio settings are fine and are remembered, but the video ones aren't.
It used to work in earlier versions of VD but not the latest few updates and the beta version.
As an example, A simple black & white TV series that I'm cleaning up would usually take 3-4 minutes each for the 26-minute clips but I would have to do each one manually - hence the use of the 'process directory' in the job control.
For 39 episodes, that's a LOT of manual intervention when JC could do it in a single stream for a couple of hours or so uninterrupted (it actually took *6* days in practice under 1.9.10 instead of a few hours!). In VD v1.10.0 they were taking 5-6 mins each.
Each clip is about 150MB and recoding it into AC3/DivX6.9 should yield 120-130MB files but with the compression being reset they are ending up at over 22GB each!!
I have a fair bit of HD space but I don't have 800Gb free! lol.
Just an update - VD v1.9.10 seems to be working correctly and remembering the video settings - VD v1.9.11 and v10 beta don't.
So I guess something got broke somewhere in the update?
Just as a side-note which might help, in v1.9.10 when processing JC, I DON'T have a progress box showing whilst it's doing each file (just the VD main window with the input/output video and the Job Control window) whereas with v1.9.11 and v10 beta I have the usual progress box (project stats, perf etc) showing with each file being processed just as if I were doing a single file manually.
Dunno if that helps to pinpoint the hiccup.
It doesn't crash - it just doesn't behave like it used to and therefore produces unwanted reults.
Another oddity I have noticed.....
I can run several instances of VD with each doing its own thing - not a problem.
I can even have one of them doing a directory via JC.
However, if I wanted to do another directory via JC when one lot is already processing, I cannot open a new JC list - I always get the one that is running already. So it seems I can only have *ONE* set of Job Control even if I have several instances of VirtualDub running.
I would have thought that the JC would be a child process of the originating VirtualDub but it seems that JC has a singular thread ID and hence can only be used on its own.
It's a tad annoying but I guess I can live with that if it got fixed in v1.10+
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| ale5000 |
| Posted: Jul 16 2011, 06:23 PM |
|
|
Advanced Member
Group: Members
Posts: 1114
Member No.: 22180
Joined: 30-September 07
|
Try with VirtualDub 1.10.1: http://forums.virtualdub.org/index.php?act...ST&f=15&t=19755
--------------------
New VirtualDub forum
VirtualDub AIO (All-in-One installer for VirtualDub and plugins)
Codec Toolbox RS (A tool to read/change merit of codecs and many other things)
Input plugins for VirtualDub / ACM codecs / VFW codecs |
|
| freedomdwarf |
| Posted: Jul 16 2011, 06:56 PM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
Just trying it now.... it's very slow tho. Barely getting 3 frames a second!!
The frames are only 720x480.
I'm only setting audio to MP3 @16oKBps Stereo.
The only video stuff I'm using is xVid and greyscale filter.
It seems to be working for the moment but it's terribly slow.
Running 32-bit XP Pro, 4GB DDR3 Ram, Intel QX8400 Core2-quad using all 4 cores.
Just checked CPU usage - barely 4%; but it's smashing the hard drive to hell and back!! 
It's a 1TB Sata3 drive so I didn't expect VD to be HD-bound as much as this - especially as it's only barely managing 3fps.
Tried another Sata3 drive.... same thing.
Tried and IDE drive.... still the same.
Tried a few combinations of Sata/IDE for different in/out.
Doesn't seem to make any difference 
I don't know why these later versions seem sooo I/O bound?
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| freedomdwarf |
| Posted: Jul 16 2011, 10:35 PM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
UPDATE
It finally finished!!!! 
It did speed up just a little bit but it took 2 hours 28 mins to recode this small 26min episode.
I used MediaInfo and this is what it reported for the original and recoded AVI -
Original Input File | QUOTE | | CODE | General
Complete name : X:\TV Series\Joe 90\01-01 - The Most Special Agent.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 162 MiB
Duration : 25mn 25s
Overall bit rate : 888 Kbps
Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 2
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 25mn 25s
Bit rate : 686 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 25.000 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.079
Stream size : 125 MiB (77%)
Writing library : XviD 1.1.2 (UTC 2006-11-01)
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Codec ID : 55
Codec ID/Hint : MP3
Duration : 25mn 25s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Delay relative to video : 26ms
Stream size : 34.9 MiB (22%)
Alignment : Split accross interleaves
Interleave, duration : 40 ms (1.00 video frame)
Title : Audio Stream |
|
VirtualDub Output File | QUOTE | | CODE | General
Complete name : X:\TV Series\Joe 90\Recode\01-01 - The Most Special Agent.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 128 MiB
Duration : 25mn 25s
Overall bit rate : 702 Kbps
Writing library : VirtualDub build 34610/release
Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 25mn 25s
Bit rate : 564 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 25.000 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.065
Stream size : 103 MiB (80%)
Writing library : XviD 64
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Mode : Joint stereo
Mode extension : MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 25mn 25s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 23.2 MiB (18%)
Alignment : Split accross interleaves
Interleave, duration : 40 ms (1.00 video frame)
Interleave, preload duration : 501 ms |
|
From what I can see, it didn't do anything really complicated or go thru a load of filters to slow it down to such a degree.
I don't remember earlier versions of VD being this disc intensive!
The CPU load barely flickered above 4% but I noticed the input/output video wasn't in sync for most of the re-coding period.
The output video window seemed to be several frames behind the input window.
I tried running a conversion directly through VD (ie, not via Job Control) and I aborted it after 10 minutes as the target and estimated time were almost identical to the JC version and was just as disc intensive.
Just out of curiosity, I used AVS4You v8.0.1.492 and re-coded it into a similar AVI container.
It took just 13 minutes 6 seconds and I don't rate this utility as being particularly quick at converting stuff!
The disc activity could hardly be seen - it barely showed the HD activity light.
The CPU load showed 28-30% during this conversion.
MediaInfo gave the following info for the AVS4You v8 output file -
AVS4You v8 Output File | QUOTE | | CODE | General
Complete name : X:\TV Series\Joe 90\Recode1\01-01 - The Most Special Agent.avi
Format : AVI
Format/Info : Audio Video Interleave
File size : 141 MiB
Duration : 25mn 25s
Overall bit rate : 778 Kbps
Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings, BVOP : 1
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Muxing mode : Packed bitstream
Codec ID : DX50
Codec ID/Hint : DivX 5
Duration : 25mn 25s
Bit rate : 640 Kbps
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 25.000 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.074
Stream size : 116 MiB (82%)
Writing library : XviD 64
Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Codec ID : 55
Codec ID/Hint : MP3
Duration : 25mn 25s
Bit rate mode : Constant
Bit rate : 128 Kbps
Channel(s) : 2 channels
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 23.3 MiB (16%)
Alignment : Split accross interleaves
Interleave, duration : 40 ms (1.00 video frame) |
|
The test I did seems to rule out anything to do with Job Control as a stand-alone direct re-code showed the same characteristics.
And in case you are wondering if I setup the last test the same as the first one - I didn't, I didn't close VD after JC had finished - so it was absolutely identical because I didn't change anything! 
So what gives with the very high HD thrashing in VD these days?
AVS4You is generally dreadfully slow so I only use it if I have to - usually to convert something from MKV to AVI before I let rip on it with VirtualDub.
The test with AVS has shown it isn't a hardware problem with my PC so it has to be something to do with what VirtualDub is doing with its disc accessing.... somewhere.
I had a similar problem when I was re-coding another TV series (Captain Scarlet) when I first hit the Job Control problem.
I put 11 episodes onto a 22GB DVD image file with Nero 9 and then used DVD-Shrink to re-code the video to a standard 4.7GB image to burn it.
I had to put it into very low priority and limit it to 2 CPU's for the process otherwise it just about froze my PC until it finished and it was still processing almost 24,000 fps - which to be fair, was only something like 3 minutes from start to finish!! 
I know it's not a good comparison but it shows how well other apps are handling similar conditions.
So... I'm a wee bit puzzled and confused to say the least. 
My favourite video tool seems to have gone down the pan. 
Any suggestions anyone? Have I found a bug somewhere?
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| freedomdwarf |
 Posted: Jul 17 2011, 04:59 PM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
I'm just trying a stand-alone re-code using VD v1.10.1trial11.
Same old DivX 6.9 video compression with grayscale filter but not processing any audio - using direct stream copy.
I did a Status Dump about 30 mins into the re-code and I was surprised at what I saw -
| CODE | =================
Processing thread
=================
Completed: No
Error encountered: No
Video push ended: No
Video ended: No
Flushing compressor: No
Codec frames buffered: 3
Video input pipe:
251/256 buffers active (251 non-preload frames)
Next buffer:
3904 bytes | srcidx 0 | stream 7525 | display 7525 | target 7525 | flags: delta | droptype 1 | final 1
Pending source frames: 251
Frame 7525 | Batch 7525 | Pending
Frame 7526 | Batch 7526 | Pending
Frame 7527 | Batch 7527 | Pending
Frame 7528 | Batch 7528 | Pending
Frame 7529 | Batch 7529 | Pending
Frame 7530 | Batch 7530 | Pending
Frame 7531 | Batch 7531 | Pending............
..........................................................
..Frame 7773 | Batch 7773 | Pending
Frame 7774 | Batch 7774 | Pending
Frame 7775 | Batch 7775 | Pending
Pending output frames: 256
Frame 7520 | Batch 7520 | Hold 0 | Null 0 | Direct 0
Frame 7521 | Batch 7521 | Hold 0 | Null 0 | Direct 0
Frame 7522 | Batch 7522 | Hold 0 | Null 0 | Direct 0
Frame 7523 | Batch 7523 | Hold 0 | Null 0 | Direct 0
Frame 7524 | Batch 7524 | Hold 0 | Null 0 | Direct 0..........
...................................................................................
..Frame 7772 | Batch 7772 | Hold 0 | Null 0 | Direct 0
Frame 7773 | Batch 7773 | Hold 0 | Null 0 | Direct 0
Frame 7774 | Batch 7774 | Hold 0 | Null 0 | Direct 0
Frame 7775 | Batch 7775 | Hold 0 | Null 0 | Direct 0
Video filter system
-------------------
Filter "grayscale":
Pending queue:
Source frame 7522 | Output frame 7522
Source frame 7522 | Pending
Source frame 7523 | Output frame 7523
Source frame 7523 | Pending
Source frame 7524 | Output frame 7524
Source frame 7524 | Pending
Source frame 7525 | Output frame 7525
Source frame 7525 | Pending..........
....................................................
....Source frame 7772 | Output frame 7772
Source frame 7772 | Pending
Source frame 7773 | Output frame 7773
Source frame 7773 | Pending
Source frame 7774 | Output frame 7774
Source frame 7774 | Pending
Source frame 7775 | Output frame 7775
Source frame 7775 | Pending |
I haven't a clue what all this means but I was wondering if VD was reading too far ahead and having to re-read stuff from the hard drive??
I know this test was only going to save me 8 minutes of re-code by doing a direct stream copy of the audio so I aborted it after 30 minutes.
I had a look through the Preferences and I think I found the answer!
Under the 'Disk I/O' section I had it set to 'Write through'.
Something I had obviously setup some time ago and didn't give it a second thought and it can't have made a huge difference at the time otherwise I wouldn't have left it on that setting.
I changed it to 'Asynchronous unbuffered' and re-run the re-code.
Jeeeeez - what a difference!!!! The time estimate was reduced from 2 hours 20 minutes to just 13 minutes 10 seconds!
...And the hard drive wasn't being thrashed to death.
So what exactly IS the 'Write through' option doing to to make VirtualDub smash the hard drive to bits?
So now I'm wondering, if 'Write through' ('slowest, but most compatible') is most compatible, what are we comparing for compatibility here??
If I leave it on 'Asynchronous unbuffered', what am I risking?
Some clues might help me to guess/decide which options to use in the future.
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| phaeron |
| Posted: Jul 24 2011, 01:21 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Although they may be odd at first glance, the defaults are usually the best unless you have an explicit reason to set otherwise.
Asynchronous unbuffered mode allows the OS to fully schedule disk operations for best performance. Write-through mode, however, tells Windows to immediately flush all writes to disk. This is slower if you are working with an uncompressed file and much slower for a compressed one. As such, you should always use asynchronous unbuffered mode.
The reason this option exists is that there are some specialized video capture setups that use custom file systems for large storage arrays and the drivers for those don't necessarily react well to the default write mode. This isn't a problem for any normal Windows machine that has partitions formatted with FAT or NTFS, or even a network drive.
|
|
| freedomdwarf |
| Posted: Jul 24 2011, 10:34 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
Thanks Phaeron.
Can you answer why we can only have ONE Job Control even if we have several instances of VD?
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| dloneranger |
| Posted: Jul 24 2011, 11:26 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Because you're using a local job list
This is stored in the virtualdub directory and multiple versions of virtualdub (run from the same directory) will overwrite each other
The solutions are
1) use multiple virtualdub directories, so each one uses a different file
2) use a shared list (selectable from the jobs dialog)
You can start virtualdub so it automatically uses a shared list by altering the shortcut's properties
You have to add the /master switch to the target line
eg
Make a new empty file somewhere like C:\Users\Public\Documents\NewVids.jobs
then, if virtualdub is at eg c:\program files\virtualdub\virtualdub.exe
Change the target from
"c:\program files\virtualdub\virtualdub.exe" /master "C:\Users\Public\Documents\NewVids.jobs"
Then, all the virtualdub's will share and use the same jobs list
You can also make virtualdub start with the shared list and begin encoding automatically
That's with the /slave switch, and would look like
"c:\program files\virtualdub\virtualdub.exe" /slave "C:\Users\Public\Documents\NewVids.jobs"
---
What I do, is have virtualdub start automatically on startup with the /slave switch
(by adding a shortcut into the startup folder, and adding the /slave switch)
And on the desktop, I have a shortcut with the /master switch
Then, I just open virtualdub form the desktop, and queue the jobs, letting the slave encode them
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| freedomdwarf |
| Posted: Jul 24 2011, 11:41 AM |
|
|
Advanced Member
Group: Members
Posts: 119
Member No.: 30166
Joined: 7-March 11
|
If I wanted a shared list I can do that easily with what I already have.
I am wanting a separate JC list for each instance of VD I'm running - however many there are.
As I mentioned before, I would have thought the spawn of JC from any particular instance of VD would have its own thread ID and hence its own JC window.
I already store the actual .jobs file inside the folders of where I'm using JC (not in the VD folder) and that's what I load each time so I was a tad disappointed that I always got the one and only JC list.
However, I can see the sense of where it's coming from in storing its own local JC file from the original EXE location so it looks like I'll have to make several copies of VirtualDub in order to do this.
Shame it didn't work as I expected. At least I have a workaround. Thanks for the info.
--------------------
Sometimes, intelligence means the obvious flies over your head! |
|
| phaeron |
| Posted: Jul 31 2011, 11:54 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
dloneranger's suggestion is the way you would handle this. The problem otherwise would be that VirtualDub would have no way of finding the job list(s) after it had exited, so you'd need to specify the job file... which is pretty much what the shared job mode does.
|
|
