[x264-devel] Evaluating x264 -- first steps encoding greylevel images

[Eeri Kask]

>>> The problem with the above tool is, it either crashes x264, or sends
>>> it into a possibly never-ending loop; depending if the only '#if 1'
>>> in the above source is '1' or '0'.  I am using the latest git-source
>>> of x264.
>>
>> I'm pretty sure you don't want to be using fgetc for binary data.
>>
>> Just a hunch though.
>
> Apart from being excruciatingly slow, no harm will come of that.
> fgetc() reads exactly one byte, be it a complete character or not.
> fgetwc() reads characters in the current locale encoding.


Thank for taking a look, of course fread() is the better method to
read input.  :-)


After a moderate investigation I found the bug:

        /*flush*/
        while (x264_encoder_delayed_frames (h) > 0)
            if (EncodeFrame (out, h, &pic < 0)
                break;

shoud read instead

        /*flush*/
        while (x264_encoder_delayed_frames (h) > 0)
            if (EncodeFrame (out, h, NULL) < 0)
                break;

and all the discovered problems above are instantly gone, so it
looks like I have finally found the simple(st) (in terms of number
of C-code lines) method to transcode raw 8-bit greylevel data into a
H264-stream.  :-)


Nevertheless further studying x264.c and input/yuv.c (which is the
module coming closest to my use case) I spotted there is some
initialising something like

        param.b_vfr_input = 0;
        param.i_timebase_den = param.i_fps_num;
        param.i_timebase_num = param.i_fps_den;

which, if _not_ carried out, has seemingly no apparent effect on
created h264-stream either, which seems correct nevertheless (by
visually observing by mplayer for now); so this initialisation
probably is not essential for x264 operation?

The same goes for

        pic.i_pts = cnt++;
        pic.i_type = X264_TYPE_AUTO;
        pic.i_qpplus1 = 0;

in the loop of transcoding the stream, right in front of calling the
frame encoder; it seems to have no impact on anything in
"Grey8_to_H264.c" either; again, though, x264.c contains these.


In order to take x264 further beyond recreational deployments it
would be great if at least yuv444-planar input encoding would be
supported for color images, how much would it be different from
current yuv420 implementation?

Thanks,

    Eeri Kask