libdv-dev

Re: [libdv-dev] XvImage support, YUV value range

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

On 30 Jul 2000, Charles 'Buck' Krasic wrote:

> Ah.  I tried this on my r128 box.  I see 120Mb write but only about 8M
> read.  Is this normal?

Yup.  Video cards are by design output-only devices.  That means all the
busses and such don't care about reads, so they're ignored, and thus very
slow.  This was one of Rasterman's primary points at his talk at LinuxTag.

         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] XvImage support, YUV value range

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

Stefan Lucke <lu...@be...> writes:

> dga is a program that ships with X11 and does a performance test of
> framebuffer access (You'll need root permission to do this).  DGA is
> an X11 extension (DirectGraphikAccess ?).

Ah.  I tried this on my r128 box.  I see 120Mb write but only about 8M
read.  Is this normal?

-- Buck

Re: [libdv-dev] XvImage support, YUV value range

[Stefan L. <lu...@be...>]

On Son, 30 Jul 2000, "Charles 'Buck' Krasic" wrote:
> The thing is, I just did some similar stuff this week :-}.  I apologize
> to anyone else who might be listening who's done the same.  It's
> unfortunate when effort is duplicated.

But that happens. So we have two possibilities of improvements.
I'll check yours later on.

> > I just did some tests with XvImages and hardware accelerated YUV to RGB
> > conversion. One problem was the value range used by the dv decoder.
> > (Y: [-223,+223]; UV: [~-63,~+63]). So adjusting the offset for 'ylut' by
> > 128 is not enough.
> 
> I'm not sure what you mean by this exactly.   
> 
> >From the smpte spec, section 5.1.1:
> 
> "Each pixel has a value from -127 to +126 which is obtained by the
>  subtraction of 128 from the input video signal level."
> 
> So the +128 offset is just the exact inverse what is done to the video
> signal level.
That means: I saw Y (*Ytmp) values of -223. UV (cr/cb) values are ok.
So indexing in a table which has only
a base offset of 128 will result in out of bounds addressing (perhaps
seg faults).
 
...
> What does the dga column mean?

dga is a program that ships with X11 and does a performance test of
framebuffer access (You'll need root permission to do this).
DGA is an X11 extension (DirectGraphikAccess ?).

-- 

mfg

  Stefan Lucke (lu...@be...)

[libdv-dev] Update XvImage patch

[Stefan L. <lu...@be...>]

Hi,

I updated XvImage patch with following changes:
    1. check for precence of an adaptor and port. If non of them
       is available use default (gdk) methods.
    2. removed some unused members of internal struct.
    3. speed up by small use of mmx instructions.

Performance table reads now:
                  |           | NTSC              | PAL               |
MB, CPU, GRA      | dga       | G[t|d]k | XvImage | G[t|d]k | XvImage |
------------------+-----------+---------+---------+---------+---------+
Asus P5A,K6-2/400,|  ~26MB/s  | R 24.13 | R 13.83 | R 25.49 | R 14.84 |
MGA-G200          |             U 18.33 | U  8.81 | U 19.22 | U  9.51 |
------------------+-----------+---------+---------+---------+---------+
DFIK6BV3+,P133,   |  ~56MB/s  | ------- | --------| --------+ ------- |
MGA-G200          |           |         |         |         |         |
------------------+-----------+---------+---------+---------+---------+
Asus P5A,K6-2/400,| ~120MB/s  | R 21.05 | R  9.66 | R 22.40 | R 10.33 |
MGA-G400          |           | U 18.28 | U  7.79 | U 19.39 | U  8.45 |

Notes:
  - Numbers measured on Asus motherboard are with kernel V2,4,0.test5
    and X11 V4.0.1
  - DFI motherboard was checked with kernel 2.0.16 and X11 3.3.?
  - The NTSC sequence is from pond.dv and PAL sequence is from a
    private video.
  - Both are truncated to 6 seconds (180 farmes for NTSC, 150
    frames for PAL).
  - XvImage times with G400 DH are now with mmx support
  - R/U values are from 'time playdv FILE' (real/user time values).

Happy testing. 
-- 

mfg

  Stefan Lucke (lu...@be...)

Re: [libdv-dev] XvImage support, YUV value range

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

Hi,

First off, let me say that I really appreciate your contribution, so
please try not to take offense at what follows.

The thing is, I just did some similar stuff this week :-}.  I apologize
to anyone else who might be listening who's done the same.  It's
unfortunate when effort is duplicated.

I've uploaded a patch to sourceforge with my version, for comparison.  

I've looked over your patch.  Here's how we differ.

