View Full Version : Resize problem regarding IC Imaging Control v. 1.4 : part III.

April 15, 2003, 10:18:01
Hello Johannes,

Thanks for replay. I answer to your suggestions and a last observation.

>> There is nothing you can do against the time delay. The time delay can be observed on all common video editing programs like Premiere, even if you use real time editing hardware like Matrox RTX.100. Even if you capture a video stream from a DV camera (the camera is in play back mode) you encounter a delay.

In the second post I searched to better explain the misbehaviour of the combination IC 1.4 resize preview + ADVC-100 and mentioned the first post (9-04-03) for the other cases where the things are right. You say that in hardware like Matrox RTX.100 there is time delay, too. In the first I reported a trial with a card that cost less than 1/20 of RTX.100, and the results were pretty good. It is TOTALLY obvious that there is a time delay between tha frame captured through the camera + grabber device and the sw preview window: the difference is that in normal cases this delay is a pretty small fraction of a second (0.1 or less, may be) and therefore acceptable for the most kind of situations, in the other THE DIFFERENCE IS 1-1.5 seconds (a little pause for a cup of coffe: is clearer in this way?).

>> Please verify that you do not see a delay if you capture a stream with Media Studio from the ADVC-100 if you use the same settings.

The delay I observe with ADVC-100 + Media Studio preview (with resizing) is pretty the same (qualitative impression) as that I observe with the other grabber (Ez Capture) and it is more than acceptable. It is more or less the same of the combination EzCapture + IcImaging preview with resize (normal behaviour).

>> Some capture programs setup the DV codec to work with quarter resolution without notifying the user. Maybe this makes the difference.

1. the DV codec is "Ulead DirectShow",
2. preview options: user defined (768x576) with flag for proportion maintaining checked.
3. resolution of acq.: 720x576.
4. quality images are congruent with this resolution (so, no tricks ...)

I don't know the internals of your component, but from my observations I may only suppose that there is some problem when it gets involved with IEEE-1394 comms, either directly or not. If this is the case, your device DFG/1394-1 should have the same behaviour. If not ..., well, may be the problem is another, but please, check it: it is not a normal or correct behaviour.

Best regards

P.S. Please, don't be upset from my insistence, but otherwise I have to devise another solution, as I can't modify the hardware configuration.