On Fri, 21 Sep 2007 18:06:32 +0200, Jeff Downs <heydowns at borg.com> wrote:
On Thu, 20 Sep 2007, Martin Zlomek wrote:
The attached patch fixes CurrPicNum of short term reference fields/frames in reference picture list reordering.
--- h264.c.orig 2007-09-20 23:30:38.000000000 +0200 +++ h264.c 2007-09-20 23:30:53.000000000 +0200 @@ -3056,6 +3056,9 @@ add = 0; }
+ if (pred > h->curr_pic_num) + pred -= h->max_pic_num; + for(i= h->short_ref_count-1; i>=0; i--){ ref = h->short_ref[i]; assert(ref->reference == 3);
This doesn't look right -- shouldn't the wrap check come prior to the block at the start of the patch? At this point of insertion, frame number to look for has already been determined. Also, pred value can't be modified like this; it can be used in subsequent iterations of the loop and has to retain the unmodified value.
This is actually not intimately tied to PAFF support; this was there all along so I'm guessing this should be kept distinct from the PAFF support patches.
So, the attached patch is one more to add, to be applied after the PAFF patches. A different (smaller) patch is needed if we want to fix prior to PAFF.
-Jeff
It seems that it is wrong, but it is not really true. You are right that I have applied formula 8-37 in "8.2.4.3.1 Reordering process of reference picture lists for short-term reference pictures" section of h.264 spec in a wrong way, but it is "fixed" in each following loop of the for-cycle by line pred &= h->max_pic_num - 1; Anyway, my previously posted patch should be replaced by the attached one; it has the same effect but looks better. For my tests, I use the following sample and the results are better with the patch: http://ftp3.itu.ch/av-arch/jvt-site/draft_conformance/MR6_BT_B.zip -- Martin Zlomek martin.zlomek at email.cz