libdv-dev

[libdv-dev] RE: libdv and the intel mmx iDCT

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

On Thu, 27 Apr 2000 Mat...@no... wrote:

> May I ask what performance your decoder have at the moment. The raw decoder
> performance, not including such things as drawing picture on screen etc. I
> do not have access to cvs (firewall issues) so i cannot download and try it
> myself.

I just timed the current CVS version (with some new asm code as of last
night) at 2.5 seconds for 30 frames.  This doesn't include yuv2rgb or
display, just the decode itself.  This is on a PIII/500 coppermine laptop.

The major performance issues are the parse code, the brute-force idct
2-4-8 (which should be solved by Tuesday, hopefully), and the fact that a
lot of the stuff hasn't been collapsed yet from the naive
correctness-over-all implementation.  For instance, inverse quantization
is taking 10% of the time because it hasn't been merged with idct yet.

I've put a snapshot up on ftp.libdv.sourceforge.net for you.  It's a fresh
checkout of CVS, tar'd.  You can also download pond.dv from there, which
is what I did the aforementioned benchmark with.

TTYL,
    Omeag

         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

[libdv-dev] Converting to library

[James B. <ja...@ex...>]

Morning all,

I'm looking at task 13738, "Feature: Convert to library"
Does anybody have any feelings about how the interface should look?

Why the interest in making libdv a library?  Because then we could make
a regression test that decoded a  frame of pond.dv, then compared them
with "golden" images.  This would make some changes easily verifiable,
for example 13732, 13733, 13737, 13801.

Some changes - like 13731, 13735 - alter the precision of processed
data, so will inevitably make a slightly different final image.  In this
case the comparison would report the largest difference between the
"golden" and actual images.

So how about starting with something like:

dvs *dvs_open(void *(*reader_func)(void*), void *s, enum frame_format)
  Initializes a dv stream, with a given read_func. reader_func(s)
returns a pointer to the next 400 bytes in the stream.  frame_format
would be the target pixel format: 32-bit RGB, 16-bit RGB, raw YCrCb.

dvs_get_frame_dimensions(dvs *s, gint *x, gint *y)
  Returns the frame dimensions of open stream s, either 720x480 or
720x576.

dvs_decode_frame(dvs *s, frame *f)
  Decodes the next frame in the stream s into buffer f.

dvs_close(dvs *)

???

-- 
James Bowman
ja...@ex...

Re: [libdv-dev] Assembler for vlc

[James B. <ja...@ex...>]

Erik Walthinsen wrote:
> 
> On Wed, 26 Apr 2000, James Bowman wrote:
> 
> > Sorry, this code will not run as is, it requires changes to vlc.h and
> > vlc.c in order to work.  I can check it all in together right now... the
> > performance gain is modest - benchmark goes from 40.3s to 37.3s.
> 
> How did you incorporate the asm version?  I put it in vlc_asm.S and added
> an ifdef around the C version, as well as turned off the INLINE flag for
> the VLC stuff.

Yes, I put it in vlc_x86.S, removed the inline definitions from vlc.h,
and ifdefed out the C version with USE_ASM_FOR_VLC.

> Yeah, go ahead and check it in.

Cool.

I looked at the profile and it seems that the gains have been modest
because of more time in the parser.  Possibly it was unrolling the block
decode loop to some extent and scheduling instructions.  The decode
process is very serial right now, with branch mispredicts in lots of
places.

So I've been thinking about what would be the ideal implementation for
dv_parse_ac_coeffs_pass0().  This function seems to take about 29% of
execution time currently.

What's your plan for the "MMX getbits" task?  Reading an527, it looks
very branchy.

-- 
James Bowman
ja...@ex...

Re: [libdv-dev] Assembler for vlc

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

On Wed, 26 Apr 2000, James Bowman wrote:

> Sorry, this code will not run as is, it requires changes to vlc.h and
> vlc.c in order to work.  I can check it all in together right now... the
> performance gain is modest - benchmark goes from 40.3s to 37.3s.

How did you incorporate the asm version?  I put it in vlc_asm.S and added
an ifdef around the C version, as well as turned off the INLINE flag for
the VLC stuff.

Yeah, go ahead and check it in.

         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

Re: [libdv-dev] Assembler for vlc

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

On Wed, 26 Apr 2000, James Bowman wrote:

Some issues:

> .text
> 	.align 4
> .globl __dv_decode_vlc 
> 	.type	 __dv_decode_vlc,@function
> __dv_decode_vlc:
> 	pushl %ebx
> 
> 	/* Args are at 20(%esp). */
> 	movl  8(%esp),%eax		/* %eax is bits */
> 	
> 	movl  %eax,%edx			/* %edx is class */
> 	andl  $0xfe00,%edx
> 	sarl  $9,%edx
> 	movsbl dv_vlc_class_lookup5(%edx),%edx