I used the SDL library (www.libsdl.org) instead of doing Xv directly.
I think this results a smaller change to libdv overall, mainly in
setting up the display.  It probably gets better, i.e. SDL does more
work for us, when we add code for window scaling/resizing.

Based on your numbers and what I've seen timing my stuff, I think the
performance is the same.  This is logical since SDL is only a shim
over Xv.  See below for some more on performance.

Also, I preserved the existing gtk output code, since not everyone
will have machines that benefit from Xv.  Theoretically, SDL should
work for everybody, but I don't know how mature their SW YUV
convertors are. 

Stefan Lucke <lu...@be...> writes:

> Hi,

> I just did some tests with XvImages and hardware accelerated YUV to RGB
> conversion. One problem was the value range used by the dv decoder.
> (Y: [-223,+223]; UV: [~-63,~+63]). So adjusting the offset for 'ylut' by
> 128 is not enough.

I'm not sure what you mean by this exactly.   

From the smpte spec, section 5.1.1:

"Each pixel has a value from -127 to +126 which is obtained by the
 subtraction of 128 from the input video signal level."

So the +128 offset is just the exact inverse what is done to the video
signal level.

My SDL patch does a clamp to [0,255].  Without it I get problems with
superwhite and superblacks.  But I don't have to do [16,235].  

At least not on my hardware.  I'm using an ATI r128.  I had a
conversation with Erik earlier this week where he said that he thought
Matrox was different.  So maybe Erik can test my patch?

> Have a look at the following performance table:
                    |           | NTSC              | PAL              
|
MB, CPU, GRA        | dga       | G[t|d]k | XvImage | G[t|d]k | XvImage
|
--------------------+-----------+---------+---------+---------+---------+

[ ... numbers clipped ... ]

What does the dga column mean?

I get nearly identical improvements in the SDL version.

If you use gprof to get more detail, you will see some interesting
stuff.  Here is an example from the sdl version with the first 180
frames of pond.dv.

From time:

SDL:      8.69user 0.33system 0:10.84elapsed 83%CPU
G[t|d]k: 16.14user 0.47system 0:18.01elapsed 92%CPU 

                    |           | NTSC              | PAL              
|
MB, CPU, GRA        | dga       | G[t|d]k | XvImage | G[t|d]k | XvImage
|
--------------------+-----------+---------+---------+---------+---------+
asus ??             |  ???      | R 18.01 | 10.84   |         |
(440BX chipset),    |           | U 16.14 | 8.69    |         |
pII/400, ATI-r128   |  ???      |         |         |         |


From gprof:

SDL:

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ns/call  ns/call  name    
 25.77      2.00     2.00   243000  8230.45  8230.45  dv_mb_to_YUY2
 18.04      3.40     1.40                             readloop
  9.28      4.12     0.72                             idct_block_mmx
  7.86      4.73     0.61    48600 12551.44 24897.12  dv_parse_ac_coeffs
  7.73      5.33     0.60   656944   913.32   913.32  dv_find_spilled_vlc
  5.93      5.79     0.46                             done_decode
  5.54      6.22     0.43    39854 10789.38 10789.38  dv_idct_248
  5.28      6.63     0.41                             quant_88_inverse
  3.99      6.94     0.31                             dv_decode_vlc
  2.84      7.16     0.22                             main
  2.32      7.34     0.18                             __dv_decode_vlc
  1.55      7.46     0.12                             dv_parse_ac_coeffs_pass0
  1.16      7.55     0.09                             blkloop
  0.52      7.59     0.04  1418146    28.21    28.21  idct_88
  0.52      7.63     0.04                             slowpath
  0.26      7.65     0.02  1418146    14.10    14.10  weight_88_inverse
  0.26      7.67     0.02    39854   501.83   501.83  quant_248_inverse
  0.26      7.69     0.02                             alldone
  0.19      7.71     0.01                             escape
  0.13      7.71     0.01   243000    41.15    41.15  dv_place_411_macroblock
  0.13      7.72     0.01    48600   205.76   205.76  bitstream_new_buffer
  0.13      7.74     0.01                             do_ac_pass
  0.13      7.75     0.01                             done_ac
  0.13      7.75     0.01                             its_mono
  0.06      7.76     0.01                             escape1
  0.00      7.76     0.00    39854     0.00     0.00  weight_248_inverse
  0.00      7.76     0.00    15026     0.00     0.00  bitstream_next_buffer
  0.00      7.76     0.00        1     0.00     0.00  bitstream_init
  0.00      7.76     0.00        1     0.00     0.00  dct_init
  0.00      7.76     0.00        1     0.00     0.00  dv_YUY2_init
  0.00      7.76     0.00        1     0.00     0.00  dv_YV12_init
  0.00      7.76     0.00        1     0.00     0.00  dv_construct_vlc_table
  0.00      7.76     0.00        1     0.00     0.00  dv_dct_248_init
  0.00      7.76     0.00        1     0.00     0.00  dv_parse_init
  0.00      7.76     0.00        1     0.00     0.00  dv_place_init
  0.00      7.76     0.00        1     0.00     0.00  dv_ycrcb_init
  0.00      7.76     0.00        1     0.00     0.00  weight_88_inverse_float
  0.00      7.76     0.00        1     0.00     0.00  weight_init

