|
|
| 4N4 |
| Posted: Jun 17 2012, 11:41 PM |
 |
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
Whatever you do to the forum worked as it's now wrapping.
Re. slowdown, I can't promise anything, but if I get some free time I'll give the real-time profiler a go. |
|
| -vdub- |
| Posted: Jun 20 2012, 12:39 AM |
|
|
Advanced Member
Group: Members
Posts: 613
Member No.: 27087
Joined: 24-February 10
|
The fix phaeron has done for this now making other forums look poor in comparison  |
|
| 4N4 |
| Posted: Jun 22 2012, 03:57 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
| QUOTE (phaeron @ Jun 17 2012, 10:06 PM) | | if you're adventurous and still willing to track this down, the real-time profiler is probably the best bet. It takes a bit getting used to, but it will show you exactly which parts of the pipeline are taking time. Mouse wheel, arrow keys, and Alt+left-drag are used to navigate it. |
If you start a job, the Real-time profiler menu option is not available, and the keyboard shortcut doesn't work either. Is it possible to bring up the profiler window once a job is running ?
Can you give a bit more info on what I should be looking for ?
I see two lines in the profiler. They both start with a ~0.10 sec Audio block, then the top line has a ~0.05s Audio block every ~0.10 secs (gap varies slightly). The second line consists of multiple V-Decode->small gap->resize->V-BltOut->V-Compress blocks.
Should I just make a note of average time taken for each stage of the pipeline in line 2, and then see which stage is taking longer than usual in the second job (ie. this stage is causing the longer processing time) ?
BTW, forum e-mail notification doesn't appear to be working (at least for me) - I'm subscribed to this topic but don't receive an e-mail when someone replies. Are they working for you ?
|
|
| phaeron |
| Posted: Jun 24 2012, 03:45 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Spam blocking has been a frequent issue with the forum notifications -- make sure your email address is correct and add forums@virtualdub.org to your spam whitelist if you have one.
What you are looking for in the profiler is the bottleneck, i.e. which blocks are the longest. The length of each block represents time, so a longer block means that portion of the pipeline is taking longer. In particular, what we're looking for here is a block which is longer in the bad case than in the good case. Of the blocks you've indicated, V-Decode is video decode, resize is the resize filter, V-BltOut is an output frame conversion, and V-Compress is video compression.
The different lines correspond to different threads, so what you're seeing is the audio thread doing a little work here and there and the video thread being the throttling factor. If you have threading enabled in VirtualDub for the various functions, you'll see some blocks moved out to their own lines and running at the same times as others, which indicates multithreading. This will only show multithreading within VirtualDub itself, as it doesn't have visibility into any threading that filters, plugins, or codecs may be doing.
Unfortunately, you can't bring up the profiler after a job has started, as it's too late for the profiler to init then.
|
|
| 4N4 |
| Posted: Jul 14 2012, 08:15 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
Finally had some free time to look at this and, on the second slow job, it's the V-Compress that's taking longer (maybe 3 or 4 times longer, although the amount varies per frame).
There also appears to be a bug in the profiler as while zooming in/out and dragging left/right the profiler has hung several times with the title saying Not responding and CPU usage higher than normal. The window goes blank (ie. white) when this happens. The profiler hanging does not stop the encode from progresing though. |
|
| phaeron |
| Posted: Jul 14 2012, 09:55 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Okay, try this:
Close VirtualDub, then manually edit the VirtualDub.jobs file. Find every video.SetCompression() statement, and add a new one before it so you have something like this:
| CODE |
VirtualDub.video.SetCompression();
VirtualDub.video.SetCompression(0x6376736d,0,10000,0);
|
What this will do is force VirtualDub to unload the video codec before reinitializing it for the next job. Ordinarily this isn't a good idea as it can foul two-pass processing, but in this case it may be the only way to work around the problem you are seeing. If this works, then I can add an option to do this. In the meantime, I'll see if I can track down the issues with the profiling UI.
|
|
| 4N4 |
| Posted: Aug 8 2012, 09:45 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
Unfortunately that didn't work either.  The first job took ~40 minutes (with an initial video rendering rate of ~75 fps, although it fluctuates between 50-80fps) and the second job has an ETA of over 4 hours (with an initial video rendering rate of ~10 fps). The only sure-fire way to get full-speed is to restart VDub.
I'm wondering if I'm the only one experiencing this slowdown when converting to XviD and MP3, or whether it's happened to other people but they just haven't noticed.
On an unrelated note - While saving a job file, the save dialog is set to only show .jobs files, but if I only put the filename without a .jobs extension and save, the .jobs extension is not automatically added. |
|
| dloneranger |
| Posted: Aug 9 2012, 07:51 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
You've had 370+ views so far, and nobody's added "me too"
I don't have any problems like yours either
So here's a few random thoughts
You could do a double test, queue the same job twice and see if the take the same time - they should be pretty close
Does it happen with just .flv's?
Is it the encoding or decoding that's the problem?
You've mentioned you tried encoding with a few different codecs and are having the same problem with them all?
You can test that the decoding's not causing the problem by setting the encoder to 'uncompressed' and queuing a few 'run video analysis pass'
If the second one's slow doing that, then it's a decoding problem
And lastly have you checked it's not something like cpu throttling because the pc's getting too hot after an hours encoding?
HWMonitor (and others) can show your cpu temperatures, and the min/max values reached
You can start the monitor before you start encoding and leave it running while the encoding is going on, then you can see the difference between idle and maximum
http://www.cpuid.com/softwares/hwmonitor/v...ns-history.html
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| 4N4 |
| Posted: Aug 9 2012, 04:59 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
| QUOTE | | And lastly have you checked it's not something like cpu throttling because the pc's getting too hot after an hours encoding? |
I thought you might be onto something with the CPU being throttled, but that's not the case.
| QUOTE | | You could do a double test, queue the same job twice and |
Second job is much much slower with the same job (eg. 1st job averages 65-70 fps, 2nd job starts and averages 11 fps).
I'll try some of your other suggestions and post back here, but I'm pretty sure it's a problem with the video encoding part. |
|
| dloneranger |
| Posted: Aug 9 2012, 05:39 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
There's no encoding going on if you've set the compressor to uncompressed, and run a video analysis pass
All that's happening then, is reading from the disk, decoding the video and then virtualdub throws the decoded frame away
So I'd think that kind of narrows it down to decoding or temperature
Are they all flv's or does it happen with every type of file
Does it happen with two really short clips? eg 30 seconds long
If it does then heats not a problem as it shouldn't have time to get all that hot
Just out of curiosity, what temps did you get?
Here I go from 28C at idle to 40C at full load
(And this pc is normally encoding 24/7)
One other thing, and I'm sorry if it sounds like a dumb question, but it'd be silly not to double check
The first and second videos are not first-pass and second-pass in the codecs settings are they?
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| 4N4 |
| Posted: Aug 9 2012, 06:17 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
It's not just the second job that can be slow - on my latest test, the first job started fast (between 60-85 fps), but after 34-35 minutes (81% complete) it suddenly drops to about 11-13 fps and stays there for the rest of the encode. However, a previous test with the same job stayed between 60-85 fps for the entire encode.
The latest test is with an .flv (AVC1 640x356x24bits + AAC Stereo 44100 Hz)
I will try encoding to a different video (and audio, if necessary) format to see if that changes anything. |
|
| 4N4 |
| Posted: Aug 9 2012, 06:23 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
I accidentally quoted your entire post rather than just the bits I had tested - fixed now.
I haven't tried the uncompressed + video analysis yet, but I'll do that next.
Max temps I got was 75C, but this is overclocked CPU but that's within expectations as it's overclocked, and I verified via CPUID that it wasn't throttled.
Re. jobs, they both use exactly the same processing settings, although as I've just mentioned in my previous post, I have now noticed a slow-down near the end of the first job. |
|
| dloneranger |
| Posted: Aug 9 2012, 06:34 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
That really does sound like a heat problem, there's no reason it should slow down in the middle of an encode that I can think of apart from that
You could check the core speeds with cpuz
http://www.cpuid.com/softwares/cpu-z/versi...ns-history.html
It shows the core speed and multiplier in real time
If these change (more than a few mhz either way) if would be a sign of throttling
Although, there's some reports of intel chips slowing themselves down in a way that doesn't show up like that
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| 4N4 |
| Posted: Aug 9 2012, 06:57 PM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
I meant to say CPUZ rather than CPUID - it didn't show any sign of throttling during the encode. Plus, if I let the CPU cool down a bit before running the same job again, the second job will usually start encoding at ~12 fps, so I'm pretty sure throttling is not the issue.
Two video analysis jobs both completed in the same time with average of 250 fps.
I will now try encoding using different video codec. |
|
| 4N4 |
| Posted: Aug 10 2012, 01:14 AM |
|
|
Advanced Member
Group: Members
Posts: 31
Member No.: 34901
Joined: 20-May 12
|
It looks like the XviD encoder is the problem as with a quick test using ffdshow's FFV1 encoder I got approx. 55 fps throughout job 1 and 55 fps at the start of job 2 (I only let it run for a short time).
I will try with DivX next. |
|
