[FFmpeg-devel] Delivery Status Notification (Failure)

[Reimar Döffinger]

On Mon, Apr 04, 2011 at 04:08:22PM -0700, Thomas Worth wrote:
> On Mon, Apr 4, 2011 at 5:51 AM, Michael Chinen <mchinen at gmail.com> wrote:
> > This year I am not eligible as a student, but I'm planning to work on
> > the seeking/index API more in may/june if no one else is doing this
> > for GSoC (and you guys haven't already implemented it - I haven't been
> > following so closely).  Or if someone is, I would be happy to help out
> > if they wished to continue my patches.
> 
> This is great, since the threaded H.264 seeking problem is holding
> back a project I'm working on. I've updated my page on this with some
> more info and a link to an example program and video clip:
> 
> http://rarevision.com/ffmpeg-mt/
> 
> Michael N., I noticed that the problem persists with the latest git of
> both ffmpeg and ffmpeg-mt. However, it does not affect Libav since I
> guess they haven't merged ffmpeg-mt yet. Also, you were asking about
> sample code. I updated the page above with a link, in case you're
> interested in taking a look. They way I've been testing is to link
> with ffmpeg (mt-enabled) libs, test, and then link with libav libs
> since there's no "non-mt" ffmpeg anymore. The problem should be
> obvious after doing that.

Seeking is not the problem, the problem is that obviously the reference
picture is missing, but for some reason also
h->default_ref_list[list][0].data[0]
is NULL
in ff_h264_decode_ref_pic_list_reordering.
I wonder a bit if it might have something to do with the
"//FIXME mt gives valgrind warnings and crashes if this is uncommented"
I think it was a really crappy idea to merge that as is, at least
these kind of changes should be under an if so that at the very least
the single-threaded case is not affected.