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

[Jason Garrett-Glaser]

> 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 FPS header and some ratecontrol modes (e.g. bitrate mode) depend
on the FPS and pts being set correctly.

> 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.

TYPE_AUTO and qpplus1 are already set in picture_alloc, iirc.  PTS are
only necessary if b_vfr_input =  1.

> 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?

A lot of work.  It's currently a summer of code project idea:
http://wiki.videolan.org/SoC_x264_2010 .  The primary problem is that
we don't currently have a _decoder_ for yuv444 (except of course the
reference).  Any useful implementation would also have to write
support for libavcodec as well.

Dark Shikari