It seems to
happen with some video files and I don't know why.

The video file I'm using was converted in a website (vixy.net, if I'm not mistaken), directly from YouTube, so if it has problems, I can't tell.

Just so you know, the vidl library is no longer being actively
maintained and is quite outdated.

Oh, those are terrible news! :/

There is a much more modern
streaming video library being developed in contrib/brl/bbas/vidl2.  I
strongly recommend using vidl2 over vidl.

Then I'll check the vidl2 library, or another one...
 
How are you stepping through the video?

I'm using an iterator of the type vidl_movie::frame_iterator, and going forward with the ++ pre-operator. I'm not seeking anything explicitly until now, just looping around in sequence, but I will use a graphic slide bar to step through the video, so I may do this in the future. From what I've seen in the documentation, seeking to a specific frame is just an assignment to the iterator, right? Like:

iterator = 20;

to jump to the 20th frame.

However, it may be that is is working for your case anyway.

Yeah, I don't know if this is actually causing me any trouble...

The underlying issue is that the ffmpeg library that we actually use changes it's API quite often, so it's hard to keep our wrappers around it working well.

I also don't like how FFMPEG changes its API so fast, it has already given me headaches in the past...

Thank you for your answers!

On Fri, Jun 13, 2008 at 3:20 PM, Amitha Perera <amithaperera@users.sourceforge.net> wrote:
Crístian Viana wrote:
I'm reading a video file and, for each frame, the program prints the frame index and its dimension. It starts just fine, but after the frame #1694, the VXL library prints some messages, like "seek went into the future!", until the end of the video.

From your error message, you appear to be using vidl.  Which version of ffmpeg are you using?

When you get that error, it often means that the seek is not correct. The actual video frames you get may not correspond to the frame numbers that the library returns.  However, it may be that is is working for your case anyway.  The only way to be sure is to compare some known frames against that output by vxl.

How are you stepping through the video?  If you simply need to read sequentially, you shouldn't seek.  And if you don't seek, I don't think this error will come up.  (I didn't look at the code to verify, though.)

The underlying issue is that the ffmpeg library that we actually use changes it's API quite often, so it's hard to keep our wrappers around it working well.

Amitha.