[x264-devel] How to flush delayed frames?

[Alex Sadovsky]

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.


Thanks


>
> Dark Shikari
> _______________________________________________
> x264-devel mailing list
> x264-devel at videolan.org
> http://mailman.videolan.org/listinfo/x264-devel
>