[Libav-user] Frames corruption when seeking...

[wm4]

On Fri, 30 May 2014 21:07:56 +1000
Jean-Yves Avenard <jyavenard at gmail.com> wrote:

> On 29 May 2014 23:34, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > Does this affect only "weird" sources (like ts captures etc.), or also
> > files using container formats designed to be seekable (like avi, mkv
> > etc.)?
> 
> i saw this with a plain mpeg-ts container, mpeg2 / mp2 and a mkv h264/ac3

Then you're probably doing something wrong. It's easily possible that
this "wrong" thing was right (or just didn't cause problems) before the
recent API changes.

> > Well, the API did change a lot regarding AVFrame management. I'm not
> > sure how compatible that API is to previous versions.
> 
> it certainly did change a bit... And actually this got me worried for
> a short while that maybe our code was leaking badly...
> 
> A question for you
> 
> After calling avcodec_decode_audio4, the AVFrame returned has data
> available in AVFrame::extended_data
> extended_data[0] containing channel 0 audio plane (or a pointer to the
> interleaved data),
> extended_data[1] to channel 1 etc...
> 
> When you free the AVFrame, it frees extended_data itself, but not the
> data pointed to.
> 
> That begs the question... Who is the owner of extended_data[n] ? the
> decoder allocates it via get_buffer(), but who frees it (and when)?

Are you using av_frame_free()? AVFrames are reference counted in the
most recent release, so freeing the data isn't as simple as it was.
av_frame_free() should take care of this properly.

But note that av_frame_free() is correct only for ffmpeg 2.2 and later.
In ffmpeg 2.1, av_frame_free() is available, but you must still use
avcodec_free_frame() _unless_ you enabled refcounting.

(That's pretty confusing, yep.)

> 
> 
> > Hm, this file doesn't work for me either. (I'm assuming you meant that
> > it doesn't work with the new API.)
> 
> oh, it works with the new API and VDPAU on nvidia cards.
> It doesn't work with VDPAU on either Nouveau (actually it can crash
> nouveau) nor AMD open source drivers. It plays green squares instead..

I get a mostly black screen with some artifacts when playing your video
with vdpau decoding on an older nvidia card with binary drivers.

> There are plenty of DVDs out there with exactly the same issue with
> VDPAU and decoding mpeg2.
> 
> Interestingly, mplayer from last year, which uses the old API, has no
> problem playing it.. I've spent several hours investigating why it
> worked for them but not us with no luck (xbmc using the old API has
> the same problems playing it)

I think it could have something to do with the demuxer, instead of the
API used. mplayer still uses its own demuxer (i.e. not libavformat) for
DVD, as far as I'm aware.