and gprof for G[t|d]k:

  %   cumulative   self              self     total           
 time   seconds   seconds    calls  ns/call  ns/call  name    
 40.10      3.91     3.91   237600 16456.23 16456.23  dv_ycrcb_411_block
 11.44      5.03     1.11                             readloop
  7.28      5.74     0.71                             idct_block_mmx
  6.77      6.39     0.66    48600 13580.25 26337.45  dv_parse_ac_coeffs
  6.36      7.01     0.62   656944   943.76   943.76  dv_find_spilled_vlc
  5.44      7.54     0.53                             quant_88_inverse
  4.82      8.02     0.47    39854 11793.04 11793.04  dv_idct_248
  4.56      8.46     0.45                             done_decode
  2.77      8.73     0.27                             dv_decode_vlc
  1.74      8.90     0.17                             main
  1.23      9.02     0.12                             dv_parse_ac_coeffs_pass0
  1.13      9.13     0.11  1418146    77.57    77.57  idct_88
  1.13      9.24     0.11                             __dv_decode_vlc
  1.03      9.34     0.10     5400 18518.52 18518.52  dv_ycrcb_420_block
  1.03      9.44     0.10                             blkloop
  0.72      9.51     0.07                             slowpath
  0.51      9.56     0.05   486000   102.88   102.88  dv_place_411_macroblock
  0.31      9.59     0.03                             alldone
  0.26      9.62     0.03                             do_ac_pass
  0.26      9.64     0.03                             escape
  0.21      9.66     0.02  1418146    14.10    14.10  weight_88_inverse
  0.21      9.68     0.02    48600   411.52   411.52  bitstream_new_buffer
  0.21      9.70     0.02    39854   501.83   501.83  quant_248_inverse
  0.15      9.71     0.01                             ampnonzero
  0.10      9.72     0.01                             escape1
  0.10      9.73     0.01                             macloop
  0.10      9.74     0.01                             skarly
  0.05      9.75     0.01                             done_ac
  0.00      9.75     0.00    39854     0.00     0.00  weight_248_inverse
  0.00      9.75     0.00    15026     0.00     0.00  bitstream_next_buffer
  0.00      9.75     0.00        1     0.00     0.00  bitstream_init
  0.00      9.75     0.00        1     0.00     0.00  dct_init
  0.00      9.75     0.00        1     0.00     0.00  dv_YUY2_init
  0.00      9.75     0.00        1     0.00     0.00  dv_YV12_init
  0.00      9.75     0.00        1     0.00     0.00  dv_construct_vlc_table
  0.00      9.75     0.00        1     0.00     0.00  dv_dct_248_init
  0.00      9.75     0.00        1     0.00     0.00  dv_parse_init
  0.00      9.75     0.00        1     0.00     0.00  dv_place_init
  0.00      9.75     0.00        1     0.00     0.00  dv_ycrcb_init
  0.00      9.75     0.00        1     0.00     0.00  weight_88_inverse_float
  0.00      9.75     0.00        1     0.00     0.00  weight_init

The function dv_mb_to_YUY2 is my dumb C code to convert the blocks to
the YUY2 format supported by Xv.  I could probably speed up the C
version, but MMX is clearly the way to go.  

I've started an MMX version, it's in the patch.  When complete,
I expect the speedup over the C version to be very high.

It may pay off to integrate it directly with the idct code.  My patch
has some code I started noodling with this morning.  I'm not an adept
MMX coder yet...

> I uploaded a patch to sourceforge.
> Happy testing. 

Ok, I'll do some gprof on yours to see more how it compares...

-- Buck

> mfg
> 
>   Stefan Lucke (lu...@be...)

[libdv-dev] XvImage support, YUV value range

[Stefan L. <lu...@be...>]

Hi,

I just did some tests with XvImages and hardware accelerated YUV to RGB
conversion. One problem was the value range used by the dv decoder.
(Y: [-223,+223]; UV: [~-63,~+63]). So adjusting the offset for 'ylut' by
128 is not enough.

