[libdv-dev] Re: dvgrab patch supports playdv (libdv)

[Charles 'B. K. <kr...@cs...>]

Alastair Mayer <ala...@aj...> writes:

> Hi,

>   I modified dvgrab a bit (added an option) so that it can output files
> in a format that 'playdv' (part of libdv) will recognize directly.  The
> patches are appended below, basically it adds a "--dv" option, i.e.
>    dvgrab --ntsc --dv --frames 150 foo
> would write 150 frames to foo.dv, and then
>    playdv foo.dv
> would display it.

Very nice.

> The performance of playdv has room for improvement: I get about 2 to
> 3 frames/second on my machine (a 233MHz winchip -- which supports
> MMX and 3DNow but otherwise has only about 156 bogoMips performance),
> this with the first release of libdv (I think there've been some
> improvements since).

Yes, our first priority has been to achieve correct playout.
Synchronizing with sound is an exception, since video performance has
to be better than real-time for normal playout.

> On other note -- the "pond.dv" file from the libdv folks seems to be
> recorded in progressive-scan mode, not interlaced.  

Yep.  A nice feature to have in a camcorder.  :)

> The interlaced data from my Sony TRV-103 that I've been testing with
> has a lot of motion (the camera was panning) so playdv spends about
> 40% of its time doing the 2-4-8 idct (and another 40% doing
> ycrcb->rgb conversion).

You observations are very astute.  Videos with motion and lots of
2-4-8 dcts suffer a major penalty in the current version of libdv.

The 2-4-8 idct in libdv is pathologically slow.  

I have a C version of 2-4-8 idct based on the AAN algorithm, the same
one that the Intel 8-8 MMX'd idct is based on, nearly complete.
MMX'ing that will follow.  Once that gets integrated, presence of
2-4-8's will have no impact on performance.

The ycrcb->rgb code has a similar story.  

Actually, we consider everything after macroblock placement to be the
"final video mile", which isn't really properly part of libdv.
Playdv.c does it out of necessity, in probably the dumbest way
possible, for the purpose of testing.

Eventually, that "final video mile" is better handled by format
independent components.  This is where the current soup that are Xv,
DGA, SDL, DRI, Hermes, gstreamer, etc. will hopefully come together.

> To make the image look nicer at the low frame rate I added code to
> playdv to deinterlace the image just prior to display (basically
> just copy every second scan line to the previous one, effectively
> doubling the pixel height and halving the vertical resolution).

Sounds like a sensible interim approach.

> I'm working on adding sound decoding now.

Great!  

-- Buck

> --- here's the patch for dvgrab to output playdv-friendly files ---

  [ snip ]