Motion compensation bugs

  • Marco Gerards

    Marco Gerards - 2007-09-12


    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 - 2007-09-25

      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!




Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks