[XviD-devel] Dev-API-4 : Possibility to mark a defined area of the encoded picture as 'BLACK=0' , to encode BlackBars with absolute minimum of bitrate ?

[Christoph Lampert]

On Tue, 29 Jul 2003, Christian HJ Wiesner wrote:
> Edouard Gomez wrote:
> 
> >Syskin has  better skills  in ME  than I, but  afaik, as  soon as  a SAD
> >comparison is zero, the ME returns and that's all done. This implies not
> >so much  CPU time  for the borders  (unless they  are not 16px  sized in
> >height, one  MB line will take  a bit more of  CPU, but it  would be the
> >case with "bb" hints anyway)
> >So i don't think it's worth overbloating user capabilities for gaining a
> >few cycles. Let's wait what our expert in ME says, c'mon syskin.
> >  
> >
> 
> sysKin replied to me in great detail on IRC, and unfortunately what he 
> was telling me was not at all motivating, as it seems MPEG4 is not 
> really suitable to use black bars for the picture. I cant repeat all of 
> his explanations, as i naturally only understood a small part of it ;-), 
> but basically it seems that MPEG4 Motion Estimation has a hard time 
> detecting motion if there is an edge, or even two of them, in the 
> picture. 

There is no "MPEG4 Motion Estimation". How to implement ME is complete up
to the user. But maybe you mean Motion Compensation, and then it's
somewhat true, that especially if global motion is present (camera
movement), then with black bars, object will (dis)appears "behind a black
block" whereas without bars, they will (dis)appear behind image
boundaries, and the latter is easier to encode. 
But I doubt that this effect is responsible for more than 0.5% extra
bitrate or so if the bars themselves are sized a multiple of 16. 
My impression from many tests was: Remove black bars if possible. 
But if you have to keep them (e.g. for rendering subtitles), then size 
them a multiple of 16 and it's not that much of a problem, either. 

> sysKin mentioned that MPEG4 in theory offers the possibility to 
> 'partition' a picture, but this is neither implemented in XviD nor 
> planned nor does anybody know anything about that.

Do you mean to encode several video objects and overlay? Maybe even
arbitrarily shaped? That's not part of Simple or Advanced Simple
Profile... which maybe is good, because decoding that is an ugly process. 
It's surely not worth implementing just to encode black bars. 
Or do you mean something like "slices" to split encoding the one
rectangular pictures into more than one subset of macroblocks? That might
be related to error resilience, but again it's not in SP or ASP and 
I can't see why it would be helpful. 

> >Concerning the resolutions, i've heard  that DVD could use a newer video
> >codec  in  near  future.  If  it's  MPEG4, you  should  stick  to  their
> >recomandation no ? 
>
> Well, from sysKin's explanation i learned that my considerations are 
> maybe completely wrong. If its true that MPEG4 cant handle black bars 
> very well, it makes more than sense that any hardware decoder HAS to 
> offer much better resizing capabilities to be able to handle various 
> different resolutions, and also interlaced, than the old MPEG1/2 decoder 
> chips would have ( that was the main reason why DVD/SVCD/VCD would only 
> support a couple of resolutions and aspect ratios at the beginning ). I 
> still feel that its a good idea to leave the normal 1:1 Pixel Aspect 
> Ratio scenario behind, my latest test encodings have shown that a 560 x 
> 352 anamorphic encoding ( Starwars EP2, 136 mins, VHQ 4, 2 b frames, 
> dx50 vop, h.263 quant ) was looking much better to my eyes than a 
> 'normal' 696 x 288 encoding with square pixels, while number of pixels 
> is almost the same for both. No idea if the codec will have a 
> 'preference' for a picture that is more 'square', or if its just the 
> visual perception of a higher vertical resolution, sysKin or you guys 
> may answer this better i guess.

My impression is that if the DVD or whatever source is anamorphic, with
non-square pixels, then it should be beneficial to encode with the 
same non-square pixels, because DCT area stays the same. Best would be to 
crop only multiples of 16 (or at least 8), whereas the effect will surely
be smaller when any rescaling is done instead of just cropping. 

gruel