[x264-devel] Re: Rate control and scene change detection

[Kurosu]

On Sun, 11 Jul 2004, Måns Rullgård wrote:
> I was thinking it could be possible to combine the scene change
> detection with the regular motion estimation, something like this:
>
> - encode the frame as a P (or B) frame.
> - check some statistics collected during the encoding.
> - if some condition is met, assume a scene change and re-encode as I
> frame.
>
> This would waste the time for the P/B encoding at a scene change, but
> save the overhead of separate scene change detection for all other

Well, the proposed method based on ratio of block types is a lot less
complex than acutally encoding a frame (in fact, only motion estimation is
needed), so that's really the more complex solution that you are
suggesting.

> frames.  It could also be more accurate than a simple scene change
> detection method.

Yes, it depends if you want a perceptual scene change or just one that
triggers when P/B frames aren't that efficient.

> So, which statistics would be indicative of a scene change?  Number of
> intra coded MBs?  Number of skipped MBs?  Perhaps something involving
> motion vectors?

To confirm my sayings, here is the code used in XviD:
http://www.xvid.org/cvs/chora/co.php/xvidcore/src/motion/vop_type_decision.c?login=2&r=1.4

As one can see in MEAnalysis, there are several steps:
- recompute thresholds based on:
  . last Iframe positions
  . count of Bframes
  . different default thresholds
- do the per block motion estimation (it seems it will be reused, dunno
if it qualifies for being a pre-pass)
- update the global SAD based on different statistics (there's an early
exit when most of the macroblocks are to be intra-coded)
- based on normalized global SAD, return frame type.

So, it seems that a motion estimation prepass can be used, and that the
frame decision mostly relies on deviation/SAD values found, and not at all
on vectors (which could be very coarse anyway).

-- 
Kurosu (Kurosu (at) inforezo dot org)
Quidquid latine dictum sit, altum viditur

-- 
This is the x264-devel mailing-list
If you are in trouble, please contact <postmaster at videolan.org>