Have a look at the following performance table:

                    |           | NTSC              | PAL              
|
MB, CPU, GRA        | dga       | G[t|d]k | XvImage | G[t|d]k | XvImage
|
--------------------+-----------+---------+---------+---------+---------+
Asus P5A, K6-2/400, |  ~26MB/s  | R 24.13 | R 13.83 | R 25.49 | R 14.84
|
MGA-G200            |             U 18.33 | U  8.81 | U 19.22 | U  9.51
|
--------------------+-----------+---------+---------+---------+---------+
DFIK6BV3+, P133,    |  ~56MB/s  | ------- | --------| --------+ -------
|
MGA-G200            |           |         |         |         |        
|
--------------------+-----------+---------+---------+---------+---------+
Asus P5A, K6-2/400, | ~120MB/s  | R 21.05 | R 10.55 | R 22.40 | R 11.61
|
MGA-G400            |           | U 18.28 | U  8.56 | U 19.39 | U  9.63
|

Numbers mesured on Asus motherboard are with kernel V2,4,0.test5 and X11
V4.0.1
DFI motherboard was checked with kernel 2.0.16 and X11 3.3.?

The NTSC sequence is from pond.dv and PAL sequence is from a private
video.
Both are truncated to 6 seconds (180 farmes for NTSC, 150 frames for
PAL).

R/U values are from 'time playdv FILE' (real/user time values).

I uploaded a patch to sourceforge.
Happy testing. 

-- 

mfg

  Stefan Lucke (lu...@be...)

[libdv-dev] Re: some linux-dv related issues

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

Rafa³ Szcze¶niak <rf...@aw...> writes:

> I'm interested in linux DV software. Actually, i'd like to (maybe)
> create a little, quite useful program for grabbing frames and
> operating on them. I hope it wouldn't be completely "out of my
> range".

There are at least a few other people working on similar programs.  I
think we have links to them on our libdv.sourceforge.net page.  But I
don't mean to discourage you from exploring or experimenting with your
own ideas.

> However, i need at last short description of dv encoding method. I
> don't even know what does these dct*, idct*, weight*, vlc*, quant*
> prefixes stand for (well, maybe not all of them ;) ).

(i)DCT == (inverse-)discrete cosine transform
weight == coeifficient weighting
vlc == variable length codes
quant == quantization

> I'm aware that documentation is not free, but i need some BASIC
> information. It seems to me that it wouldn't be breaking the law.

The standards also assume that the reader understands these concepts,
and doesn't do any substantial explaination beyond what you see in the
code.

It sounds to me that you need to learn a little more of the basic
concepts of multimedia compression in general.  There are surely many
websites with such information, but I'd recommend finding a good book
on the subject.  My first suggestion would be "Video Demystified".
They have a web site, www.videodemystified.com.

You should know that many of the major compression standards are very
similar to each other.  For example, DV, MPEG-[124], H.26x, all use
the DCT.  The same is true for the other components of the DV video
codec.  

> I'm asking for all these, because tracing libdv sources is not easy
> and maybe there's some way to save time and spend it on writing
> actual programs.

Well, you should not necessarily need to know much of the libdv
internels to write higher level programs, if we had a proper api and
documentation in place.

Unfortunately, after a good burst of initial activity, Erik and I have
let things slide a lot.  We both took long vacations, and since my
vacation I've been kept busy by other activities.  

Erik is just back from his.  So hopefully we'll get some progress on
cleaning things up.  We do have other obligations so it won't be as
fast paced as when we did the first version.

> regards
> Rafa³

> PS. Sorry for my (not perfect) english, in advance.

Hope this helps.  

-- Buck

[libdv-dev] YUV speed?

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

Last night I finally got our DV decoder to use SDL.  I can play 720x480
video in full-screen in a 2048x1536 modeline rather nicely, albeit
slowly...  ;-) 

My question is: what kind of speed should I be expecting?  My first test
program looked like this:

  for (i=0;i<300;i++) {
    SDL_PumpEvents();
    SDL_LockYUVOverlay(overlay);
    memcpy(overlay->pixels,yuvdata,length);
    SDL_UnlockYUVOverlay(overlay);
    SDL_DisplayYUVOverlay(overlay,&screenrect);
  }

This was taking about 6-7 seconds (real-time would be 10) on my K6-2
running at 360, with a G400 MAX dual-head, runing XFree 4.0 from Rawhide.
This seems awfully high to me, with very little room left over for actual
processing (DV is about as heavy as software MPEG-2 MP@ML, that is to say:
very). Granted, the machine's running the stock RH6.2 kernel, i.e. no AGP
kernel code.  I'm attempting to run it on 2.4.0-test1-ac3, but for some
reason everything is segfaulting under that kernel...