I'm confused.  What does this do?

> 	
> 	movl  dv_vlc_index_mask(,%edx,4),%ebx
> 	movl  dv_vlc_index_rshift(,%edx,4),%ecx
> 	andl  %eax,%ebx
> 	sarl  %cl,%ebx
> 
> 	movl  dv_vlc_lookups(,%edx,4),%edx
> 	movl  (%edx,%ebx,4),%edx

This is where it segfaults right now.  I can't seem to get gdb to tell me
what's in the register, though.

> 
> 	/* Now %edx holds result, like this:
> 	   bits 0-7   run
> 	   bits 8-15  len
> 	   bits 16-31 amp
> 	*/
> 	/* code needs to do this with result:
> 	   if ((amp > 0) &&
> 	     if ((bits >> sign_rshift[result->len]) & 1)
> 	         amp = -amp;
> 	   }
> 	*/
> 	/* if (amp < 0) %edx is 0, else 0xffff0000. */
> 	movl  %edx,%ecx
> 	sarl  $8,%ecx
> 	andl  $0xff,%ecx
> 	movl  sign_mask(,%ecx,4),%ecx
> 	andl  %ecx,%eax
> 	negl  %eax
> 	sarl  $31,%eax
> 
> 	movl  %edx,%ebx
> 	sarl  $31,%ebx
> 	xorl  $0xffffffff,%ebx
> 	andl  $0xffff0000,%ebx
> 
> 	andl  %ebx,%eax
> 	
> 	xorl  %eax,%edx
> 	subl  %eax,%edx
> 
> 	movl  12(%esp),%eax
> 	movl  %edx,(%eax)
> 	
> 	popl  %ebx
> 	ret

         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

Re: [libdv-dev] Assembler for vlc

[James B. <ja...@ex...>]

Erik Walthinsen wrote:
> 
> On Tue, 25 Apr 2000, James Bowman wrote:
> 
> > I'd like to take a crack at the asm versions of __dv_decode_vlc and
> > dv_decode_vlc, so I'll be making a few changes in vlc.h and vlc.c, as
> > well as adding a new file for the asm implementation itself.
> 
> I'd suggest working on it in your working copy, and not checking into CVS
> for a day or so.  I have some ideas as to how a project like this can deal
> with multiple optimizations (for different processors, etc.), but I need
> to think about them a bit and go over the code as it's structured now.
> 
> That said, I think creating vlc_x86.[ch] with identical contents to the
> standard vlc.[ch] except for the code itself is a good place to start.
> We'll want to come up with some combination of stuff that allows a
> Makefile to select one or the other without having to duplicate tables and
> such.
> 
> I'll post tomorrow sometime on my ideas for this.
> 
> I'd be very interested in taking a peek at what you get as soon as you get
> something working, though, regardless of CVS.

Here it is, nice and branchless, just like the C.  Uses the tables
defined in vlc.c.

I actually tweaked the C a little before I started to make the job a
little simpler.  The biggest change was to make dv_vlc_t small enough to
fit in a single 32-bit word.  The main function now looks like this:

void __dv_decode_vlc(gint bits, dv_vlc_t *result) {
  gint class, has_sign, amps[2];
  
  class = dv_vlc_classes[16][(bits & (dv_vlc_class_index_mask[16])) >>
(dv_vlc_class_index_rshift[16])];
  *result = dv_vlc_lookups[class][(bits & (dv_vlc_index_mask[class])) >>
(dv_vlc_index_rshift[class])];
  amps[1] = -(amps[0] = result->amp);
  has_sign = amps[0] > 0;
  result->amp = amps[has_sign &  // or vlc not valid
		    (bits >> sign_rshift[result->len])];
} // __dv_decode_vlc


.text
	.align 4
.globl __dv_decode_vlc 
	.type	 __dv_decode_vlc,@function
