Ticket1148Patch

I believe the attached patch should correct this problem. It gives every bottom field a depth equal to one more than corresponding top field one.

I would somehow disagree with this solution since this prioritizes the top field in favor of the bottom field. For many applications that solution may be undesirable since it may end up giving worse quality to the bottom field than the quality given to the top. It might be better if maybe the software allows some more flexibility for this, possibly through some external signaling, allowing the user to either allocate quality to the two fields, or prioritize one in favor of the other. My suggested solution would instead be something like:

Int poc = isField ? ( (rpcSlice->getPOC()%m_pcCfg->getGOPSize() ) / 2 ) * 2 : rpcSlice->getPOC()%m_pcCfg->getGOPSize();

in place of the existing code, but I think this needs further investigation and may depend on other code modifications relating to field encoding.

Alexis' solution places the top and bottom fields at the same depth whereas mine keeps the regular pyramidal pattern used in the code and places the bottom fields one temporal id up. A user may want to prioritize the bottom field over the top one as much as he may want to prioritize the 2nd picture over the first one in a regular frame encoding. As we do not allow yet the users to define their preferred depth case by case for the frame mode, I just followed the general trend and provided a solution that I believe is in accordance with the general concepts of referencing structure.

Fixed in r3874