Re: Re[2]: [XviD-devel] scene change detecting in Bframes mode

["peter ross" <suxen_drol@xxxxxxxxxxx>]

> I frames are smaller because they use predictions of DCT coefficients
> between macroblocks, while in P frame all blocks are independant. (OK
> I might be wrong here, please correct me).

syskin, i think you've got I-frames and P-frames mixed up.

in mpeg-4 we have two main macroblcok modes:
INTRA macroblock are independant
INTER macroblocks use the previous frame as a reference, therefor is
dependant on the previous frame.

I-frames consist entirely of INTRA macroblocks
P-frames can consists of both INTRA and INTER macroblocks

Currently the ME-based scene detector works like this:
1. assume this frame is a P-frame, and perform motion estimation (m.e. 
decides the macroblock mode for each macroblock in the frame).
2. if the number of INTRA macroblocks for this frame is greater than
  some threshold (typically 50%), then encode this frame as an I-frame.

> > would it be possible to code a false-I-frame? i mean a P-frame who keeps 
> the
> > background and
> > adds a static image on it, instead of trying to estimate an non-existing
> > movement.
>
> Every P frame is like this, because every MB in such frame can be
> intra. However there is no prediction between the intra blocks so a P
> frame saturated with intra blocks will be much bigger than a similar I
> frame. (again, please correct if I'm wrong).

YES. if parts of the P-frame are completely un-identical to previous
frame, these are coded as INTRA macroblocks.

> I don't think my answers helped you ;) But, as we all know, it is a
> difficult subject.
>
> Now I have a question: Why can't we use the current (ME-based)
> scene-detection algo?
> Of course I don't want to conduct P-frame ME for every frame. I only mean
> doing it for a P frame. If this frame will turn out to be from new
> scene, THEN go back one frame (in viewing order) and check which scene
> is this. Keep going back until you found the last frame of old scene
> (and encode it as P - ME is done already; encode the frames before as
> B, next frame [first of new scene] as I).
> There is no waste in computing power unless there is many B-frames and
> lots of scene changes. No more than current max_bframes = -1, anyway.
>
> The only problem I see is putting it into bitstream in VfW
> compatibility mode.
> Please enlighten me what's wrong with it. Or ask questions if what I
> said is difficult to understand.

syskin, isn't this simular to what gruel suggested earlier (that is: use me 
for scenedetection). YES its possible, although will require
some smarting programming.

For each frame we assume its going to be a P-frame ad perform motion 
estimation. After the m.e. we then decide on the frame type
- I-frame: code the i-frame
- P-frame: perform motion compensation && code the P-frame (no need to 
perform m.e. since its already done)
- B-frame: perform additional m.e. and code the b-frame.

The existing frame ordering code should not need any changes.

The difficult part is, the B-frame "additional m.e.":
B-frames use a different prediction model, so the P-frame vectors will
not be optimal. However, the P-frame vectors can be used as a good
starting point.

-- pete

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com