Discussion Forum

I must disagree with something that you said, if you timestamp the incomming frames, the playback rate must never change. it must be constant.  In our system we have to timestamp the frames, so there is off-sync between the video and the audio (up to 40ms).  Is Osprey 220 still an option for us, or should we upgrade it to a better one 500 or 2000?

Guy

Well this does make more sense. The belief that video is absolutely N frames/sec will pratically never be correct. It is very source dependent. The hw itself is basically slaved to vertical sync rate of the source. VCRs are typically horrible as you've seen. The best results will be with a studio VTR (you've seen that as well). The timestamps are generated based on vertical interrupts so there's little chance of these being wrong - they basically represent *the* time in reference to the system clock. Now your system clock may have a slight drift in it so that needs to be taken into account.

In designing any a/v capture/playback system one always needs to keep in mind that the source capture rate should define the playback rate. In pratice however this can be challenging unless the underlying a/v APIs can handle the types of drift that exist between capture/playback.

As an aside... For example, audio A/Ds are pure digital samplings of an analog audio signal. This A/D is mastered by a clock that in practice will never be exactly the defined capture rate (say 44.1KHz) - it will tend to be off by some ppm (parts per million). On playback there is a D/A which will also be taking in digital samples at the defined rate but off by some different ppm. One option to adjust the captured audio to the playback rate is by inserting silence or duplicate/interpolated samples during playback. That usually doesn't happen. Typically audio is played back slaved to the output audio device and the video associated with the audio is either slowed down or sped up to match. This is what is referred to as having the a/v stream audio mastered. Actually this process usually happens on capture where the video rate / frames (through the underlying APIs) are adjusted dynamically due to any slight drifts in audio from the ideal audio capture rate.

Hi

I'm sorry for giving you the worng information. It's not that the timestamps are different from the computer time. it's the timestamps given in compare to the frame recieved.

After more research, i've observed that it is source depended, if I capture from a sony DVD it missed a frame every ~23 minutes, whereas capturing from a VTR output it misses a frame every 1 day...., a simple VCR connected to anthena gave an hurrible results...

Is this fact known? is my observation correct, or am I doing something wrong?

Guy

Hi

Yes, the frame rate is 40,000. You can take the null renderer example of DirectShow, this is exactly the same one as I'm using.

Guy

Is your framerate set to 25.00 (usec/frame = 40000)? Would you mind sending us your dump filter to try out in our lab? We'll run it against our VFW and WDM based drivers. Send to [email protected].

Hi

I'm devloping a 24/7 capturing application with Osprey 220. My flatform is DirectX 8.1. P4 1.8 Ghz with SCSI HD drivers and 256 Memory.

I've written a dump filter in Direct Show that doesn't do any data processing, just observed the timecodes given by the Osprey.

It seems that for every 25 minutes there is a difference of 1 frame between the timestamps and the computer clock.  I run the graph for 2 days and this rule continued on (Difference between computer clock and the sample timestamp was around 110*40,000 ms)

I'm capturing a CIF YUY2, PAL.

Thanks in advance

Guy