Total bandwidth should be about 20MB/sec at 30 frames/sec, which shouldn't
even make the bus break a sweat.  Am I doing something else wrong?  It's
hard to tell from the smpeg code what the proper sequence is.  smpeg seems
to do a SDL_Flip() in plaympeg.c, but I'm not sure how that works with
overlays.

Sometime early this week I hope to get my hands on some HDTV material,
which I'll be trying to display on this machine (but most definitely not
real-time), so I'll have a killer test-case for the YUV overlays
(1920x1080).  I also just noticed that I have to get the CVS XFree, since
there was a commit two days ago that enables texture-based overlays on
the G400. This is notable since I just ran across a table in CVS that says 
regular overlay is limited to 1024x1024, whereas texture overlays can go
to 2046x2046.

I just spent a few minutes perusing the MGA driver in XFree CVS, it seems
that the X server is doing memcpy's of all the data.  AGP isn't utilized
for the transfer at all.  This is a significant time drain: top(1) shows
almost equal usage of both the test program and X.  I would bet that a
profile of X during that time pots the vast majority of the cyles in
MGACopyData(), which is a simple striding memcpy.  Things get worse if
you're not using YUY2, since YV12 does a significant amount of work in
MGACopyMungedData():

   U32 *dst = (U32 *)dst1;
   for(j = 0; j < h; j++) {
        for(i = 0; i < w; i++) {
            dst[i] = src1[i << 1] | (src1[(i << 1) + 1] << 16) |
                     (src3[i] << 8) | (src2[i] << 24);
        }
        ....
   }

I'll try to decipher what that loop does, and see if it's even necessary
or just an unnecessary format conversion (looks vaguely like a
planar->packed conversion, maybe?).  According to FourCC
(webartz.com/fourcc), the G400 supports YV12 natively in DirectX, so such
a conversion shouldn't be necessary.  Regardless, I've signed up for
Matrox's developer program, in hopes of being able to get some kind of
hardware assisted copy set up from the XShm segment. 

Anyway, you'll probably be hearing more from me in the near future, as I
push as hard as I can on this stuff.

         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] RE: Streaming DV

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

On Wed, 7 Jun 2000, Bernhard Schwall wrote:

> Unfortunately after a (very short I must admit) look into the libdv
> sources it looks to me that there isn't a function returning the
> complete YUV picture and one for converting YUV->RGB. Instead the
> conversion is done block by block so it should be a bit of work to do
> simple operations on the picture before color conversion. 

The reason it's done this way is because it's significantly faster.  If
you do all your operations frame-at-a-time, you're blowing your cache
repeatedly (unless you have more than 2MB of L2).  In its current form, we
are or easily can be within the 16KB L1 data cache of most common CPUs
pretty much all the time.  This is one of the things that makes DV a lot
easier than MPEG, since MPEG (-2 MP@ML) is always referring to a massive
data set (a hair over 2MB) at all times.

As for making libdv easier to work with, I'll very soon be committing some
fairly major changes that will make libdv an actually library ;-)  My most
recent success is a ~150 line program that shows DV data off disk in full
screen scaled to 2048x1536 at about 1/4 realtime using 78& CPU on a
partially crippled K6-2 350.  This is accomplished with XFree 4.0 and SDL
on a G400.  A third of the time is currently spent in brute-force code
that can be reduced to around 1% of total running time once I optimize (C
and MMX), meaning I can go quite a bit faster even on this machine without
much more work.

> Has anyone implemented such a function (returning the complete YUV picture)
> for libdv yet?

The library API I'm building has several layers, the lowest of which I'm
focusing on right now.  The highest layer simply takes a buffer of
sufficient size (120K or 144K) and fills a frame buffer with either raw
YUV or any other format we add converters for, or you supply yourself. The
lowest layer API lets you deal all the way down to video segments, which
is ideal for things like time-warp (you know the cool effect you see when
fast-forwarding on your camera?  that's simply regular strided samples of
video segments off tape, the effect is a fuction of the segment scrambling
built into the format) and other specialized operations.

         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] RE: Streaming DV

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

