> The next step would be to add support for the new formats
> to the video source and display paths, which should finally
> get some of these new formats into a usable path.
Please, consider formats with alpha channel.
Could be useful for loading 32bit PNG/TGA image sequences.
MaxS - 18 10 09 - 18:18
Hehe, I would rather see some new formats in the file save dialog. Hail MKV!
Mirage - 20 10 09 - 06:53
I've been using VirtualDub since version 1.7 or 1.6 even. Even today it's my first and most used video editing tool.
I really do appreciate your great work.
That being said, I'd love to see, in the foreseable future, a pure recording tool a la Fraps.
Just simple on-the-fly uncompressed screen- and soundrecording including full-size/half-size option and FPS limitation 15fps, 25 fps, 29.97fps, 30fps, variable fps.
I know VirtualDub has it, but I'm talking Fraps-equivalent for GAMES recording. VirtualDub is unsuitable this way.
Though I can record uncompressed audio and video, it takes forever until VirtualDub reacts after I finished recording, for example, a 10 min. clip of a pc videogame gameplay.
The downsize of Fraps is clearly, since it allows 1:1 recording, a huge drop in FPS and huge demand on GPU/CPU, since it records everything in real-time.
Like I said, in foreseeable future, if ever, I'd like to see something like that developed by your hand! You clearly have experience in this field!
Again, love and appreciate your work for VirtualDub since 1.6!
NoCanDo - 20 10 09 - 18:53
Unfortunately, that's one thing that I'll probably won't be doing.
The reason is that it's a huge undertaking. Windows doesn't provide any good hooks for doing recording at the level that Fraps does, and therefore the only way it can be done is by hooking APIs -- which is made complex by the number of potential APIs involved, as well as issues with dealing with copy protected games and differences between OS versions. It's also something that has actively gotten more difficult over time as Microsoft increasingly sees such techniques as security holes to close, or at the very least not to support. So, sorry -- not something I should really take on.
Phaeron - 20 10 09 - 19:04
Eventually, someone might try to convince Microsoft to actually add system-level support for that so that nobody needs to hack into the system to do that.
Kasuha - 20 10 09 - 20:54
Oh well, that's ok. Eventually somebody might take on where Taksi left ( http://taksi.sourceforge.net
I know I would had I got the time and motivation.
NoCanDo - 22 10 09 - 01:28
There's a reproduceable bug causing crashes all over.
I'm using Win 7. And I have a 7.2 gb uncompressed video-file, which I recorded with Xfire.
Now, when I start transcoding and the moment when I press ctrl+alt+del the crash happens. Or the moment this UAC (user account controll) box pop-ups when you want to start an unsecure application the crash happens.
Maybe I'm not alone. Just letting you know. I sent you my crashlog.
NoCanDo - 22 10 09 - 03:28
Some issues I noticed in this new version:
1. The interlace filter still uses ambiguous even/odd field language for the field order selection.
2. The IVTC filter doesn't seem to work correctly. For example:
Frame input = (AT,AB) (BT1,BB) (BT2,CB) (CT,DB1) (DT,DB2) (AT,AB) (BT1,BB) (BT2,CB) (CT,DB1) (DT,DB2)
Filter settings = reduce frame rate, top field first, first combed frame 2
Expected output = (AT,AB) (BT1,BB) (CT,CB)
(DT,DB2) (AT,AB) (BT1,BB) (CT,CB) (DT,DB2)
Actual output = (AT,AB) (BT1,BB) (DT,DB1)
(DT,DB2) (AT,AB) (BT1,BB) (CT,CB) (DT,DB1)
The first problem I see is the first group does not have a C frame at all, but it has 2 D frames. This only happens in the very first group and not any subsequent groups.
The second problem I see is that the output D frames in subsequent groups are produced by separating and recombining fields. This is completely unnecessary and produces "dirty" D frames. It's not a problem if you're working with RGB color, but if you're working with MPEG color, you get color bleed from the C frame into the D frame. Only the C frame should be produced by recombining fields.
MtYt - 22 10 09 - 09:51
Oi! It's me again. I found the problem to my crashes. It's the 3D acceleration! When I turn off Preferences -> 3D accel everything works just fine!
Thought I'd share it with ya, might be helpful.
NoCanDo - 22 10 09 - 20:10
I'll take a look at the dumps.
I think I've figured out what's causing the error at the beginning of the video stream, but I'm confused about the second part. Yes, it's probably slightly suboptimal to select the reassembly case instead of the frame case, but it should not be causing chroma crosstalk between frames. The only way that can happen is if you are using an image format that doesn't properly separate field chroma to begin with, like 4:2:0. I don't know what you mean exactly by MPEG chroma, but if you're pushing through 4:2:0 interlaced as YV12, that's your problem (YV12 is progressive).
Phaeron - 26 10 09 - 19:27
Once VirtualDub be able to read/write MKV... I gonna say "nothing matches VD". VirtualDubMod makes a good try though but it is soooo buggy exactly in MKV IO part :(
Besides other bugs.
SamePaul - 27 10 09 - 03:38
I must admit I don't really know how these luma/chroma color spaces are supposed to work, but it looks to me like VD is converting YV12 color in a way that makes it impossible to perform the pulldown removal correctly on YV12 material.
Here's the situation:
I have a DVD that I'm trying to convert for playback on a portable device. I'm using fccHandler's MPEG-2 plug-in to load the video in VD. When I removed the pulldown, I was unhappy with the result because 2 out of every 4 frames (the C and D frames) had color bleeding (especially in spots where the camera changes angles adjacent to a C frame).
So I used the VD frame server to load the video in an AVS script since AviSynth gives me exact control over the pulldown removal pattern. I used AssumeTFF().DoubleWeave().SelectEvery(10,0,2,5,8) to remove pulldown. That fixed the D frames, but the C frames still had color bleed.
Then I used VD to crop out a piece of the movie (on a 5 frame boundary to preserve the pulldown pattern) and saved it to an uncompressed avi (no filters -- just load, crop, and save). Then I loaded that avi file in an AVS script and -- lo and behold -- the C frames were now good. I loaded the same piece of the movie in the AVS script using the VD frame server just to be sure the timeline cropping didn't have something to do with it, and the result was bad C frames again as I expected. After further checking, I found that VD was converting frames to RGB color whenever I used the frame server -- something it doesn't do when I save to avi.
So, I have 2 questions. Is it possible to use the IVTC filter to remove pulldown on YV12 video without color bleed? Is it necessary for the frame server to convert frames to RGB color?
Thanks for your help.
MtYt - 27 10 09 - 09:23
You cannot perform pulldown on YV12 material, because the YV12 FOURCC is always progressive and thus the vertical subsampling causes field crosstalk. Some programs allow you to pass 4:2:0 interlaced material as YV12, but that is a misuse of the YV12 FOURCC. (The very first problem: whose definition of interlacing? DV and MPEG-2 use different chroma interlacing methods.)
The frameserver indeed currently always transfers data as RGB.
Phaeron - 27 10 09 - 15:06
I would love to see some optimizations regarding multi-core cpus - as this really slows done vdub unnecessarily. A good starting point would be to optionally allow the job list to process several jobs at the same time - that would help to improve total through-output and should be easier to implement than true multi-processing. What do you think, Phaeron?
Robert Niessner - 29 10 09 - 04:23
I saw 2 questions on MKV support being skipped, so I will ask again: is there any work in progress on it? I don't expect people will hold the breath for it, I know you are doing this for passion and you are working as the time allows you, but at least it is a valid question on making VD a bit more modern. I think many people use VD as their primary transcoding tool, I am using it to edit the material from my DV camera and the option to create MKV files directly with some H.264 encoding is making it much easier.
AdrianB1 - 29 10 09 - 22:20
1) I don't answer every question. Sorry.
2) There are serious roadblocks to MKV support, the main one being that it is a codec nightmare.
Phaeron - 30 10 09 - 15:37
it wasn't question :) just hope it would be there. Pity it wouldn't...
@Phaeron can you explain a bit more about "codec nightmare"? What is so bad in MKV that makes it look "monster" in front of AVI?
SamePaul - 01 11 09 - 14:13
Two causes, one directly related to MKV and one not.
The first is the sheer feature set -- MKV simply supports a lot more than AVI, such as chapters and subtitles. This leads to inherently higher complexity in supporting it. I call this the TIFF Problem, after similar issues faced by supporters of the Tagged Image File Format -- which is easy to write because it supports everything, and hard to read because it supports everything.
The second problem is that there is no easy binary codec API, at least on Windows, to decode and encode audio and video in an MKV file. With AVI, original path was Video for Windows, and now it is DirectShow. This abstraction is very important because it means that an application can support container formats without having to have special code for each format involved, which sometimes also involves legal issues. MKV lacks this level of abstraction due to not having an associated codec API and not having a directly defined conversion between formats in an existing API format and the structures in the MKV file. The last time I looked at this, some of the format structures in MKV for popular formats were essentially *undocumented* and could only be determined by either reverse engineering existing files or looking at code. I had heard that there was an attempt to establish an accompanying binary codec API, but unfortunately it did not succeed. There appear to be three paths for supporting MKV nowadays:
1) Integrate your own support. This generally only works for specific formats that the application is targeting and is not future proof, i.e. applications must be updated to support new formats in the same container. This also leads to fragmentation in the format when various applications don't support features correctly, the risk of which is increased in this case.
2) Use an existing library. The main library for this purpose appears to be ffmpeg, which is unfortunately unusable in many cases, one reason being compiler mismatch (I believe building its codecs with VC++ results in a severely lower performing library due to disabled optimizations). This too has similar issues with forward compatibility.
3) Use DirectShow codecs. This is the method used by several common players in Windows, such as Media Player Classic, and has the benefit that the user can upgrade the codecs and splitter filters independently of the application. The downsides are the need for an external component (commonly ffdshow) and that it may not work for encoding (I haven't looked at this possibility).
What it comes down to is that VirtualDub's development has always depended on me not having to maintain or link in support for every format that it needs to support, but being able to pull in external codecs to do so. I've had to do so in some cases, such as DV, but this greatly raises the effort and problems involved in developing the program, and the current situation leads me to believe that it is not viable to include support for the current crop of formats in the program itself (H.264 + AAC). That's the reason why I added support for input plugins a while back, and am looking at doing output plugins next. Even doing this, though, involves some serious integration problems, and the more components that are in the pipeline, the more of a stability and support problem it becomes. This is not at all easy to set up in general, and it's even harder when trying to deal with an existing architecture.
Basically, this isn't a question of just including a header file and adding an MKVOpen() function -- it's a huge amount of work, probably involving higher DirectShow integration, which frankly is one of the flakiest APIs on Windows I've ever head to deal with (it's unbelievable how many crash reports I receive in the *open dialog* due to broken DShow codecs). In addition, I also have a lot of users who are requesting features that having nothing to do with MKV, because they aren't working with MKV files -- they're working with uncompressed or lightly compressed HD source. So, sorry that I don't have this support yet -- but it's not a switch that I just flip.
Phaeron - 01 11 09 - 15:28
I understand. And never thought it would be easy. Technically native code support would be hard work indeed and I didn't mean it when asked for MKV. Definitely my idea was the 3rd option you mentioned - DirectX.
Writing MKV is simple because "it supports everything". Your words :) Actually can me achieved with DirectX muxers as well.
I assume that VD could use DirectX for splitting file into elementary streams without decoding. And VD already know how to deal with elementary streams, I guess.
The most tricky part here is:
* provide time-accurate stream cutting (which is not always trivial with the H264 streams, i believe).
* appending segments. Main problem not with the video/audio, but with all this stuff like chapters, bookmarks, menus etc. Although for VD being video-editing tool you can easily drop support for anything except video & audio. Well, maybe subtitles as well, but not a must. Though mixture of "DirectShow source + oldschool AVI source" would be real mess anyway.
* decoding video/audio. As I understand in VD you always used VFW for this. I guess DirectX here is inevitable.
In general I never thought about adding support for new containers gonna be simple. But when you wrote "new formats" I though you were talking about new containers, which would be really giant step ahead.
Of course someone could say "there is AviDemux, go with it", but AviDemux still rather "linear transcoder" than real editor.
SamePaul - 08 11 09 - 16:28
According to cppcheck there's a resource leak and two memory leaks in the source:
[c:\VirtualDub-1.9.7-src\src\Asuka\source\utils.cpp:143]: (error) Resource leak: f
[c:\VirtualDub-1.9.7-src\src\VirtualDub\source\Mpeg.cpp:1716]: (error) Mismatching allocation and deallocation: AudioSourceMPEG::pkt_buffer
[c:\VirtualDub-1.9.7-src\src\VirtualDub\source\Mpeg.cpp:1724]: (error) Mismatching allocation and deallocation: AudioSourceMPEG::pkt_buffer
Adding a fclose(f); and some missing  will fix those.
Kidman - 09 11 09 - 00:01
DirectX -- or really DirectShow -- doesn't make things much easier. It's actually a lot harder, because DirectShow is a streaming API. It doesn't lend itself at all to the kind of random access that you want for editing. As an example, the DV Splitter will dynamically switch its output format whenever the source audio format in the stream changes. That means you have to have support in your application for dynamic resampling.
As another example, there's no notification if a frame will arrive... ever. You have to seek to the desired point and wait for frames to arrive, since frame delivery is an asynchronous operation. Some playback filters handle seeking by simply not delivering frames until the next convenient location in the decoding sequence, which then results in your application hanging unless you have a timeout. This used to happen with the WMV filter, which caused playback to be black after a seek until the next sync point (key frame).
Cutting of streams that have B frames is another problem entirely. In most cases, this is not possible without re-encoding, because the B-frames cause all frames in the entire stream to be cross-linked, as opposed to an I/P only stream where you have a clean break before each I-frame. In MPEG-1, this is handled by a "broken link" bit, which indicates that an edit has occurred before an I frame. However, this results in an imperfect edit since you now have ~2 frames before the I frame that are lost and are replaced with the I frame; doing a frame-exact edit requires re-encoding. Furthermore, this all assumes that a multiplexing filter is installed on the system for the container format, which is unlikely.
What this all adds up to is that it's hard to find a way to make all of this work without ending up with a result that's held together by duct tape and baling wire.
Thanks. Both of these are actually harmless in practice: the first error is in the build tool and stream I/O handles are guaranteed closed on exit, and the second error causes no problem because default delete and delete are equivalent for POD types in VC++. Still, they're technical errors, so I might as well fix them.
Phaeron - 09 11 09 - 03:07
MKV for gods sake!
"I call this the TIFF Problem, after similar issues faced by supporters of the Tagged Image File Format -- which is easy to write because it supports everything, and hard to read because it supports everything."
then at least make "Save as MKV:
Mont Pelier - 31 03 11 - 07:02
Please, if you can get us a Save As MKV at least~
Navarr (link) - 14 10 11 - 14:52