Motion compensation bugs

  • Marco Gerards
    Marco Gerards


    There are a few more bugs (shoot me if I am wrong ;)) in the specification:

    xstop = min (xstart + xblen, lenX)  = min ((i + 1)  xbsep + xoffset, lenX)
    ystop = min (ystart + yblen, lenY ) = min ((j + 1)  ybsep + yoffset, lenY)

    (page 75)

    It's wrong to use xstart and ystart here. Both can't become lower than 0
    because of the way it is defined. The last part of both lines is correct.

    On page 122, picture_weight_ref1 and picture_weight_ref2 are set to 1
    by default. The same is done for picture_weight_bits. However, in practise
    picture_weight_ref2 and picture_weight_bits are both zero in the case that
    only one reference frame is used.

    Are these weights used at all? Is this a bug or am I misunderstanding the
    specification in some way?


    • Thomas Davies
      Thomas Davies

      Yes, you're right about p75. Fixed.

      The weights really only specify the weightings of the two references in REF1AND2 prediction modes. You can specify how unidirectional prediction works in a number of ways: what you say is equivalent to the default values in the code.

      It's not done in Dirac ATM, but it could be that non-default picture weights are used, for example for a cross-fade. For REF1AND2 mode it's clear what to do. For uni-directional modes you could just always use weight = 1, bits =0. But then the only way to predict a fade to black would be to do REF1AND2 prediction always, in order to get the non-unity weighting factors. The way it's done in the spec, you can set the picture weights so that a fade to black is appropriately weighted, although it's admittedly a bit artificial.

      If you have ideas how to specify this so that we have flexibility for both 1 and 2 references I'm happy to redo this!