Re: [libdv-dev] Frame encoding using change regions

[Roman S. <rv...@su...>]

On Mon, Aug 23, 2004 at 06:39:35AM -0700, Andrea and Jamie wrote:
> Hello,
> 
> I would like to bounce an idea off of this list...
> 
> What would libdv developers think of adding the ability to encode a dv frame using the following
> inputs:

  First of all, as far as I know there's no active development of libdv
  anymore. Just a very helpful maintenance. By the way, if this is a
  wrong perception -- I'd be happy to listen to anyone who begs to 
  disagree :-) Anyhow...

> - The original dv frame from the input file
> - the altered frame buffer, in RGB or YUV or whatever
> - and, a change list that details what regions of the frame were modified. EG, a list of
> rectangles.
> 
> This could provide two big benefits:
> - greatly reduced computation in some situations
> - The potential for applying some effects with absolutely no loss whatsoever to most of the video
> frame.

  Unfortunately it ain't so simple, as they say. Here's why: minimal coding
  unit in DV video is something called video segment, which is a collection
  of 5 MacroBlocks (8x8 blocks of pixels) taken from very distinct places in
  the frame. For example video segment #1 could have its 5 MacroBlocks
  arranged like this:

  +---------------------------
  |X
  |            X
  |
  |
  |    X
  |
  |                      X
  |         X
  
 
  Given the fact that most of the overlays will be three or four times larger that 8x8 
  and they will be most likely off kilter given the video segment pattern we
  will have to reencode quite a few 8x8 blocks. Which brings us to the next
  question -- quality.

  Now, the perceived quality of an image parts of which has been reencoded and
  others stayed the same is usually worse than "uniformally" degraded image. 
  At least this has been my experience.

  Speaking of quality -- have you tried ffmpeg's DV ? It's known to have
  better quality than libdv. Both in terms of PSNR and in terms of green
  shift of the reiteration.

Thanks,
Roman.