[Ffmpeg-devel] av_seek_frame() units

[Gary Corcoran]

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
>> http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 
> 
> 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 
> important.

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...

Gary