[x264-devel] How to flush delayed frames?

[Jason Garrett-Glaser]

On Wed, Mar 17, 2010 at 3:43 PM, Alex Sadovsky <alexeysad at gmail.com> wrote:
> On Thu, Mar 18, 2010 at 12:28 AM, Jason Garrett-Glaser
> <darkshikari at gmail.com> wrote:
>> On Wed, Mar 17, 2010 at 2:17 PM, Alex Sadovsky <alexeysad at gmail.com> wrote:
>>>>>>
>>>>>> You need to pass encoder_encode a NULL input to signal x264 that there
>>>>>> are no more frames coming.
>>>>>
>>>>> That's what I'm trying to do, but x264_encoder_delayed_frames returns zeroes
>>>>> and delayed frame counter stays at it's value, something around 3 or 5 frames.
>>>>
>>>> What is the "delayed frame counter"?  libx264 doesn't have one.
>>>
>>> Ok. No wonder that x264_encoder_delayed_frames returns values that aren't in any
>>> correlation to actual encoder state.
>>
>> Oh, of course it _has_ one internally, it's just not part of the API.
>> x264_encoder_delayed_frames() accesses the internal data and gives it
>> to you.
>>
>> I just don't see what you mean by "delayed frame counter"--the only
>> externally accessible delayed frame counter is
>> x264_encoder_delayed_frames.
>>
>>>>
>>>> Probably a lot.  I would recommend you use a compiler that isn't a
>>>> pile of garbage; if you insist on Microsoft's IDE, you can at least
>>>> use ICL.
>>>
>>> Last time I checked there was not such a compiler (that isn't a pile
>>> of garbage).
>>
>> This is true.
>
> Well, adding "__attribute__((force_align_arg_pointer))" before
> x264_encoder_encode indeed helps "sliced-threads", the crash was in
> x264_deblock_v_luma_sse2. And delayed frames are flushed just as
> expected. So, I'll use "sliced-threads" for now. Will see later why in
> frame based threading mode it behaves differently.

You're right, there's a bug in sliced threads that doesn't align the
stack correctly during deblocking.  This will be fixed in the next
release.

Thanks for the bug report.

Dark Shikari