Mark Knecht wrote:
> 
> James,
>    Would it be possible to share more of the technical details of your
> accomplishments? One of my machines has XFree86 4.0 installed with 2D and 3D
> accelerations for a GeForce card. Unfortunately, when I recompiled the
> kernel for 1394 support, the GeForce driver complained about not being
> installed correctly and RPM didn't want to reinstall. I haven't gotten back
> to trying to fix that one yet.
> 
>    Is the code you did something that is specific to the graphics cards you
> are using, or could it be extended in some way to a general PC graphics
> card? (Assuming some baseline capabilities...
> 
>    My experience here says that showing folks 30FPS live video gets them
> excited about putting resources in to some projects

OK, I just did the initial import of "dviola", which - someday -  will
be a native DV nonlinear editing app.  The part you'll probably want to
see is "dvplay", a simple DV player.

There's a README in the source tree.  libdv is required.  Because dviola
and dvplay only accept input from files, 1394 support is not required.

http://sourceforge.net/project/?group_id=6661

Caveats: Only 16-bit visuals are supported; the window is half size
(320x240); NTSC DV only; 30fps on PII-450 (probably); only tested on
Voodoo3 and Matrox Millenium xservers; no audio.

I'd appreciate any reports of success/failure/performance... thanks...

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

Re: [libdv-dev] RE: Streaming DV

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

Arne Schirmacher wrote:
> 
> Best of breed in the Windows world: The Microsoft DV codec does easily 30 fps
> fullscreen on my AMD 333 MHz with a Matrox Millenium card.
> 
> The trick with most Windows graphics software is that they use the hardware
> features of the graphics card, whereas on Linux it is all done in software. A
> very expensive operation is the YUV to RGB conversion and scaling. Many cards
> can do this in hardware -- write the YUV (or whatever other format) to the
> card's memory, setup source and destination rects in some registers and zap!
> RGB data is just there. I wrote a Quicktime codec for an obscure Macintosh PCI
> graphics card five years ago and using the hardware features I could do 25 fps
> fullscreen PAL videos on a PowerMac 100 MHz (compareable to a 100-150 MHz
> Pentium).
> 
> So to get decent codec performance somebody needs to look into how hardware
> acceleration is done under Linux / XFree86.

I'm running libdv on an Intel PII/300, and have got reasonable
performance (30fps) running with custom backends for placement and
display.  Displaying a 16-bit X visual is pretty painful; the only way I
can get 30fps is by shrinking the image to half-size; 360x240 for NTSC. 
Using fbcon with a 800x600 screen works ok, but I had trouble getting
multimon working with anything except Matrox cards.  What I'm currently
using is a 3dfx Voodoo 1 card - this gets 30fps when displaying
monochrome; I use Glide to download the picture as a series of textures
then draw some big texture-mapped triangles that cover the screen. 
Sounds weird but works ok.

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

[libdv-dev] RE: Streaming DV

[Arne S. <ar...@sc...>]

Best of breed in the Windows world: The Microsoft DV codec does easily 30 fps 
fullscreen on my AMD 333 MHz with a Matrox Millenium card.

The trick with most Windows graphics software is that they use the hardware 
features of the graphics card, whereas on Linux it is all done in software. A 
very expensive operation is the YUV to RGB conversion and scaling. Many cards 
can do this in hardware -- write the YUV (or whatever other format) to the 
card's memory, setup source and destination rects in some registers and zap! 
RGB data is just there. I wrote a Quicktime codec for an obscure Macintosh PCI 
graphics card five years ago and using the hardware features I could do 25 fps 
fullscreen PAL videos on a PowerMac 100 MHz (compareable to a 100-150 MHz 
Pentium).

So to get decent codec performance somebody needs to look into how hardware 
acceleration is done under Linux / XFree86.


Another dvgrab user recommended this to improve harddisk performance:

>> Setting      hdparm -d1   on my drive helped a lot...  I assumed it was set
>> because I configured DMA as default when I built my kernel....
>>
>> Kirk

Arne

-----Original Message-----
From:	Mark W. Knecht [SMTP:mar...@ho...]
Sent:	Sunday, June 04, 2000 5:20 AM
To:	Linux1394-Developers List
Subject:	Streaming DV

I tried Daniel's live video program today and it seemed to work fine. I am
getting about 4.5 to 5 FPS on a 750 Athlon with a GeForce DDR card. I have
no idea how this compares to best of breed in the Windows world. Does anyone
else?

The program seemed quite friendly, which I also attribute to good underlying
driver code. I was able to leave the program running, but pull the camera
plug, or stop and restart the camera, and the video picked up again and
started playing just fine. No core dumps or other problems I could see.

I also recorded some longer clips using dvgrab-0.82 - like 5 minutes - just
to see what happens, and they basically worked fine. DV2 format plays back
at the right speed under NT using QuickTime and under Win98SE using WMP.
Audio was working under 98SE. I didn't have the speakers plugged in at the
time under NT. (Listening to Sting on my Linux box)

The one 'problem' I am dealing with on this system Athlon is that it seems
to drop a huge number of frames in dvgrab. I am quite surprised, as this
machine is far and away the fastest of the 5 machines I'm playing around
with, and it has the fastest hard disk, at least as far as specs go. It is
new though, so I need to figure out if it's really configured correctly.

My 433 Celeron has never dropped a frame, to the best of my knowledge. I
read Arne's README that talked about disk speed, which makes sense, but this
machine is supposed to be a great new chipset and certainly a fast
processor.

What benchmarks can I run to determine whether there is some problem with
the way I've built the kernel or the system itself? Any configuration files
to check?

Anyway, Daniel, cool job. I need to study the code a bit now.

Thanks!

Mark



_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/mailman/listinfo/linux1394-devel

[libdv-dev] Static lib, streaming from IEEE1394 to screen.

[Daniel K. <dan...@st...>]

Hi!

I just uploaded a little patch to the patch manager that does two things:

1. It builds a static libdv and exports simple API for
   decoding-frame-by-frame purposes.
2. Includes stream.c, a little gtk app that demonstrates how to make use
   of the API functions. It captures DV data via IEEE1394 and displays it
   in a window on-screen. As it obviously requires libraw1394 to be
   installed, it isn't build by default, use 'make stream' instead.

So far it works quite well for me. I'm getting ~6 frames per second on a
PIII/450. Quality seems to be okay.

Have fun!

Daniel.

-- 
	GNU/Linux Audio Mechanics - http://www.glame.de
	      GPG Key ID 89BF7E2B - http://www.keyserver.net

[libdv-dev] libdv doesn't do PAL anymore

[Arne S. <ar...@sc...>]

Hi all,

recent versions of playdv won't play PAL data anymore.

Please check out a sample PAL file:

http://www.schirmacher.de/arne/samples/dvgrab/raw.dv

It plays with an old version of playdv, but fails with more recent version

Arne

[libdv-dev] new pages on my website

[Arne S. <ar...@sc...>]

Hi all,

I have set up a new IEEE1394 and Digital Video related link list on 
http://www.schirmacher.de/cgi-bin/dclinks.cgi . Please check it out and add 
your own favorite links to it. Also if your own website is already mentioned 
there, please check the comments for accuracy.

There is also a small discussion board on
http://www.schirmacher.de/cgi-bin/dcboard.cgi which may be of interest too.

According to the logfiles my website draws about 500 - 1000 hits per day with a 
clear increasing tendency. Maybe we can use it to promote the whole ieee1394 
idea, but it is just too time-consuming for me to do it alone (I still have 
some new ideas to code...). Anybody wants to volunteer for things like FAQs, 
application stories, success stories etc.?

Arne

[libdv-dev] Re: [new version of xdvplay]

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

On 20 May 2000, Gord Wait wrote:

> Any chance of making a non MMX version? I'm still on
> a non MMX pentium. I suppose non MMX wouldn't be fast enough
> to run xdvplay?

It's been suggested that libdv be set up with a quality control variable,
which could be tuned all the way down to only decode the DC components (as
demonstrated by someone else's package, the name escapes me at the
moment), which will yield a small thumbnail window (1/8 size both axes),
but can be done on just about any machine capable of actually transfering
25Mbps through it.

Keeping MMX out of the loop will be a function of how the library is
utilized.  I've got a prototype of this library style set up in my
bitstream code (which will be used in libdv RSN), but libdv is
sufficiently different that it'll need a different style (difference:
bitstream code is all inlined, so #ifdefs work, but libdv is all library
code, so function pointers must be used).

