[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