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

[Jean-Yves Avenard]

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

> 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)?



> 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..

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)