FFmpegFrameGrabber's timeout doesn't work in some cases?

[d-a-gerashenko]

Actually I don't know is it timeout or lock.

1. When network is disabled

try {
	FFmpegFrameGrabber grabber = new FFmpegFrameGrabber("rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov.WRONGURL");
	grabber.start();
} catch (FrameGrabber.Exception ex) {
	System.err.println(ex);
}

When network is enabled this code instantly returns message: Did not find a video or audio stream inside "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov.WRONGURL"
When network is disabled grabber.start(); gets stuck.

2. Whe connection is lost
I noticed that FFmpegFrameGrabber's timeout doesn't trigger on connection is lost for one of my cameras.
I tried this code for ubiquiti cam mini:

try {
	FFmpegFrameGrabber grabber = new FFmpegFrameGrabber("rtsp://192.168.0.16/live/ch00_0");
	grabber.start();
	while (grabber.grab() != null) {                
		System.out.println("frame grabbed");
	}
} catch (FrameGrabber.Exception ex) {
	System.err.println(ex);
}

When I unplug network cable this code gets stuck on grab(). But it happens only with ubiquiti cam mini.
For this link "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov" code exits after about 10 seconds after cable unplugging.
The cause may be warnings which I get during connection to ubiquiti cam mini:

[swscaler @ 000000002a8e6020] deprecated pixel format used, make sure you did set range correctly

This warning doesn't take effect on video and audio grabbing from camera. I see video with audio in a good quality.

[saudet]

Does the same thing happen on the command line with the ffplay application?

[d-a-gerashenko]

ffplay works some differently. At start it works exactly as FFmpegFrameGrabber.start() but on connection lost it never stops even for "rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov".

I think I will have to use something like this:

ScheduledExecutorService executor = Executors.newScheduledThreadPool(2);
final Future handler = executor.submit(...); // start(), grab() and so on
executor.schedule(() -> {
	handler.cancel();
}, 10, TimeUnit.SECONDS);

[saudet]

I don't think that's going to work, but anyway marking this as a duplicate of #170, #430 and others.

[d-a-gerashenko]

Yes it's not a decision. Grabber stayed locked.

[saudet]

BTW, I'm pretty sure what we need is an interrupt callback, so please give it a try (see #170), and if it works, please make a contribution by sending a pull request!

[d-a-gerashenko]

I'll try it tomorrow.

[saudet]

Great, thanks! Be sure to try the stimeout option as well:
https://www.ffmpeg.org/ffmpeg-protocols.html#rtsp

[d-a-gerashenko]

Great thanks!!!

grabber.setOption("stimeout" , "3000000"); works.

There is some difference in behaviour after timeout.

When network is disabled (before brabber was started) grabber throws exception: "org.bytedeco.javacv.FrameGrabber$Exception: avformat_open_input() error -138: Could not open input...".

When connections is lost (after a few grabbed frames) grabber.grab() returns null without exception.

Code for test:

try {
    FFmpegFrameGrabber grabber = new FFmpegFrameGrabber("rtsp://184.72.239.149/vod/mp4:BigBuckBunny_115k.mov");
    grabber.setOption("stimeout" , "10000000"); // 10 seconds
    grabber.start();
    Frame frame = null;
    while ((frame = grabber.grab()) != null) {
        System.out.println("frame grabbed");
    }
    System.out.println("loop end with frame: " + frame);
} catch (FrameGrabber.Exception ex) {
    System.out.println("exception: " + ex);
}