[Libav-user] Frames corruption when seeking...
nfxjfg at googlemail.com
Thu May 29 15:34:06 CEST 2014
On Thu, 29 May 2014 09:28:47 +1000
Jean-Yves Avenard <jyavenard at gmail.com> wrote:
> I just upgraded our local FFmpeg 1.2.6 used in our project (MythTV)
> with the latest 2.2.1.
> The user side of things haven't been changed one bit (e.g. still using
> exactly the same API) and to my surprise it all worked first go.
> What I have noticed however, is that following a seek, or right at
> startup, the first few frames being displayed are all corrupted, like
> it had been attempted to start with a non-reference frame... It only
> does so for a fraction of seconds
> This effect is seen with both H264 and mpeg2 videos, pure software decode
Does this affect only "weird" sources (like ts captures etc.), or also
files using container formats designed to be seekable (like avi, mkv
> Seeing that I haven't changed the user code, I was wondering if there
> had been any changes to how the FFmpeg API should be used between 1.2
> and 2.2 that would explain that behaviour ?
> Like having the force reset something, flush caches and what not
Well, the API did change a lot regarding AVFrame management. I'm not
sure how compatible that API is to previous versions.
> FWIW, I also had this issue happening when I converted our VDPAU code
> from the old API to the new hwaccel API, but only when using AMD or
> Nouveau drivers. As I couldn't find the reason, I reverted back to the
> old VDPAU API when using those drivers, only using hwaccel for nvidia
> (when using the old VDPAU API, this file
> http://www.avenard.org/files/media/mediatest/Ondine_clip.mpg doesn't
Hm, this file doesn't work for me either. (I'm assuming you meant that
it doesn't work with the new API.)
> But I'm sure there's a much simpler explanation for this...
> Hoping it's something very obvious that I've missed.
More information about the Libav-user