|
|
| evropej |
| Posted: Dec 21 2013, 05:24 PM |
 |
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Ok, so I have a chain of filters which seems to crash randomly and I am curious now which filter is causing it. So I got a de-assembler program to find out who is causing the issue. Since I am a newbie, I am having a problem with finding out when filters are used.
Can someone help here and suggest at which point does virtualdub call a filter and how? Like USER32:Messagebox or something similar? Any help is appreciated.
Also, does anyone have a video of how virtualdub is compile and with what software?
Thanks
 |
|
| dloneranger |
| Posted: Dec 21 2013, 05:48 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
It's compiled with visual studio plus a few other bits and pieces
http://forums.virtualdub.org/index.php?act...ST&f=11&t=17993
anything after version 2008 will cause problems though
Each filter has a few entry points that virtualdub calls
paramProc -> for configuring/setting up the filter, where the filter negotiates which formats it accepts etc
runProc -> that proccesses each frame
The virtualdub sdk gives help on those and the others
What crash are you getting?
The crash log should give useful information
Notes:
The filter that crashes might not be the cause of the problem, an earlier one could give back bad data that causes a later one to die
Old filters might need the 'single buffer' option enabled in the filter list dialog as they might not handle the newer method of running - msu's filters are prone to this
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| evropej |
| Posted: Dec 21 2013, 07:05 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Thanks for the info!
Its different filter combinations of MSU, warp sharp, smoother, etc. They crash randomly. Sometimes single buffer helps but in general it does not. Some filters from MSU specifically are sensitive the video sizes. For example 720p is fine but 4kp is not.
So now I wan to start running vdub in a debugger mode to see what filter is the culprit but the assembly language is a huge learning curve. I am looking for entry points to put break points.
PS Can I put a message in the filter itself where the entry point is to help debugging or is it compiled? |
|
| dloneranger |
| Posted: Dec 21 2013, 08:22 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
I guess you could, but have no idea how you'd find the place to easily put a breakpoint
It's all returned classes and function tables.......
I'd do it from inside vs2008 while debugging virtualdub itself, searching for filter->runproc and then trace the assembler from there as that's where it jumps into the 'process a frame' code
You'd have to read the sdk for other entry points like paramProc etc
I don't envy you, even if you find the problem, trying to fix it would be a nightmare
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| evropej |
| Posted: Dec 21 2013, 08:56 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
I am not going to try and fix it, I just want to see which one causes issues.
I just installed vb2008 express and I cant see a dang thing in there when attached to a process.
I need to do some googling or just use what I have now. |
|
| dloneranger |
| Posted: Dec 21 2013, 09:12 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
On the full visual studio its on the tools menu - can't say if express can do that or not
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| evropej |
| Posted: Dec 24 2013, 05:36 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Question, how does virtualdub render each frame on the screen?
Does the filter do the calculations and load them pixel by pixel or does vdub load it at the end? If so, how can I find this?
I am finding it hard to de-tangle the mess lol.
|
|
| dloneranger |
| Posted: Dec 24 2013, 06:36 PM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
The filters etc get a VDXFilterActivation variable. They use the info there to access the pixel data
I'll just use the 'run' part of my multiadjust filter here
| CODE |
void MultiAdjustFilter::Run()
{ // in paramproc I've said I want to use source and a separate dest pixmap
const VDXPixmap &pxdst = *fa->dst.mpPixmap;
const VDXPixmap &pxsrc = *fa->src.mpPixmap;
|
Then it depends on the format of the data (rgb24/32, yuv420 etc)
VDXPixmap has these variables
| CODE | struct VDXPixmap {
void *data;
const uint32 *palette;
sint32 w;
sint32 h;
ptrdiff_t pitch;
sint32 format;
// Auxiliary planes are always byte-per-pixel.
void *data2; // Cb (U) for YCbCr
ptrdiff_t pitch2;
void *data3; // Cr (V) for YCbCr
ptrdiff_t pitch3;
}; |
data is the start address of the first horizontal line of pixel data
pitch is the amount to add to data to get to the next line - because lines may be aligned, you don't just add width*number of bytes per pixel
format is virtualdub' format number for rgb24/32, yuv420 etc
data2/pitch2 and data3/pitch3 and for multiplane formats like yuv420 -> data will be Y, data1 is U and data3 is V (or is that V then U....)
Then you have the same for dest, if you're using two pixmap buffers
You can just use 1 buffer (specify in paramproc) - and then you read/write to the source one
or you can use 2, then you read from src and write to dest
So, virtualdub reads a pixmap from the source video
passes that to filter 1, and gets back the same one, or the new dest one
then that's passed to the next filter etc (repeat for all filters...)
until all the filters are done and the last returned pixmap is put on the screen or passed to the compressor for saving
With multithreading there could well be lots of those happening at once
eg filter1 is doing frame 4, filter2 is doing frame 3 (that it got from filter1), filter3 is doing frame 2 (that it got from filter2) etc etc
Some things that can go wrong off the top of my head
Filter assumes it's always getting the same pixmap/buffer
- when multithreading was introduced it changed the way filter got a pixmap. they used to get the same one over and over again, now, they're moved around and given to different filters
- nobody ever said they were going to be the same, but as they were, some people just assumed they always would be, so instead of doing it the right way they wrote code that breaks with the new way of doing things
- the 'single buffer' option was introduced to try and fix this -> yes MSU filters, I'm looking at you!
Some filters assumed that pitch would always equal number of bytes per pixel*width
- back when virtualdub was rgb only then it just so happened that this was true
- by ignoring the pitch variable that filter now is broken.... lazy programming
Using the wrong variable types for data and pitch
- using a signed data type for data will fail if data ever goes over 2Gb -> negative address... oops
- pitch is signed, as the pixmap could have an upside down layout
Misc errors
- for x/y=0 to w/h instead of the correct for x/y=0 to w/h-1
- using a static variable that gets corrupted when the filters being multithreaded
- assuming src and dest variables will be the same and using eg src pitch to increment dest data ptr
- MSU gets lots of callouts here with plenty of bad programming practices ->msu smart deblock, changing the height can make it crash as it's unhappy without multiples of 8 for the height and width even though it's using rgb32
- MSU filters for being generally half-assed about things - good ideas poorly implemented
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| phaeron |
| Posted: Dec 28 2013, 10:19 PM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
If you are having problems with filters crashing randomly, there is another thing you can do to help isolate the problem. Spelunking around in code is actually unlikely to reveal the issue unless it's obvious, and will take a lot of time regardless.
Download the Debugging Tools for Windows package:
http://msdn.microsoft.com/en-us/library/wi...v=vs.85%29.aspx
...and run the Global Flags program. You'll need the x86 version for 32-bit VirtualDub and x64 for 64-bit VirtualDub. Switch to the Image File tab, and type VirtualDub.exe or Veedub64.exe into the Image line, then hit Tab, then check Enable page heap, then hit Apply. Then, run your tests. What this does is enable a diagnostic mode in Windows that does extra checking for certain types of memory errors. It makes it more likely that if a filter has a memory trashing bug, the crash will happen in that filter instead of somewhere else.
The main downside of this is that it makes VirtualDub take a lot more memory and run quite a bit slower. Make sure you uncheck the page heap and click Apply again so you don't accidentally leave it on. Another downside is that any memory error will cause a crash, so it's possible that it may end up tripping on some minor error that's not what's causing your problems.
I have private PDB symbols archived for all released versions of VirtualDub and can provide them on demand if you need them for debugging... but honestly, you won't get much more out of that than you would with just the built-in call stack decoder.
|
|
| evropej |
| Posted: Dec 29 2013, 05:10 AM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Thanks for the help so far.
I was not hoping to see the code which is causing the errors.
I was hoping to run the program in some kind of debugging mode where I can step through the executable and see at which point the program crashes.
I was going to set breakpoints at each filter and step through each function to see where it craps out or at least this was the theory.
The truth of the matter is that things are a lot more complicated under the hood.
I will keep digging into this while I have free time but it honestly seems like the scope is growing really big lol.
|
|
| evropej |
| Posted: Dec 30 2013, 05:29 AM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Resize and msu deblocking just dont like each other. This is the filter combination which is causing the crash at this time which I am interested. Single frame buffer is not working either. So frustrated! lol
I can almost guarantee that its due to programming with don't care conditions. I had a professor in college who told me "dont validate the data prior to processing, it takes too much time". He was right, for the coder and dead wrong for the end user. |
|
| dloneranger |
| Posted: Dec 30 2013, 09:14 AM |
|
|
Moderator
Group: Moderators
Posts: 2366
Member No.: 22158
Joined: 26-September 07
|
Try and make sure your frames are multiples of 8 for msu smart deblocker - that usually works for me
--------------------
MultiAdjust JoinWav WavNormalize FFMPeg Input Plugin v1827 UnSharpMask
Windows7/8 Codec Chooser
All FccHandlers Stuff inc. Installers for acm codecs AAC, AC3, LameMp3 |
|
| evropej |
| Posted: Dec 30 2013, 11:23 AM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
Tried it, multiple of 8 when resizing. The crashes are so bad that I cant even close vdub after the crash. Bad joo joo. |
|
| evropej |
| Posted: Jan 14 2014, 08:57 PM |
|
|
Advanced Member
Group: Members
Posts: 514
Member No.: 26523
Joined: 28-November 09
|
So I did narrow it down to the MSU filters plus warp sharp.
I think the guys who wrote the MSU filters did not expect video sizes of dimensions greater than what was available at the time combined with careless programming such as dont care conditions or not validating data prior to using it.
Its a shame at the end of the day because these filters have a lot of potential.
Weird side effects: if you save the settings and close thing down, the filter combination migh work. If you try to set the filters up and then run them, they crash. |
|
