Opened 11 years ago

Closed 10 years ago

#1282 closed defect (fixed)

Frame level PSNR function for fields

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

Description

Function: xCalculateInterlacedAddPSNR

Issue:
Condition to call this function is not correct.

Test case:
Gop period is 32.
Interlaced frame related PSNR data collection should happen after POC 17 but it happens after POC 16 itself.

Some condition should be added based on "IRAPtoReorder" flag

Attachments (2)

ticket_1282.patch​ (1.1 KB) - added by barrouxg 11 years ago.
patch to solve the problem of frame equivalent PSNR computation being performed at the wrong moment in field mode
fix_1282.patch​ (5.9 KB) - added by barrouxg 10 years ago.
This new patch should solve the problem whatever cfg file we use

Download all attachments as: .zip

Change History (8)

comment:1 Changed 11 years ago by DefaultCC Plugin

  • Cc fbossen ksuehring davidf jct-vc@… added

Changed 11 years ago by barrouxg

patch to solve the problem of frame equivalent PSNR computation being performed at the wrong moment in field mode

comment:2 Changed 11 years ago by barrouxg

I added a patch taking in account the IRAPtoReorder to only call IRAPtoReorder at the right time. I tested it over few different configurations (LD / RA field mode and frame mode) and it seems to work.

comment:3 Changed 11 years ago by ksuehring

  • Milestone HM-15.0 deleted

Changed 10 years ago by barrouxg

This new patch should solve the problem whatever cfg file we use

comment:4 Changed 10 years ago by barrouxg

My ticket_1282.patch was only good when using a configuration file that would not invert the first top and bottom fields of a GOP. It was relying on the wrong assumption that the field swapping would only be done through the code associated to the EFFICIENT_FIELD_IRAP parameter.

The problem here is that when our encoder gets a field, it does not know whether the corresponding top or bottom field has already been encoded as well.

I added some code on the GOP level so that we can always check which picture has been encoded or not within the encoded GOP. This way our encoder can now scan through the GOP and look for the corresponding field to the one that is being encoded. If the corresponding field has been encoded then the encoder proceeds to the computation of the frame level PSNR values.

comment:5 Changed 10 years ago by ksuehring

  • Milestone set to HM-16.2
  • Owner set to ksuehring
  • Status changed from new to assigned

comment:6 Changed 10 years ago by ksuehring

  • Resolution set to fixed
  • Status changed from assigned to closed

the patch has been applied in r4130

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

  • David Flynn(Subscriber)
  • Frank Bossen(Subscriber)
  • Guillaume(Participant)
  • jct-vc@…(Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Owner, Subscriber, Participant, Always)
  • Mrigendra Nagar(Reporter)