|
|
| jac_goudsmit |
 Posted: Nov 6 2002, 09:12 PM |
 |
|
Unregistered
|
I have a problem that (I think) might be the same problem as the poster that had the "Jumpy Horizontal Movements in 25fps" (see elsewhere in this forum), only I'd like to describe and analyze it in a different way, so I'm starting a new topic.
I've been using VDub for years, in combination with Pinnacle Studio and a Miro DC10(plus) MJPEG video grabber. I use Studio to grab the video and audio and then I use VDub to link AVI's together and convert the result to a different format, e.g. DivX.
I recently updated to Studio 7.0, and I just grabbed a movie with it that I recorded from tv. In Studio, the grabbed AVI's play just fine. In Windows Media Player, they play fine too. When I play them, I can see that the picture is interlaced, but I have no problem with that.
But when I open one of the MJPEG AVI's in VirtualDub 1.14.11 and play or process it, it looks awful: it's as if one of the fields of each frame doesn't get updated by the decoder that VDub uses, or something. I used Direct Stream Copy to create a short fragment AVI, you can download it from here (28MB). If you don't have an MJPEG decoder installed, you may not be able to play it in Media Player but I can assure you it plays just fine when you do have one. However in VirtualDub you will see immediately what I mean.
When you add a deinterlace filter, set to "duplicate field 2", you will see a fluent picture: Field 2 is ok. But if you change it to "duplicate field 1" and click the "Play Output" button, you will see that the picture only updates a few times per second.
Let's keep that "duplicate field 1" filter in place just to analyze it further. If this would be a grabbing problem, the data in the AVI file would be to blame (let's ignore for a second that it plays correctly in Media Player). In other words: if the grabber couldn't keep up with the computer during the grabbing, it would have just put the same data in the AVI for each frame's field 1. So let's say if it would have only put data in the AVI for frame 0 and frame 5, and you would go from frame 0 to 5 and then back, you would see this:
frame: 0 1 2 3 4 5 4 3 2 1 0
display: 0 0 0 0 0 5 0 0 0 0 0
Instead, what you see when you do this in my AVI is:
frame: 0 1 2 3 4 5 4 3 2 1 0
display: 0 0 0 0 0 5 5 5 5 5 0
It looks as if the MJPEG decoder just doesn't have anything to decode in the frames with "dropped fields", and the data that you see is the data from the last frame that WAS successfully decoded.
This to me would either mean that there is just nothing in the stream that can be decoded, or there is something wrong with the decoder and it just doesn't "pick up" the data.
Now, I know that VDub has its own MJPEG decoder. When you use the "popup extended open options" on File/Open, you can switch the internal MJPEG decoder on. Interestingly, if you switch to the internal decoder and set it to discard either field 1 or field 2, the result looks distorted of course, but it's totally fluent for either field. Also, if you set it to swap the fields, you will still see the dropped fields when you use the "duplicate field 1" filter. And when you set it to "split interlaced frames in two fields" you see fluent video too, even without the deinterlace filter. Interesting! Another indication that the data is there, but just doesn't get decoded in normal mode. Furthermore it's interesting that it doesn't seem to matter whether you switch the internal MJPEG decoder on or off.
From what I see, it looks like there are two bugs here.
(1) VDub always uses the internal MJPEG decoder, no matter whether you set the "use VirtualDub routines" option ON or OFF. (Hmmm this just came up in my mind: maybe in WinXP, VDub doesn't detect the hardware decoder because it uses a different driver model?)
(2) the internal decoder seems to have a problem with the AVI format that Studio 7 generates: most of the time it only reads field 2, sometimes it reads both fields.
This is my setup:
Athlon 800MHz, 256MB, Windows XP, using NTFS file system for video files;
Pinnacle Studio 7.15 PAL+NTSC version, grabbing from NTSC source (VCR); VDub 1.4.11 release.
Pinnacle DC10Plus hardware drivers: DCxxMJPGCapture.ax 6.0.0.1; DCxxMJPGRender 6.0.0.0; DCxxMJPG.sys 2.0.0.000
===Jac
|
|
| Morsa |
| Posted: Nov 6 2002, 10:02 PM |
|
|
Moderator of the Vdub support board
Group: Moderators
Posts: 640
Member No.: 246
Joined: 9-September 02
|
There's another thread talking about problems with Studio xx from Pinnacle.
Please, search for it to see if it just helps you.
If not, someone surely will answer this post, cause I'm not the proper one.
|
|
| Spire |
| Posted: Nov 7 2002, 04:12 AM |
|
|
Unregistered
|
Jac,
I downloaded your test clip and tried to reproduce the problem.
On my system, the only MJPEG decoder I have installed is the PICVideo MJPEG Codec, and when I open your file in VirtualDub, it correctly uses the codec to decode the file. Interestingly, the file appears to be decoded perfectly! It is coherent in both fields; also, processing the file with the Deinterlace filter with either Duplicate field 1 or Duplicate field 2 causes no apparent problems at all.
However, if I use VirtualDub's internal MJPEG decoding routines (which correctly get activated only if I enable them in the extended open options), I am able to reproduce the problem that you describe.
This indicates one of two possibilities:
First: The file produced by Studio 7 is a corrupt/nonstandard MJPEG file, and the Studio program and the PICVideo codecs just happen to be able to handle it correctly by chance.
Second: The file produced by Studio 7 is a valid MJPEG file, but is stored in an unusual variant of the format that is handled incorrectly by VirtualDub's internal MJPEG decoder, as well as by the codec that VirtualDub uses on your system (the Pinnacle software codec?). |
|
| jac_goudsmit |
| Posted: Nov 10 2002, 12:52 AM |
|
|
Unregistered
|
Thanks for your comments, Spire!
As I said in my first message to this thread, I think it might have something to do with the fact that my card only has DirectShow drivers, so no Video For Windows drivers. I'm not sure how VirtualDub works, but because it's been around for a while, I wouldn't be surprised if it only uses VFW. Therefore it only searches for VFW codecs, decides that there isn't any decoder for MJPEG and therefore always uses the internal codec, no matter what the setting is in the extended open options (Of course IMHO this should be indicated in VDub by showing the "use internal codec" checkbox as "on" and "disabled", i.e. you can't disable it, but this is of little importance).
Either way, like you said, the internal codec has a problem with something that's happening in this AVI, that didn't happen in AVI's produced with previous versions of Studio under Win98. It's been too long since I programmed anything under Windows, and I'm not familiar with the VDub source code at all, so I'm afraid someone else (Avery Lee?) will have to have a closer look at it. Looks like a decoding buffer isn't always big enough or a frame size is read into a variable that isn't big enough to hold it (e.g. short instead of unsigned short). It can't be a big bug because it DOES decode entire frames every once in a while. Maybe it has something to do with the bitrate; I guess I should try grabbing a video at something lower than the default 7000KB/sec and see if the problem is still there.
For now, I can switch to a software VFW codec (I have a registered copy of the Morgan Multimedia codec, so I can play movies from my external SCSI harddisk on my laptop - I just don't have it installed on my video grabbing system because it doesn't need it) but that still leaves the fact that the internal codec apparently has a problem with the AVI, and I'm sure I'm not the only person who has this problem - Studio 7 and 8 are popular applications and the DC10(+) is a popular grabber. Previous versions of Studio didn't have this problem.
===Jac |
|
| phaeron |
| Posted: Nov 30 2002, 11:18 AM |
|
|
Virtualdub Developer
Group: Administrator
Posts: 7773
Member No.: 61
Joined: 30-July 02
|
Finally got a chance to look into this one -- it is indeed a bug in my decoder. I own a DC10 and a DC30 and VirtualDub's MJPEG decoder was tested extensively on DCxx-generated material, but it appears the behavior of the Pinnacle MJPEG encoder has changed recently. The bug is in the MJPEG decoder's handling of fill bytes -- markers can be skipped when FF FF ... is present. It looks like the current Pinnacle drivers are now padding the second field to word boundaries, giving a one-half chance that VirtualDub misses the second APP0 marker when the sequence FF FF E0 is present. This then causes VirtualDub to decode to two fields on top of each other.
Unfortunately, I just released 1.4.13 a few hours ago, so the fix will ship in the next version (1.4.14 or whatever).
|
|
|
