| Printable Version of Topic
Click here to view this topic in its original format |
| Unofficial VirtualDub Support Forums > News / Announcements > VirtualDub 1.6.7 (23538) |
| Posted by: phaeron Jun 13 2005, 02:16 AM | ||
|
| Posted by: fccHandler Jun 13 2005, 07:16 AM | ||
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.  |
| Posted by: i4004 Jun 13 2005, 12:54 PM |
real old-skool losers use 1.4.x because it's end-point inclusive. |
| Posted by: Loadus Jun 14 2005, 03:13 PM |
| 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. |
| Posted by: stephanV Jun 14 2005, 09:30 PM | ||
What does this mean? Will drop-frames always be removed with direct stream copy? Or only when down converting the frame rate? |
| Posted by: phaeron Jun 15 2005, 03:29 AM |
| 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. |
| Posted by: Loadus Jun 16 2005, 05:49 PM |
| @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. |
| Posted by: fccHandler Jun 16 2005, 07:56 PM |
| 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... |
| Posted by: phaeron Jun 17 2005, 04:53 AM |
| @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. |
| Posted by: fccHandler Jun 17 2005, 05:30 AM | ||||
Crap, I was afraid you would say that.
I will gladly do so, but at the risk of sounding utterly stupid, uh... what are these "traces" and how do I insert them?  |
| Posted by: phaeron Jun 17 2005, 05:49 AM |
| 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). |
| Posted by: fccHandler Jun 17 2005, 06:38 AM |
| 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...) |
| Posted by: fccHandler Jun 17 2005, 08:14 PM |
| 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. |
| Posted by: Loadus Jun 18 2005, 03:00 AM | ||
@phaeron: Rok. You're the wizard. |
| Posted by: phaeron Jun 18 2005, 06:44 AM |
| @fccHandler: I'm impressed. You managed to expose on not one, not two, but three bugs:
I will fix all of these for 1.6.8. |
| Posted by: fccHandler Jun 18 2005, 07:03 AM | ||
Again, awesome! Glad I could help. |
| Posted by: Gral Jun 20 2005, 08:37 PM |
| Please add the option to change mouse wheel behaviour, to work as in earlier versions, before 1.6.0. |
| Posted by: phaeron Jun 21 2005, 03:54 AM |
| Gral: Mind explaining further? The only change I know of in 1.6 with regard to the mouse wheel was to fix a bug that caused it to stop working beyond frame 32767. |
| Posted by: Gral Jun 21 2005, 11:02 PM |
| Scroll direction is different than in earlier versions. |
| Posted by: phaeron Jun 22 2005, 04:07 AM |
| Ah, that I can fix. |