Great! Thanks a lot robjv1! Wow, my settings were much different. And, this has helped to improve my video transfer. So from the small testing I've done, this works! So I thank you!
Quote:
Originally Posted by robjv1
It's easy to tell when you are dropping frames, because they'll be missing when you watch the video of course, it'll add a noticeable judder to the video. It doesn't sound like you are dropping frames.
|
Right, you can often tell when you are dropping frames! However, this isn't really good enough. What if I recorded 2 hours of video? I can't obviously watch the entire thing. So, there must be a better way to determine if I have dropped frames? What I'm getting at is, can I trust Virtualdubs dropped frame status? The format in the lower left corner is as follows:
"357 frames (25 dropped), 13.100s, 2ms jitter, 2ms disp, 689287 frame size, 242635K total: 1.0030259"
It would be great if someone could break each field out? Here we got dropped frame count, time??, jitter time??, time of 'disp' (whatever that is), ...etc.
There's jitter time shown in the "Timing Graph" (Capture->Timing Graph). But what does this jitter time really mean to me when I see it fluctuate? Big deal? How does the jitter time relate to the quality of the video being captured? How concerned should I be?
But again, can I rely on the frame drop count? Does it accurately reflect when a frame was lost? I ask this, because when I had "Drop frames when captured frames are too close together" enabled, I would immediately start dropping frames. Soon as I disabled "Drop frames when captured frames are too close together", I no longer was receiving dropped frames. I wondered if "Drop frames when captured frames are too close together" perhaps disables the accuracy of the drop frame count? Or maybe not?
Quote:
Originally Posted by robjv1
Maybe I'm not quite understanding what you are saying, but the speeding up and pausing sounds like the timing settings for sure -- keep in mind that with that card the audio and video should be locked together, so you don't have to worry about compensating for timing differences.
|
At this point, I am not even passing audio through the ATI 600 USB. I see the video 'was' already jerky, and so that to me made the audio irrelevant at the time. It's just to say that I have yet to actually try audio NOW that I actually have what looks like a steady and consistent stream of video.
Otherwise, you made another great point: The audio and video should be locked together! I suppose that's because the video and audio go into this ATI 600 USB and come up through the same USB stream in sync. I never really thought of it...but that's how I look at it.
Quote:
Originally Posted by robjv1
For the ATI they should look like the attached picture.
|
Again, thank you for taking your time to provide these settings!
Quote:
Originally Posted by robjv1
As long as your computer is powerful enough, that should result in no dropped frames and no sped up / slowed down video and audio.
|
In summary, there are two things that have helped to improve my video transfer:
1) The settings you provided in the attached picture! Much different from
virtualdub defaults.
2) Increasing buffer size in Disk I/O
It would be great if someone can help to clarify this "Timing Graph" a bit more. In the graph, you can see from the legend:
1) Video Time Jitter - what's the relevancy of this? How important is this? What is the healthy state?
2) Video Resampling Rate - what's the relevancy of this? How important is this? What is the healthy state?
3) Video offset error - what's the relevancy of this? How important is this? What is the healthy state?
4) Synch error - what's the relevancy of this? How important is this? What is the healthy state?
In my first post, I attached a picture of what I see in the Timing Graph. It's all over the place. Of course, this was before my improved settings. But, what's an example of a "Healthy" timing graph?