[Ffmpeg-devel] av_seek_frame() units
Wed Jul 6 23:24:01 CEST 2005
Nathan Kurz wrote:
> On Wed, Jul 06, 2005 at 12:04:44PM -0700, Ian Gowen wrote:
>>On 7/6/05, Andy Parkins <andyparkins at gmail.com> wrote:
>>>I'm not sure why you would need to do this. What source for frame_number are
>>>you using - it's not in any of the AV structures.
>>I'm working on a video editing application. If the user wants to
>>preview frame 320, I
>>need it to seek to frame 320, not the nearest keyframe or a frame in
>>vicinity of frame 320.
> Not to be too discouraging, but you should also know that seek is
> badly broken for many formats. It's quite possible that you are doing
> things correctly, but are being bitten by bugs. If you search the
> archives from (I think) the end of last year you'll find a fairly
> elaborate test program I wrote to test which formats work. I had
> submitted it as a regression test, but as it pointed out new bugs
> rather than regressions it wasn't included in the test suite.
> Nathan Kurz
> nate at verse.com
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
It sounds like Ian and I are both working on applications that need
precise frame positioning. In light of what Nathan said above, can
anyone offer recommendations for the best way to ensure that the user is
looking at the frame he or she thinks they should be looking at? Is
there a reliable way to detect when seek has gone wrong ("I expected to
be looking at the frame for time 13.125 seconds, but I actually got the
frame for time X...error!")?
In response to my original question a couple of weeks ago, someone
suggested using a format like MJPEG that treats all frames as keyframes.
If there is not a more general solution for precicely positioning
arbitrarily-formatted streams, could someone give me an expert opinion
on the best format to transcode all input videos into? The videos I am
dealing with are printed from high speed film (1000 fps) for scientific
analysis frame-by-frame. I'm looking for a reasonable balance between
decoding speed and size. Image quality is of course important for seeing
detail in each frame of interest. Most important is that the frame shown
is actually correct for the time in question to match up with external
sensor data, so a format that does not use keyframes would also be
More information about the ffmpeg-devel