[Libav-user] Why does av_seek_frame() not seek to a keyframe?
donmoir at comcast.net
Sun Aug 5 13:51:00 CEST 2012
----- 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
>>> ffmpeg to demux up to the requested timestamp, so it's not quite related
>>> seeking (putting -ss before the input will seek the input file).
>>> Since -a/vcoded copy avoids re-encoding, it just copies the packets
>>> regard to keyframes, iiuc). The packet closest to 90 seconds probably
>>> a keyframe, but since that's where you requested the start it ffmpeg
>>> 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...
> 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.
More information about the Libav-user