[Libav-user] Why does av_seek_frame() not seek to a keyframe?

[Don Moir]

----- Original Message ----- 
From: "Don Moir" <donmoir at comcast.net>
To: "This list is about using libavcodec, libavformat, libavutil,libavdevice 
and libavfilter." <libav-user at ffmpeg.org>
Sent: Sunday, August 05, 2012 6:36 AM
Subject: Re: [Libav-user] Why does av_seek_frame() not seek to a keyframe?


> ----- Original Message ----- 
> From: "Roger Pack" <rogerdpack2 at gmail.com>
> To: "This list is about using libavcodec, libavformat, 
> libavutil,libavdevice and libavfilter." <libav-user at ffmpeg.org>
> Sent: Thursday, August 02, 2012 2:48 PM
> Subject: Re: [Libav-user] Why does av_seek_frame() not seek to a keyframe?
>
>
>>> I believe that does no seeking there. Putting -ss after the input will 
>>> cause
>>> ffmpeg to demux up to the requested timestamp, so it's not quite related 
>>> to
>>> seeking (putting -ss before the input will seek the input file).
>>>
>>> Since -a/vcoded copy avoids re-encoding, it just copies the packets 
>>> (without
>>> regard to keyframes, iiuc). The packet closest to 90 seconds probably 
>>> isn't
>>> a keyframe, but since that's where you requested the start it ffmpeg 
>>> starts
>>> copying packets from there anyway.
>>
>> Yes I would totally agree with you, except I can't find a single "-ss"
>> time that seems to "accidentally hit an i-frame" and work the way you
>> and I would expect it to...though I haven't looked into it much...
>> -r
>
> Given that seeking on mpeg2video does not seek to a key frame unless you 
> get lucky.
>
> I did a couple of test and normally for mpeg2video the first frame read 
> after a seek is not a key frame which causes a delay in the animiation. 
> Then I seeked to known keyframe times and that seems to successfully seek 
> to a key frame. I did this a couple times. For testing, I got the known 
> keyframe times by looking at the data after a seek.
>
> So when seeking backward you should always be at a keyframe at or before 
> your requested time but in the case of mpeg2video it does not happen.
>
> o - Is there an intent to get this reported as a bug if not already ?
>
> o - If it is reported as a bug, whats the likelyhood it will be fixed ? I 
> think I saw somewhere that it has been known for sometime or something to 
> that effect.

I see this has been reported as ticket #1575 but why this is reported as an 
enhancement and not a bug, god only knows.

This should not be a documentation issue and in my way of thinking, its a 
bug. We don't need gray areas like this and the frustration just gets passed 
on to everyone.