Just as a general note, we're aiming right now at a 400MHz PII as our
target for non-accellerated playback (i.e. no XFree 4.0 YUV hardware
overlays), and we may eventually be able to squeeze it into to a 300MHz
box, but don't hold your breath.  It's that hard of a problem.

         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] new version of xdvplay

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

On Sat, 20 May 2000, Arne Schirmacher wrote:

> We should really have libdv in library format, as its name suggests... is 
> anybody listening ?   :-)

Yeah, it's at the very top of my list of things to do.  This last week was
pretty shot while I attended the International Electronic Cinema Festival,
where the focus was mostly HD and not DV, but still very interesting.  Toy
Story 2 projected in pure digital on a large screen, well, it just doesn't
get any better than that.  ;-) 

I'll be starting on making libdv an actual library tomorrow, hopefully
I'll get it done tomorrow 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

[libdv-dev] new version of xdvplay

[Arne S. <ar...@sc...>]

I have made an own home page for the xdvplay program:

http://www.schirmacher.de/arne/xdvplay/index_english.html

There is also a new xdvplay version. It is adapted to the latest version of 
libdv. The tar file now contains a copy of a known working copy of libdv, 
because the libdv changes rapidly and several users could not compile xdvplay.c 
with the latest and greatest libdv version. It has however additional 
instructions where and how to get the very latest version.

