The aim of this project is to develop an encoder and decoder (codec) to implement H.263 with all its four negotiable options enabled. As a mid-term check-point, the base codec has been developed (without the negotiable options).
The encoder and the decoder were written separately as they shared very little code in common except for some header files. The encoder in particular had been partially developed as a result of the series of homeworks implementing DCT, motion compensation and half-pel motion compensation.
The Draft ITU-T Recommendation H.263 (dated 2 May 1996) was used as a reference for the specifications of the encoder and the decoder. The above document was obtained from http://www.pictel.com/
The following sections detail the development of the encoder and
the decoder.
As was mentioned above, only the base level encoder has been developed thus far. The H.263 specification states that encoders shall be able to operate with either sub-QCIF or QCIF and were not obliged to operate with both. I have used QCIF (176x144) as the supported format for my encoder as this allows me to reuse the components developed in homeworks 2 to 5.
Other parameters specified by the H.263 document that I selected for my encoder were a reference frame rate of 30000/1001 (29.97 Hz) and a quantization step size of 8.
The reference document also requires that the encoder should provide a mechanism to restrict the maximum picture rate by having a minimum number of non-transmitted pictures between transmitted ones. To cater to this requiement, the encoder accepts a command line option "-s <n>" where <n> is the number of frames to be skipped between transmitted frames. This scheme allows the sender to tailor the outgoing bitstream to whatever frame rate is acceptable.
While testing the encoder, I also encountered the two sample videos that we used for our homeworks (weather.yuv and children.yuv) that were originally at 10Hz instead of the required 25 or 30. I have added a command line option to accept source images of different frame rates although this does not seem to be part of the standard.
The main coding challenge for the encoder was the correct implementation
of the bitstream (In particular, using stuffing to meet the timing
requirements and the required byte alignment of all new pictures).
The specifications required that the decoder be able to decode Sub-QCIF as well as QCIF. This has been done but I was not able to test the Sub-QCIF portion of the decoder as my encoder only produced bitstreams from QCIF sources.
I have coded the decoder to save the Y, U and V components of
the decoded images in separate files as I was hoping to view the
Y portions using "xv". I was unable to get xv to recognise
the format of these "Y" sections, however, and ended
up using the Xlib routines posted on the class bulletin board
to display the output buffer. A reference inverse DCT algorithm
was also found on the MPEG2 source distribution "mpeg2decode,
© 1994, MPEG Software Simulation Group" that meets the
error tolerance specified in Annex A of the H.263 specifications
Currently, the output files are still separated into three Y,
U, V files. I hope to combine these into the same format as the
yuv files used as inputs to the encoder.
Due to time constraints, I have not had the opportunity to perform
the conformance requirements test on the encoder and decoder as
specified in the Draft Conformance Requirements document. I hope
to be able to do this for the full featured codec to be developed
by the end of the semester.
My testing has been limited to decoding bitstreams that were encoded
by my own encoder and viewing them in a X-window screen.
As specified in the project proposal, the four negotiable options will be added to the encoder and decoder. I also hope to be able to support more file formats on the encoder, but Sub-QCIF at the very least (so that I may test my decoder with it).