|
|
| phaeron |
| Posted: Jun 13 2005, 02:16 AM |
 |
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
| CODE | Build 23538 (1.6.7, experimental): [June 12, 2005]
[features added]
* Script: Added support for cast expressions to int/long/double.
* Video direct-stream path now treats zero-byte (drop) frames as non-
essential. A video stream that has been spaced with drop frames to a
higher frame rate can now be cleanly converted down as well.
[bugs fixed]
* Fixed crash when decoding audio from broken or mismatched DV frame.
* Hierarchical AVI index blocks were being placed outside of RIFF chunks.
No known actual incompatibility cases (yet).
* Fixed occasional crash when using lowpass or highpass filters with a
large tap count.
* Fixed crash on attempting to abort a render when an error had already
occurred.
* Fixed "cut off audio stream when video stream ends" sometimes being
active even after being disabled.
* Fixed audio stream being shortened slightly when using audio compression.
* Capture: Fixed crash in volume meter code triggered by load of DLLs that
whack the floating-point control word.
* Capture: Fixed crash on exit in DirectShow layer caused by shutting down
COM too early.
[regressions fixed]
* Script: Fixed "method not found" errors loading .vcfs caused by failure
to convert longs to ints. |
|
|
| fccHandler |
| Posted: Jun 13 2005, 07:16 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE | | ...barring no major issues, the next release — 1.6.8 — will be released as stable. |
Awesome! 
But I do have one silly gripe about 1.6.x. In 1.5.10, clicking on the slider moves you to a position +/- 50 frames from where you were previously. I got really used to that behavior, so I'd like to humbly request an option in preferences to emulate the old behavior, for us old-school losers -- uh, I mean users...
As always, thank you for VirtualDub. 
--------------------
May the FOURCC be with you... |
|
| i4004 |
| Posted: Jun 13 2005, 12:54 PM |
|
|
Advanced Member
Group: Members
Posts: 2432
Member No.: 4935
Joined: 24-June 03
|
real old-skool losers use 1.4.x because it's end-point inclusive.
--------------------
my signature:
 |
