[Ffmpeg-devel] av_seek_frame() units
Wed Jul 6 23:52:56 CEST 2005
Steve Willis wrote:
> 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
>>> the general
>>> 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
Couldn't you convert it to MPEG, specifying that only I-frames (keyframes)
be used? Then the "seek only directly works to I-frames" feature wouldn't
be a problem...
More information about the ffmpeg-devel