http://www.schirmacher.de/arne/xdvplay/xdvplay_latest.tar.gz

We should really have libdv in library format, as its name suggests... is 
anybody listening ?   :-)

I am also working on a patch to the xanim video player program to use the libdv 
code. Stay tuned.


Arne

[libdv-dev] Proposal for quality setting

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

All,

To get real-time performance on slower machines, we could have a global
quality control.  It could be a bitfield, something like:

#define DV_QUALITY_BEST       ~0
#define DV_QUALITY_FASTEST     0     /* Monochrome, DC coeffs only */
#define DV_QUALITY_COLOR       1     /* Clear this bit for go to
monochrome */
#define DV_QUALITY_AC1         2     /* Clear to avoid any AC coeffs  */
#define DV_QUALITY_AC2         4     /* Clear to avoid second phase AC
coeffs */

Curently, only the main decode loop and dv_parse_video_segment() would
need to know about quality.

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

Re: [libdv-dev] please make a library...

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

Yes, sorry for the delay.  We're working on it.  

I was away for some time, and am just now catching up on various
changes people have made/proposed.  (As well as my own work on the 248
DCT for interlaced videos...)

-- Buck

[libdv-dev] please make a library...

[Arne S. <ar...@sc...>]

... because whenever you change something, my xdvplay program won't compile 
anymore.

Right now the Makefile to xdvplay simply links against alot of *.o files in 
libdv, this is of course rather naive...


Arne

[libdv-dev] Looking at 13732

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

All,

I'm planning to work on 13732 - merging weighting/quantization with
IDCT.  Just wanted to make sure that nobody else has an imminent checkin
in this area.  I should be done by the end of today (Wednesday).


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

Re: [libdv-dev] Re: xdvplay 0.2 is available

[Scott F. J. <sc...@fl...>]

Add these two lines to the quicktime/Makefile in quicktime4linux and
it will compile a DSO for shared use amoung these tools. I think this
would be the preferred method to linking libquicktime.a in multiple
places.

libquicktime.so: $(OBJS)
        $(CC) -shared -o $@ $(OBJS) -ljpeg -lpng -lz -lpthread

RE: [libdv-dev] RE: xdvplay 0.2 is available

[Arne S. <ar...@sc...>]

Just try to feed an arbitrary file to playdv to crash it.

You can easily create files with dropped packets if you run dvgrab on an almost 
full or slow disk drive. I did not try playdv (or xdvplay) with such files, I 
was quite happy that it works on good files.

Arne


-----Original Message-----
From:	James Bowman [SMTP:ja...@ex...]
Sent:	Monday, May 01, 2000 4:23 PM
To:	Arne Schirmacher
Cc:	'lib...@li...'
Subject:	Re: [libdv-dev] RE: xdvplay 0.2 is available

Arne Schirmacher wrote:
...
> 4. Stability, Quality. Right now libdv is a bit, er... , sensitive to its 
input
> data. If  it is invalid data it just crashes. The DV data stream from a
> camcorder is not guaranteed to be error-free, packets may be dropped, the
> program should not crash if it is feed with wrong data.

Could we start a collection of data streams with errors?

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

[libdv-dev] Re: xdvplay 0.2 is available

[Brion V. <br...@gi...>]

On Sun, 30 Apr 2000, Arne Schirmacher wrote:

> This is a slightly modified version of the playdv.c program from the libdv 
> project. This version now reads AVI files instead of plain DV data files.

Since I don't have any DV AVI files to play with - the only 1394 card I 
have access to is a Digital Origin card with MotoDV on a friend's Win98
box and it only has Quicktime drivers - I hacked up Arne's hack some more
to read my Quicktime files using Quicktime4Linux. I've been able to
display all my DV .mov's so far except for the ones that Q4L itself
mysteriously hangs on for reasons not yet clear to me.

The Quicktime4linux library is available at http://heroine.linuxave.net/,
it compiles to an .a file and has no automatic install so you may need to
hack makefiles depending on where you put it.

A diff to xdvplay_0.2 is attached... With a teensy bit of work a single
program capable of playing .dv, .avi, and .mov files should be doable, and
once libdv is librarized it should be elementary to add the codec to Q4L.

-- brion vibber (br...@po...)