[x264-devel] Re: HD Encoding

[Loren Merritt]

On Thu, 10 Feb 2005, Michael S. Kazmier wrote:

> I am experimenting with some HD encoding with x264.  I have a bunch of
> source material in 1920x1080i format (29.97 FPS).  The problem is, with x264
> you have to represent the resolution in a multiple of 16, which means the
> height must be represented as 1072, which creates for a not so nice encode.

True, not nice for HDTV with fixed aspect ratios. But while I haven't 
rerun compression tests in H.264 (I_4x4 and UMV might make a difference), 
cropping and/or scaling to mod16 was the most efficient method (in terms 
of PSNR per bitrate) in MPEG-4 ASP.

> 1) Is the mod 16 in there because only 4x4 and 16x16 blocks are currently
> processed (a forced limit if you will)

Macroblocks are always 16x16. 4x4 is simply a description of the 
prediction method within a 16x16 macroblock. The encoded video contains 
whole numbers of macroblocks, so it's impossible to encode resolutions not 
divisible by 16. What you can do (and is done for HD MPEG-2) is pad the 
frame (typically by duplicating the edge pixels) and then write cropping 
parameters in the header.
Encoder support is not necessary (other than writing the header), though 
it could reduce inefficiency by disabling the "distortion" part of RD in 
the padding region. In terms of x264, that means using 16x8 SA(T)D instead 
of 16x16 for the edge blocks, and forcing the padding residuals to be not 
coded.

> 2) Is anyone currently working on 4x8, 8x8, or 8x16 blocks?

The only MB types that are missing are Intra 8x8 (which depends on 
high profile's 8x8 transform) and Bidirectional 4x4 and 4x8 (I don't 
think these will provide a large improvement in compression compared to 
the CPU-time needed to evaluate them, especially in HD).

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html