__dv_decode_vlc:
	pushl %ebx

	/* Args are at 20(%esp). */
	movl  8(%esp),%eax		/* %eax is bits */
	
	movl  %eax,%edx			/* %edx is class */
	andl  $0xfe00,%edx
	sarl  $9,%edx
	movsbl dv_vlc_class_lookup5(%edx),%edx
	
	movl  dv_vlc_index_mask(,%edx,4),%ebx
	movl  dv_vlc_index_rshift(,%edx,4),%ecx
	andl  %eax,%ebx
	sarl  %cl,%ebx

	movl  dv_vlc_lookups(,%edx,4),%edx
	movl  (%edx,%ebx,4),%edx

	/* Now %edx holds result, like this:
	   bits 0-7   run
	   bits 8-15  len
	   bits 16-31 amp
	*/
	/* code needs to do this with result:
	   if ((amp > 0) &&
	     if ((bits >> sign_rshift[result->len]) & 1)
	         amp = -amp;
	   }
	*/
	/* if (amp < 0) %edx is 0, else 0xffff0000. */
	movl  %edx,%ecx
	sarl  $8,%ecx
	andl  $0xff,%ecx
	movl  sign_mask(,%ecx,4),%ecx
	andl  %ecx,%eax
	negl  %eax
	sarl  $31,%eax

	movl  %edx,%ebx
	sarl  $31,%ebx
	xorl  $0xffffffff,%ebx
	andl  $0xffff0000,%ebx

	andl  %ebx,%eax
	
	xorl  %eax,%edx
	subl  %eax,%edx

	movl  12(%esp),%eax
	movl  %edx,(%eax)
	
	popl  %ebx
	ret


-- 
James Bowman
ja...@ex...

[libdv-dev] Re: DV audio

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

On Wed, 26 Apr 2000, Alastair Mayer wrote:

> If anyone has a copy of this, could they summarize the relevant details
> sufficient for me to add decoding for 32kHz/12-bit and 44.1kHz/16-bit
> which it allows?

Ack, I left it at work.  I'll summarize it as compared to 314M when I get
into work tomorrow.

Did you happen to try your code on pond.dv, from
ftp.libdv.sourceforge.net?  It claims to be a 314M-compliant stream, and
should be 48kHz/16-bit (captured from Canon Elura), though every couple
dozen frames it changes to a 61834 stream for a frame, according to the
APT field.  I'm confused on that one, anyone have an idea why that would
be?

         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

Re: [libdv-dev] Assembler for vlc

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

On Tue, 25 Apr 2000, James Bowman wrote:

> I'd like to take a crack at the asm versions of __dv_decode_vlc and
> dv_decode_vlc, so I'll be making a few changes in vlc.h and vlc.c, as
> well as adding a new file for the asm implementation itself.

I'd suggest working on it in your working copy, and not checking into CVS
for a day or so.  I have some ideas as to how a project like this can deal
with multiple optimizations (for different processors, etc.), but I need
to think about them a bit and go over the code as it's structured now.

That said, I think creating vlc_x86.[ch] with identical contents to the
standard vlc.[ch] except for the code itself is a good place to start.
We'll want to come up with some combination of stuff that allows a
Makefile to select one or the other without having to duplicate tables and
such.

I'll post tomorrow sometime on my ideas for this.

I'd be very interested in taking a peek at what you get as soon as you get
something working, though, regardless of CVS.

TTYL,
    Omega

         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

[libdv-dev] Assembler for vlc

[James B. <ja...@ex...>]

Hi all, I just joined this project.

I'd like to take a crack at the asm versions of __dv_decode_vlc and
dv_decode_vlc, so I'll be making a few changes in vlc.h and vlc.c, as
well as adding a new file for the asm implementation itself.

--
James Bowman
ja...@ex...

[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 ]

Re: [libdv-dev] more PAL progress...

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

On Thu, 20 Apr 2000, Charles 'Buck' Krasic wrote:

> I guess the CVS commit log to mail gateway isn't up yet.  So this is
> just a heads up that with my latest commit, PAL now seems to work.

It seems that the list isn't quite up yet on sourceforge.  I'll put in the
proper CVS scripts when it's live, to avoid spamming some poor soul with
'unreachable'...

         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

[libdv-dev] more PAL progress...

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

I guess the CVS commit log to mail gateway isn't up yet.  So this is
just a heads up that with my latest commit, PAL now seems to work.

-- Buck

[libdv-dev] Re: libdv and PAL (IEC 61834) working (?)

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

On 20 Apr 2000, Charles 'Buck' Krasic wrote:

> Erik has gave me a program avispew that he got from dvgrab (with some
> slight tweak), which I used to pull the raw DV out of the .avi files.
The change was to comment out the printf and put in:

fwrite(buff,0x00023280,1,stdout);

Of course, this doesn't work for a file I grabbed a while ago, but that's
probably because it was done with dvgrab-0.2...

         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

[libdv-dev] CVS commits list?

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

For GStreamer I set up a CVS script that would send mail to gstreamer-cvs
any time a commit happened.  Should I set up the same for libdv?

         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

[libdv-dev] PAL (4:2:0) partially working.

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

I've checked changes into CVS for macroblock placement of 4:2:0 PAL
video.  Luma works, but the color is off.

-- Buck