From dimitry at andric.com  Tue Oct 12 11:29:01 2021
From: dimitry at andric.com (Dimitry Andric)
Date: Tue, 12 Oct 2021 13:29:01 +0200
Subject: [x264-devel] Busy looping when flushing encoding operation?
Message-ID: <12E27FB7-63FA-4C62-9847-FA7D0E1209E1@andric.com>

Hi,

While integrating x264 into an encoding project, I noticed that the
logic for flushing any delayed frames out of the encoder basically
requires using a form of busy loop, e.g. something like:

    h = x264_encoder_open( param );
...
    while( !end_of_input() )
    {
        ...
        i_frame_size = x264_encoder_encode( h, &nal, &i_nal, pic, &pic_out );
        ...
    }
    /* Flush delayed frames */
    while( x264_encoder_delayed_frames( h ) != 0 )
    {
        i_frame_size = x264_encoder_encode( h, &nal, &i_nal, NULL, &pic_out );
        ...
    }

What appears to happen is that in the latter loop, x264_encoder_encode()
sometimes has to be called quite a large number of times to have x264's
background threads deliver a frame (i.e. until i_frame_size > 0). So
effectively, in your calling code you then are busy-looping, eating up
one CPU core.

Is there any reason that x264_encoder_encode() with a NULL pic_in
parameter couldn't block for the delivery of a frame more efficiently?
As it can rely on x264's internal thread state, it could maybe wait on
some mutex or condition variable, which is a lot lower in CPU cost.

-Dimitry