[FFmpeg-devel] Delivery Status Notification (Failure)

[Thomas Worth]

On Tue, Apr 5, 2011 at 11:02 AM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> 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.

That's correct, seeking works fine -- the real problem surfaces when
when seeking directly past an I-frame because supposedly the decoder
can't reconstruct the frame without the I-reference (from what I
gather). Is it that seeking to a specific timestamp (after an I-frame,
for example), doesn't buffer the previous frame? When running a normal
decode loop, are frames automatically buffered? Is
avcodec_flush_buffers() responsible for clearing these same buffers?

An "if" as you suggested would be a good workaround until this is
fixed. In which file is the aforementioned code, by the way?