Opened 8 years ago

Closed 8 years ago

#1148 closed defect (fixed)

Field-coding - incorrect depth calculation

Reported by: karlsharman Owned by:
Priority: minor Milestone: HM-14.0
Component: HM Version: HM-12.0
Keywords: Cc: fbossen, ksuehring, davidf, jct-vc@…

Description

The depth calculation in TEncSlice::initEncSlice appears to be wrong for field-coding.

You get (for randomaccess_field_coding) in decoding order

Field Depth QP Expected Depth

0 0 (base) 0
1 4 +1 0
16 0 +1 0
17 4 +1 0
8 1 +2 1
9 4 +2 1
4 2 +3 2
5 4 +3 2
2 2 +3 3
3 4 +4 3
6 2 +3 3
7 4 +4 3
etc

i.e. all odd fields have depth of 4, and a depth of 4 will be seen before a depth of 3, 2 or 1 has even been processed.

Attachments (2)

patch_1148.txt (638 bytes) - added by karlsharman 8 years ago.
TEncSlice.cpp.patch (427 bytes) - added by barrouxg 8 years ago.
Ticket1148Patch

Download all attachments as: .zip

Change History (7)

comment:1 Changed 8 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

Changed 8 years ago by karlsharman

Changed 8 years ago by barrouxg

Ticket1148Patch

comment:2 Changed 8 years ago by barrouxg

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.

comment:3 Changed 8 years ago by alexis

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.

comment:4 Changed 8 years ago by barrouxg

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.

comment:5 Changed 8 years ago by fbossen

  • Milestone changed from HM-12.1 to HM-14.0
  • Resolution set to fixed
  • Status changed from new to closed

Fixed in r3874

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • Alexis Tourapis(Participant)
  • David Flynn(Subscriber)
  • Frank Bossen(Subscriber, Participant)
  • Guillaume(Participant)
  • jct-vc@…(Subscriber)
  • Karl Sharman(Reporter)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Always)