[libdv-dev] Re: libdv changes

[Erik W. <om...@cs...>]

On Thu, 27 Apr 2000, Scott F. Johnston wrote:

> I'm trying to be more "block" based rather than "frame" based.
> For example, the conversion from YCrCb to RGB now occurs on blocks.
Good.  This is what we've been planning to do in general.

> I've also started calling things "dvc" as the video format may
> be known as miniDV, but since "dvb" and "dvd" may be supported
> by this library in the future, I thought I'd start making distinctions.
I suppose that makes sense.  Not sure it'll end up supported in this
library or not, probably not.  We're discussing the idea of a general
library for common video codec routines, but they wouldn't even have
codec-specific names on them.  Then again, the library is called libdv, so
it seems to make sense to stay with dv_*.  Buck is on vacation, we'll
discuss it when he gets back Tuesday.

> I've enabled "STRICT_SYNTAX" and instead of keeping track of the
> dif numbers and counting the video block numbers in "i,j,k"
> variables in a macroblock, I'm extracting difseq and difblock from the
> header of each macroblock.
We relied on keeping track because some of our videos didn't have valid ID
bytes.  Our Cannopus DVRex seems to capture video without correct IDs,
which was throwing me off for a while.

> If you look at "dvc_parse.c" you'll notice that
> I've included stubs for parsing all the blocks, not just the
> video blocks.
> Currently, the audio, subcode, and vaux blocks just pull
> data from the stream and return. (I haven't changed all the
> unsigned char's to guint8's yet, though.)
This should probably be changed to use the bitstream that's available, so
it's more generic.

> I've brought us closer to having a "library" by simplifying
> playdv to only contain a minimal front and and the GTK stuff.
Good.

> I've added dv2ppm to convert the frames to ppm images.
Cool.

> I've replaced "place" with a routine that unshuffles the
> location based on the dif and macroblock numbers.
> This should be converted into a table.
Yeah, the placement code has always been ugly...

> WARNING: I have not written unshuffle for PAL yet, so
> my work has temporarily broken PAL decoding.
If it gets into CVS in that form, I'm sure someone will fix it ;-)

> I've noticed that this decoder does not give the same results
> as the Quicktime decoder. I believe it has to do with compression
> of the dynamic range in the ycrcb to rgb conversion. I haven't
> poked around further to see about stretching the range, but I
> know it's a common thing to do.
Different good or different bad?  I know your ycrcb changes made it look
a heckuvalot more colorful...

> I hope I haven't broken anything else.
Just PAL.  You'll have to ask the Europeans for forgiveness for that
one... ;-)

I'm familiarizing myself with your changes now, and will try to merge them
into CVS in some form soon.

BTW, you should sign onto the mailing list, libdv-dev.  Makes it easier to
discuss this, since everyone else can chime in too ;-)

         Erik Walthinsen <om...@cs...> - Staff Programmer @ OGI
        Quasar project - http://www.cse.ogi.edu/DISC/projects/quasar/
   Video4Linux Two drivers and stuff - http://www.cse.ogi.edu/~omega/v4l2/
        __
       /  \             SEUL: Simple End-User Linux - http://www.seul.org/
      |    | M E G A           Helping Linux become THE choice
      _\  /_                          for the home or office user