[XviD-devel] Extended BFrame support
peter ross
xvid-devel@xvid.org
Thu, 07 Nov 2002 08:54:02 +1100
hi,
>From: Dirk Knop <dknop@gwdg.de>
>I've been playing around with sysKin today at BFrames and proper support
>for them (e.g. through VfW interface).
>We added a few flags for the stats-files (we're just tesing gruel, that's
>no final thing ;) ):
great.
>#define NNSTATS_KEYFRAME (1<<31)
>#define NNSTATS_BFRAME (1<<30)
>#define NNSTATS_SKIPFRAME (1<<29)
>
>And added the values 2 for bframes and 3 for skipped frames to
>pFrame->intra.
>
note: by doing this, i think you will break gknot compatibility.
i suggest using one of the unused NNSTATS fields.
>After playing around with it a little I found that the frame-sizes get
>re-sorted to reflect the resorting process for the container format, but
>the frame-type flags aren't! That's a little weird and not at all to handle
>from vfw, since vfw can't guess what's a bframe, pfame or iframe from
>anything (caused by the dynamic I/P/B-decision on 1st pass).
my idea was:
modify xvidcore such that XVID_ENC_STATS are returned in display order,
and add a frame_type and frame_length fields to XVID_ENC_STATS.
this tells vfw what the frame type was, AND, nicely handles packed
bframe mode. in packed mode, frame->length refers to the length of the
pvop and the bvop.
>sysKin managed to give full control over the second pass back, but
>unfortunately I can't do much more without having sorted this issue out.
for api3 iam planning to incorporate ratecontrol/2pass into xvidcore.
this should hopefully be ready in early december. i also intend to
keep XVID_ENC_STATS support, so this *will not* break vfw 2-pass.
cya
-- pete
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus