Developing

This is the page for discussion of the CUDA implementation. Overview of the encoding process is available here: http://forum.doom9.org/showthread.php?p=1166447#post1166447.

Discussion on the x264 mailing list about the tasks:

http://search.gmane.org/?query=cuda&group=gmane.comp.video.x264.devel

Random x264 documentation: http://akuvian.org/src/x264/

Road Map

The initial goal is getting the motion estimation logic into CUDA. Preliminary results show that it is impractical to to merely "copy and paste" the pre-existing motion estimation code into CUDA and then attempt to compile (the exisiting code heavily usues pointers which make it hard to have the code run in CUDA as it tries to call invalid memory address).

Loading in Video Files

In order to avoid (re)writing video loading code, we can take advantage of the code already available in the x264 encoder.

In z264.c, in the Encode procedure, the following line is called:

p_read_frame( &pic, opt->hin, i_frame + opt->i_seek )

This line will load the specified input file into pic (a struct x264_picture_t).

We can begin writing our CUDA code right after this line.

Another line of interest is: x264_frame_copy_picture( h, fenc, pic_in ) which copies the x264_picture_t into a x264_frame_t struct.

For some reason x264_picture_t have 4 color spaces whereas x264_frame_t have three (as would be expected)

<Dark_Shikari> cancan101: legacy

<Dark_Shikari> x264 used to support colorspace conversion a long time ago

<Dark_Shikari> RGBA has 4 color planes