|
|
| awenonian |
| Posted: Sep 2 2014, 11:26 PM |
 |
|
Newbie
Group: Members
Posts: 5
Member No.: 38247
Joined: 2-September 14
|
Ok, let me see if I can explain this.
So, I'm playing a PS2 game through an EZ cap thing, with Virtual Dub to record it. When playing it and using Virtual Dub for visuals and audio, everything is as expected. When I capture though, I run into issues.
While the audio and video in the preview sound good and look good and are in sync, if I turn off audio and video syncing in the "Timing" option of the "Capture" tab, the audio desyncs nearly immediately, and get's more out of sync as the video goes on. However, the audio sounds the exact same (not higher or lower pitched, which I thought meant it was going at the same speed as the original)
Changing that to resync the video to the audio changes literally nothing, and the same exact result is aquired.
Changing it to resample the audio to fit the video results in all the characters to slowly fill their lungs with helium, more and more as the video goes on (it went from sounding normal to rather extreme in less than a minute)
What I find weird, is that when the audio sounds normal (i.e. not higher or lower pitched, which I believe(d) would correlate to how fast it's played), and it desyncs with the video, the video still has the correct timing, as in, I timed it with a separate timer(on my phone), and they came out the same. So, if the audio and video are both playing at the correct speed (the speed that had them in sync in the preview) why are they out of sync in the resulting video? |
|
| Abrazo |
| Posted: Sep 3 2014, 06:31 PM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
When capturing video and audio, you must see this as they are recorded in separate tracks. One track with the video, one track with the audio.
In general, depending on the video standard, there are 25 or 30 images per second that must be captured.
Depending on the hertz-rate of the audio, there are 44100 or 48000 samples per second to record.
Recording audio is mostly no problem, because the time to encode, and the place to store this, are rather small.
In case of video, that is another thing...
What happens when capturing, is that sometimes and mostly irregularily there are frames that are NOT recorded
(because the cpu is not fast enough to encode and/or the disk of the pc is not fast enough to store it).
These are called "dropped frames".
So it may be that sometimes there are no more than 20 images per second, sometimes 22, ...
When you play the recorded video and audio from the recorded file, the images are shown at 25 (or 30) frames per second even if they were not recorded at that speed. This makes that the video goes out of synchronisation with the audio (because there are less images than there are audio samples), and there is almost no way to resolve this with an acceptable result.
The only thing that there is to do, is trying to avoid "dropped frames" while recording, by capturing in a lower resolution and/or by lowering the quality settings of the encoder.
I hope this explanation may help a bit.
Regards. |
|
| awenonian |
| Posted: Sep 4 2014, 07:38 PM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 38247
Joined: 2-September 14
|
Ok, that makes sense to me. But if that was the case, wouldn't the video time be off? I'm pretty sure it's on time, and so, if there were less images then there were supposed to be, and it was playing at the same rate anyway, wouldn't it be an incorrect time? |
|
| Abrazo |
| Posted: Sep 4 2014, 08:45 PM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
When opening the resulting video in VirtualDub and clicking File > File Information... you may detect a difference in audio- versus video-length ?
Every frame that has been dropped represents 40 milliseconds of time (when at 25 frames per second).
A difference from 40 to 80 milliseconds between audio and video timing is nearly remarkable, but once it gets 120 or more you will see this (and that is only 3 frames).
Given that fact that you already need 60 x 25 frames (1500) per minute of video, chances are very high that an out of sync will quickly be remarkable. |
|
| awenonian |
| Posted: Sep 4 2014, 10:26 PM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 38247
Joined: 2-September 14
|
Maybe I misunderstood something, and sorry for taking up your time, but from what I got, you were saying that the audio was able to be encoded easily enough that it was not really affected by computer speed and such. And so the audio would remain at the rate and timing it should be. However, since video is harder, it would drop frames, and the resulting video, missing those frames, would be shorter than the actual time it should be, so the audio and video would be out of sync. But, I played the resulting video file in windows media player, and it came out as the correct time, which would seem to not be what would occur if the video had dropped frames. Is that correct?
Thanks so much for trying to get me to understand. |
|
| Abrazo |
| Posted: Sep 5 2014, 07:59 AM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
Can you once try to capture with Video > Timing... everything un-checked, and the choices on "Do not resync..." and "Automatic" = 30.
And see what that gives afterwards when playing the new captured file.
An other possibility is that the resulting video is being played via a decoder that is not part of the codec with which you did record it.
By this I mean, VirtualDub uses a "video for windows" codec when encoding, and your Windows Media Player uses a DirectShow or a Windows Foundation decoder to play it.
For Windows 7 there is a tool called "Windows 7 DirectShow Filter Tweaker" with which you can set which decoders you prefer to be used.
Maybe you can try with that, and see if it makes any difference when playing your recorded video.
Maybe you can tell us which codecs you have used to encode audio and video ?
And did you verify audio and video length in VirtualDub via File > File information... ?
At the moment, I have no other ideas of what might be the cause of the problem, or should it be that the images that you are capturing themselves are played at "variable" speed ? At my knowledge VirtualDub and also most encoders are capturing at a "constant" speed. MPeg2 might offer an exception to this, but that codec is not available for capturing with VirtualDub.
Regards.
|
|
| awenonian |
| Posted: Sep 5 2014, 10:41 PM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 38247
Joined: 2-September 14
|
Ok, I tried it with everything unchecked, and it worked a lot better than it did before. However, I tested that one for a longer time, and even though virtual dub told me there were 0 dropped frames, the audio was very noticeably off at the end of the video. Though according to a timer, the video length was correct, so that's good. And it was much more on point than before.
I'm using the Xvid Mpeg 4 Codec to compress, not sure if that's what you mean by "encode", and I think it gave me better results, but I can try it without a codec and see if that works better.
Here's the file Information:
Also, Just to compare with the lengths, a timer that I started when I pressed the capture button (meaning, if there's a delay before it actually starts capturing, it won't account for that) says 21:29.95 for the time. Just to compare with the audio and video lengths.
Video:
Frame size, fps (µs per frame): 720x508, 30.000 fps (33333 µs)
Length: 38643 frames (21:28.09)
Decompressor: Xvid MPEG-4 Codec (XVID)
Number of key frames: 189
Min/avg/max/total key frame size: 4432/7016/21190 (1296K)
Min/avg/max/total delta size: 0/1467/26775 (55092K)
Data rate: 359 kbps (1.58% overhead)
Audio:
Sampling rate: 48000Hz
Channels: 2 (Stereo)
Sample precision: 16-bit
Compression: PCM (Uncompressed)
Layout: 945 chunks (0.00s preload)
Length: 61888800 samples (21:29.35)
Min/avg/max/total frame size: 91264/261963/262144 (241754K)
Data rate: 1536 kbps (0.01% overhead)
Another note, virtual dub reported no dropped frames, yet the audio is about a second longer than the video, So, I don't know what's up with that.
Do you think removing the Compressing with Xvid would make it just that slight bit better I'd like it to be? I have the space to be able to compress them afterward. But I would think with 0 dropped frames it wouldn't matter too much.
Again, thank you so much for helping me as much as you have.
|
|
| Abrazo |
| Posted: Sep 6 2014, 08:15 AM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
One last idea.
I see that the length of the video (at 30 fps) is a little bit less than the length of the audio.
Myself I am used to work with 25 fps, but in other countries they are working with 29.970 fps (that is not really 30 fps).
At the playing speed of 29.970 fps your recorded video will just be a little bit longer.
So I am thinking, when in capture mode, you can set via the Video-menu > Capture filter... the video-standard.
Is this set to the correct standard that you are using ?
Once the video standard has been set you may have to once quit the capture mode and return to capture mode (= not quit VirtualDub itself).
After that, when you click Video > Preview pin, or Capture > Settings > Frame rate, you may see 29.970 ?
- - -
By 'encode' I mean indeed : compress the data via a codec (encoder - decoder) like Xvid or other.
You can also execute a test by recording the video as uncompressed AVI, if the hard disk of your computer can keep up with storing the datastream.
- - -
And you can also try to re-work (edit) the recorded video by changing its framerate via Video > Frame rate... > Change the frame rate to 29.970 and Process all frames. |
|
| awenonian |
| Posted: Sep 7 2014, 04:44 AM |
|
|
Newbie
Group: Members
Posts: 5
Member No.: 38247
Joined: 2-September 14
|
Thank you so much! Everything is working awesomely!
I wasn't really sure what standard to use, but NTSC_M worked fine. It did make the frame rate go to 29.970, so you were completely right there. I had it set to PAL_M and that looked ok, but then after I set it to something else and went back to that, it made the frame rate 29.970, but it also made the video black and white. But NTSC_M worked fine, so I guess I'll use that.
Again, thank you so much, I've never done this stuff before, and before you helped, I was getting very annoyed at it. So yeah, thanks, again. |
|
| Abrazo |
| Posted: Sep 7 2014, 07:21 AM |
|
|
Advanced Member
Group: Members
Posts: 775
Member No.: 28995
Joined: 5-November 10
|
Glad to hear that it finally works as expected.
Regards.
|
|
|
