View Full Version : DFG/1394-1e and Blue Screen on Video Loss

October 4, 2006, 16:16:04

I'm using the Firewire DFG/1394-1e device with the IC Imaging Class library.

If the source of video input to the device is lost, I get a black screen for about 15 seconds, then I get
RGB24 640x480" for S-Video inputs, and

RGB24 640x480" for the composite input.

The black frames are okay with my application. The problem is with the blue frames with the above error. Once they show up, the video does not return, even if I reconnect a valid source of video to the device.

Is there a fix for this?

Stefan Geissler
October 5, 2006, 10:14:18
Hi Kay,

The problem seems to be that the DFG/1394-1e can not resynchronize to the camera. In the properties of the DFG/1394-1e is a "VCR compatibility" flag. You may enable this and try, whether the DFG/1394-1e is able to synchronize after the camera is disconnected and connected again.

October 5, 2006, 14:47:37

Could you provide me with short example on how to set the VCR Compatibility flag. Is this in version 2.1 of the library?


Stefan Geissler
October 6, 2006, 08:14:39

You could use the Grabber::showVCDPropertyPage() method to set the property.

October 6, 2006, 22:39:30

Thanks for the suggestion. The problem that I have is that the "VCR Compatibility" flag may not solve the problem for all my sources of video. I have video sources which come from very unpredictable old Fluoro XRay medical units, etc.

This problem of the DFG/1394-1e device first losing synchronization but then not been able to see good video coming in seems to be a firmware problem that should have a solution. The device locking up is definetily not a good thing. Is there way to fix this problem via a new firmware version for your device?



October 7, 2006, 16:00:45

I have done some more testing on this problem that has revealed some more details. I don't know if any of this is useful to you, but here it is.

1 - I connected a source of S-Video and Composite video to the DFG/1394-1e.

2 - In the callback function that I use for the Listener object, I check the Grabber::getSignalDetected function.

3 - Here are the results.
- If video is connected to the DFG, the getSignalDetected function returns TRUE.
- If video is not connected to the DFG, the function returns FALSE. If I reconnect the source of video to the DFG, the getSignalDetected function returns TRUE and the video comes in properly. This only happens if I reconnect the video within 15 seconds from the time that I disconnected it.
- If I don't reconnect the video within 15 seconds, the Blue Screen described earlier is returned by your driver and the getSignalDetected function stays FALSE.
- Now, here is the interesting point. If I do reconnect the source of video to the DFG AFTER the 15 second time period, while the Blue Screen is up, the getSignalDetected function returns TRUE.

What would make the getSignalDetected function return TRUE if the DFG is locked up? On the otherhand, if this function means that the driver in the PC is detecting good video over the Firewire port, then doesn't it point to a lockup in you PC software and not the DFG?

Please advice.

Stefan Geissler
October 9, 2006, 15:32:25
Hi Kay,

The Signal Detected property shows only that the PLL has synchronized to something. But unfortunatelly something went wrong in the video chip, thus the converter does not deliver correct data. But a call to Livestop and livestart should fix this problem, because the video chip is restarted.

October 9, 2006, 20:16:12

Thanks for the suggestion. I'm happy to report that I have had partial success.

What I do is check for the Blue Frames in the callback of the Listener object. If I detect the Blue Frames, while the getSignalDetected function returns TRUE, I set the application up to call the 'stopLive' and 'startLive' calls. I put a 1 second delay between the calls.

The result is that it works, most of the time. Sometimes, I get the following error. Eventhough the error is for Debug mode, please note that it has also happened in release mode.

Exception DEBUG: in c:\ic 1.5\core\tisudshl\grabber.cpp lilne 952
Error = IID_IGraphBuilder could not be build. Due to: CoInitialize has not been called.
In file: "c:\ic 1.5\core\dshowlib\filtergraph.cpp at line 147

Any advice.

Please note that my linker is set to use the 2.1 libraries. I don't understand why the error shows "ic 1.5".

Thanks in advance for any help with this.

Stefan Geissler
October 10, 2006, 08:04:07

The function DShowlib::InitLibrary() calls CoInitializeEx(), that is why this functions should only be called once in an application. If some other function in your application calls CoUninitialize() somewhere, then the error you reported occurs. Thus you may try to find out who calls CoUnitialize(). This is not easy, because you hardly will have the source code of all functions you use in your application.

And do not worry about the "C:\IC 1.5" path of the development environment of my computer. It is just a name, historical grown :-)

October 10, 2006, 14:54:05

I have not found anything in my code calling CoUnitialize().

The only addition to my code is to detect the blue frames when getSignalDetected returns TRUE in the Listener callback function. I then call the 'stopLive' function, followed by the 'startLive' function.

This is not going to be reliable enough for me, so unfortunately, I can't use it. Is there any other way around this problem?


Stefan Geissler
October 10, 2006, 16:07:50

I exspected that you would not find CoUnitialize, because this may is called within some other functions. I do not know, what functions you call in your project, I have trouble to help you. Is it possible that you call startlive from another thread then the thread you have called InitLibrary in?
Also do not call startlive / stoplive from the Overlay update event and CListener::frameready.

October 10, 2006, 17:03:32
Hi Stefan,

Yes, I do call the 'stopLive' and 'starLive' functions from within the same thread that initialized the device. Also, I do not call from within the Overlay event or the frameReady callback.

What I do in the frameReady function is to send an appropriate WM_USER message back to my main application. As part of the processing for that custom message, the application then carries out the 'stop' and 'start' sequence of events.

Thanks for all your help. I will look into this in more detail when I have the time. Meanwhile, if you can think of anything else that I may do, please let me know.

Once again, thanks for your prompt response to my questions on this issue.


Johannes Vogel
October 25, 2006, 10:39:40

Please use PostMessage instead of SendMessage. SendMessage will wait for the message handle to return. In this case, the message handler is executed in the main thread and it calls stopLive. StopLive waits for all threads that are pending. One of these threads is the fram ready event, which waits for the message handler. In this case, you have a dead lock and your app hangs.