|
| Loadus |
| Posted: Jun 14 2005, 03:13 PM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
I had serious crashing (v1.6.5) when frameserving to TMPGEnc. The crash happened when pressing "Stop Serving" after the job had finished. If v1.6.7 does that kind of crashing, I'll get back to this ... (It had something to do with the resize -filter?)
A strange request for Avery:
How difficult would it be to implement a 16-bit/channel TIFF I/O support for VirtualDub?
If it's too much work then you can skip this.
--------------------
deviantART behance |
|
| stephanV |
| Posted: Jun 14 2005, 09:30 PM |
|
|
Spam killer ;)
Group: Moderators
Posts: 4348
Member No.: 8917
Joined: 18-February 04
|
| QUOTE | * Video direct-stream path now treats zero-byte (drop) frames as non-
essential. A video stream that has been spaced with drop frames to a
higher frame rate can now be cleanly converted down as well. |
What does this mean? Will drop-frames always be removed with direct stream copy? Or only when down converting the frame rate?
--------------------
useful links:
VirtualDub, Input plugins and filters, AviSynth, AVI-Mux GUI, AC3ACM by fcchandler, VirtualDub FAQ |
|
| phaeron |
| Posted: Jun 15 2005, 03:29 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Only when converting to a lower frame rate. Basically, when trying to do so, and the underlying key frame structure of the video stream doesn't allow precise sampling of the video stream, VirtualDub will attempt a best-effort resample, where it will fall behind slightly and catch up at the next key frame. What this change does is make the render engine also realize that it can catch up at drop frames as well. Normally this isn't a big deal, as drop frames are rare — except when they were intentionally inserted to pad the frame rate.
|
|
| Loadus |
| Posted: Jun 16 2005, 05:49 PM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
@phaeron:
Yeah, that strange crasher still lurks in this version... 
Resize causes some strange anomaly in VDub. Sometimes after frameserving, sometimes just by changing it's place on the filters -list. I had Bugs' Gradation Curves filter on the list and added resize. Then I moved the resize's place to be before the curves -->crash. I first thought this might be with the Gradation Curves, but resize has crashed with other filters as well, even with the internal ones.
http://www.coppersky.fi/loadus/crashinfo.txt
Maybe I'm just not doing it right.
--------------------
deviantART behance |
|
| fccHandler |
| Posted: Jun 16 2005, 07:56 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I have a serious complaint.
As I've been using 1.6.7 more and more lately (rather than VirtualDub-MPEG2 1.5.10), I've noticed something I hadn't seen before now. It happens when I use the arrow keys to step frame by frame through one of my big Huffyuv-compressed capture files. It seems that if (and only if) my CPU usage hits a certain point (near 50% in task manager), both panes stop displaying video, though I'm still holding the arrow key and the slider is still moving. It also happens when scrubbing, that the panes will not get updated until I stop moving the slider.
I don't know if it's my system, or a bug in the program, or what. Heck, for all I know maybe it's supposed to do that. In any case it's a major bummer and (at least for my purposes) makes the program unusable.
Just so you know, I tried all the obvious things like turning off DirectX, HT, changing display depth, etc. (Doesn't make any difference.) It's quite obviously related to CPU load, in fact I can even duplicate it using a small video, and simply adding a bunch of filters to force my CPU usage up. I can even watch it getting worse as I add more filters.
P.S. (later) VirtualDub 1.6.6 does it too. 1.5.10 definitely does not. Damn I wish I had brought this up sooner...
This post has been edited by fccHandler on Jun 16 2005, 08:00 PM
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jun 17 2005, 04:53 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@Loadus:
This was reported before and I wasn't able to reproduce it, but I finally figured out what's causing it. The crash is occurring in the resize filter because that is one of the filters that cannot work if it hasn't been started — no resampler has been allocated. Well, what's going on is that the display panes behind the filter dialog are restarting the filter chain in order to refresh the panes, but this is happening while the dialog itself is trying to change the filter chain. I'll have to dig into it but I should be able to fix this for 1.6.8/stable.
@fccHandler:
The new scrubbing mechanism is timesliced at 1/10th intervals. If it cannot update the video frame within 0.1s it temporarily returns to the main message loop so that the program remains responsive. During this time you can still move the slider and reseek to a new frame. If you are moving forward to a new frame, it will continue decoding toward the current target but will update the next target for when the current frame is done. If you are moving backwards, it will update the target immediately but continue decoding toward that from its current point. In other words, if you hold down the right arrow, you should see a frame update rate at least as fast as 1.5.10, but the application should be a lot more responsive on files with few key frames.
I can't reproduce this, I'm afraid. The two functions involved are VDProject::UpdateFrame() and VDProject::DisplayFrame(). If you could insert traces at VDProjectUI::UIRefreshInputFrame() and the Update() calls on the drivers in VideoDisplayDrivers.cpp it would help me narrow down the cause. |
|
| fccHandler |
| Posted: Jun 17 2005, 05:30 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
| QUOTE (phaeron @ Jun 17 2005, 12:53 AM) | | I can't reproduce this, I'm afraid. |
Crap, I was afraid you would say that.
| QUOTE | | If you could insert traces at VDProjectUI::UIRefreshInputFrame() and the Update() calls on the drivers in VideoDisplayDrivers.cpp it would help me narrow down the cause. |
I will gladly do so, but at the risk of sounding utterly stupid, uh... what are these "traces" and how do I insert them? 
--------------------
May the FOURCC be with you... |
|
| phaeron |
| Posted: Jun 17 2005, 05:49 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
In a debug build, use the VDDEBUG(format, ...) macro. It outputs to Visual Studio's Output window (or to any other Win32 debugger you have attached, such as DebugView).
|
|
| fccHandler |
| Posted: Jun 17 2005, 06:38 AM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
Well, I hope I've done this right. I placed 3 VDDEBUGs, one each at the beginning of VDProject::UpdateFrame, VDProject::DisplayFrame, and VDProjectUI::UIRefreshInputFrame. Then I loaded my Huffyuv capture file, held the RIGHT arrow key for about one second, released it, and quit the program. (IIRC, it was showing frame 32 when I quit.) Here is the debug output:
http://fcchandler.home.comcast.net/trace.txt
If this isn't what you wanted, or if there's anything more I can do to help, please let me know. 
EDIT: I thought I might mention that I always set my keyboard "repeat delay" to minimum and my keyboard "repeat rate" to maximum. Perhaps that's necessary to reproduce it? (It wouldn't affect scrubbing, though. Hmmm...)
This post has been edited by fccHandler on Jun 17 2005, 07:05 PM
--------------------
May the FOURCC be with you... |
|
| fccHandler |
| Posted: Jun 17 2005, 08:14 PM |
|
|
Administrator n00b
Group: Moderators
Posts: 3961
Member No.: 280
Joined: 13-September 02
|
I think I figured this out. Thanks phaeron for teaching me about VDDEBUG, that made all the difference! I reread your previous post about VideoDisplayDrivers, and I put a VDDEBUG in the DX9 minidriver. That's how I discovered that the DX9 minidriver was still being used, even though I unchecked "Use DirectX" in preferences! (Is it supposed to do that?) The solution for me was to leave "Use DirectX" checked, but uncheck "Use Direct3D." Stupid me, that is the one thing I didn't try before. Now the DX9 minidriver is not called, and the panes are updating nicely.
Woohoo!
OTOH, that begs the question of why the DX9 driver is misbehaving on my system. (I assume it's been working for everyone else.) If I happen to discover why, I'll post it, but at the moment I'm not too concerned about it.
--------------------
May the FOURCC be with you... |
|
| Loadus |
| Posted: Jun 18 2005, 03:00 AM |
|
|
Advanced Member
Group: Members
Posts: 352
Member No.: 10881
Joined: 1-July 04
|
| QUOTE (phaeron @ Jun 16 2005, 10:53 PM) | @Loadus:
... I finally figured out what's causing it ... |
@phaeron:
Rok. You're the wizard.
--------------------
deviantART behance |
|
| phaeron |
| Posted: Jun 18 2005, 06:44 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
@fccHandler:
I'm impressed. You managed to expose on not one, not two, but three bugs:
- The ANDing of the DirectX option with the subordinate options is only UI-side, so if you check the Direct3D option and then uncheck the DirectX option it still tries to use D3D.
- I left in some debug code that limited the D3D bicubic code to the 3-texture (RADEON 7xxx) path, disabling the pixel shader modes.
- The D3D driver is missing a call to UpdateWindow() after the InvalidateRect() call. WM_PAINT messages are dispatched only when the message queue is otherwise empty, so if the message loop is running slowly enough that new input is always arriving, windows don't repaint.
I will fix all of these for 1.6.8.
|
|
