bug in opencv ffmpeg wrapper. (Bug #1815)
Description
It seems the new ffmpeg wrapper solved the frame positioning bug. However, it introduces a new bug.
The function VideoCapture::get(CV_CAP_PROP_POS_FRAMES)
gives wrong results.
Here's the code producing the problem:
1capture.set(CV_CAP_PROP_POS_FRAMES, i);
2capture >> frame;
3int j = capture.get(CV_CAP_PROP_POS_FRAMES);
4cout<< "get =" << j << "| set:" << i<<endl;
The output is:
get =8| set:2000 get =10| set:1998 get =12| set:1996 get =14| set:1994 get =16| set:1992 get =18| set:1990 get =20| set:1988 get =28| set:1986 get =30| set:1984 get =32| set:1982 get =34| set:1980 get =36| set:1978 get =38| set:1976 get =40| set:1974 get =46| set:1972 get =48| set:1970 get =50| set:1968 get =52| set:1966 get =54| set:1964 get =56| set:1962
The problem could lie in following code. frame_number is also a member of CvCapture
.
1void CvCapture_FFMPEG::seek(int64_t frame_number)
2{
3 frame_number = std::min(frame_number, get_total_frames());
4 int64_t dts = dts_to_frame_number(ic->streams[video_stream]->cur_dts);
5
6 if (abs(dts - 2 - frame_number) > 16)
7 {
8 double sec = static_cast<double>(frame_number) / static_cast<double>(get_fps());
9 int64_t time_stamp = ic->streams[video_stream]->start_time;
10 double time_base = r2d(ic->streams[video_stream]->time_base);
11 time_stamp += static_cast<int64_t>(sec / time_base);
12 av_seek_frame(ic, video_stream, time_stamp, AVSEEK_FLAG_FRAME | AVSEEK_FLAG_BACKWARD);
13 }
14
15 while(dts - 2 < frame_number)
16 {
17 /* cv::Mat imag = read(); */
18 if (!grabFrame()) break;
19
20 dts = dts_to_frame_number(ic->streams[video_stream]->cur_dts);
21 }
22}
Associated revisions
Fixed error in frame positioning (bug #1815)
Merge pull request #1815 from asmorkalov:android_native_camera_build_automation
History
Updated by Andrey Kamaev almost 13 years ago
- Description changed from It seems the new ffmpeg wrapper solved the frame positioning bug. However, it... to It seems the new ffmpeg wrapper solved the frame positioning bug. However, it... More
- Category set to highgui-images
- Assignee set to Alexander Reshetnikov
Updated by Alexander Reshetnikov almost 13 years ago
Jack, could you attach a video clip for reproducing this bug?
Updated by Jack Tan almost 13 years ago
Hi, Alexander,
Here's the requested video clip. I've tested a couple of video clips. All have the same problem.
- File dvd_Title01-001.mkv added
Updated by Alexander Reshetnikov almost 13 years ago
Thank you for the report, Jack! It was really mistake in the prototype of seek function. I've changed it in r8085.
One note: your test clip doesn't contain 2000 frames (I've already tested it and got 662 frames returned by get method and 661 frames read (last frame probably cannot be read so it's not full).
- Status changed from Open to Done
- Priority changed from High to Normal
- Target version set to 2.4.0
Updated by Furqan Khan almost 13 years ago
Hi,
The updated code still didn't resolve bug #1788 for my H.264 encoded files. I think the seek_frame routine doesn't do anything if the _frame_number (input) is not more than 18 frames behind the current position. However, even trying higher differences still didn't work for me. I also used the sample code uploaded here but it I had same issue.
Thanks.
Updated by Andrey Kamaev over 12 years ago
- Category changed from highgui-images to highgui-video