Début du message réexpédié :
> De : Lucas Soltic <[email protected]>
> Objet : Réexp : [Libav-user] Why is av_seek_frame() inaccurate in some cases ?
> Date : 16 avril 2012 12:07:55 HAEC
> À : "libavdevice and libavfilter. This list is about using libavcodec
> libavformat libavutil" <[email protected]>
>
>
> Début du message réexpédié :
>
>> De : Lucas Soltic <[email protected]>
>> Objet : Rép : [Libav-user] Why is av_seek_frame() inaccurate in some cases ?
>> Date : 14 avril 2012 19:24:01 HAEC
>> À : "This list is about using libavcodec, libavformat, libavutil,
>> libavdevice and libavfilter." <[email protected]>
>>
>>
>> Le 14 avr. 2012 à 18:49, Michael Bradshaw a écrit :
>>
>>> On Sat, Apr 14, 2012 at 10:40 AM, Lucas Soltic <[email protected]>
>>> wrote:
>>> So I don't think I did anything fancy, but I still can't find out why the
>>> video seeking is inaccurate. I would be really grateful if someone had
>>> ideas about this issue.
>>>
>>> There's two reasons I can see why you would be getting this result: 1) It
>>> could be seeking to the closest keyframe in the video, and 2) some demuxers
>>> seek by DTS and not PTS.
>>>
>>> You say it works fine for H.264 videos though, so I'm not entirely sure
>>> what could be causing it.
>>
>> Hello!
>>
>> I tried to use AVSEEK_FLAG_ANY for the av_seek_frame() parameter, so that it
>> does not only seek to keyframes, but it still gives important gaps.
>> As for the DTS, in the movie I read, they are equal to the PTS (for any of
>> the ~10 seeking I did). These results concern the MPEG4v2 video.
>> I'm going to investigate further with other codecs but I wanted to tell
>> these points.
>>
>> Lucas SOLTIC
>
>
> Actually I noticed than when seeking (even with AVSEEK_FLAG_ANY), the real
> sought position is 0 to 10s before the position I wanted. Then, if the video
> PTS is 9.90s before the position I wanted, and I seek a little bit further
> (say 0.1s), the video PTS becomes the exact position I wanted. So it looks
> like it's just seeking to keyframes, whatever seek flag I use.
>
> Considering this, are there more accurate ways to directly reach the expected
> position or should I just do avcodec_decode_video2() until the PTS becomes
> the one I wanted ? Decoding 10s of video could take some time on high
> resolution movies...
>
> Regards,
> Lucas SOLTIC
Sorry for the spam, I found another interesting point.
Actually if I disable the audio stream seeking (ie. do not call av_seek_frame()
for the audio stream), the AVSEEK_FLAG_* are correctly handled. And if I use
AVSEEK_FLAG_ANY for the video stream, I exactly get the PTS I wanted (with
artifacts in the image, but it's normal as I didn't seek to a keyframe), AND
the audio PTS is also correct, although I didn't do any seeking for the audio
stream. THUS I'm wondering why both streams are bound that way? Aren't they
supposed to be independent ?
Now, considering that I don't want to get artifacts, I suppose I still HAVE to
*don't* use AVSEEK_FLAG_ANY and do avcodec_decode_video2() for up to 10 seconds
of video in order to get full images, wherever I seek to. Am I right ?
One more question: what is the advantage of avformat_seek_file() over
av_seek_frame()? In the documentation it's written that the function isn't
"stable" yet and should therefore not be used right now. But in when I've
searched for solutions about my av_seek_frame() issue, I saw a lot of people
using this "unstable" function. Why ?
Regards,
Lucas SOLTIC
_______________________________________________
Libav-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/libav-user
