libdv-dev

[libdv-dev] [Bug #121857] Scalar IDCT does not work

[<no...@so...>]

Bug #121857, was updated on 2000-Nov-06 20:51
Here is a current snapshot of the bug.

Project: Quasar DV Codec
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Summary: Scalar IDCT does not work

Details: There seems to be a problem with the coefficient weighting in the scalar IDCT code.  It's very important to offer a scalar IDCT method since Intel's MMX IDCT routine is destructive.  The DV decoder is usually the import stage in a video production pipeline and as a result, it's speed is virtually irrelevant while its quality must be the best possible.  All the intermediates are uncompressed YUV.

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=121857&group_id=4393

Re: [libdv-dev] bugreport #110554

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

Hah!  Way to go.  That fixes one nasty bug that's been around for
ages.  I guess the real credit is due to the author of the anonymous
bug submission... cheers to whoever they are!

-- Buck

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

> Hi,
> 
> according to this bug report I changed parse.c by:
> --- cut ---
 ...
> --- cut ---
> 
> The resulting pictures have much less artefacts and look better.
> Decoding time slows down by 15%.
> Can anyone check this ?
> 
> -- 

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

[libdv-dev] 16:9 / wide screen indicator

[<lu...@sn...>]

Hi,

does anyone know if there is a flag in the VAUX section (or somewhere else)
which indicates that current video data is in wide screen (16:9) format
and/or anamorphic encoded ?

Thanks in advance

Stefan
Lucke

[libdv-dev] Kino 0.1 is available

[arne <ar...@sc...>]

Hi all,

this version of Kino is much more polished and it is actually useable....

See the announcement on the dvgrab website (no time to make another one for 
Kino yet) http://www.schirmacher.de/arne/dvgrab/index_e.html or download it 
directly from http://www.schirmacher.de/arne/kino/kino_0.1.tar.gz .

Arne

[libdv-dev] bugreport #110554

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

Hi,

according to this bug report I changed parse.c by:
--- cut ---
--- ../libdv-0.1.5c/parse.c     Wed Oct 18 23:19:47 2000
+++ parse.c     Wed Oct 18 23:18:45 2000
@@ -176,4 +176,8 @@
   found_vlc = FALSE;
   found_bits = dv_find_mb_unused_bits(mb,&bl_new_lender);
+
+  if (!found_bits && pass != 1)
+    found_bits = dv_find_vs_unused_bits(seg,&bl_new_lender);
+
   while(found_bits && (!found_vlc)) {
     bitstream_seek_set(bs, bl_new_lender->offset);         
--- cut ---

The resulting pictures have much less artefacts and look better.
Decoding time slows down by 15%.
Can anyone check this ?

-- 

mfg

  Stefan Lucke (lu...@sn...)

[libdv-dev] Announce: Kino

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

Hi all,

I have written a Digital Video Editor program yesterday morning (well, 
something that might finally evolve in such a program.....)

It wasn't that hard using glade, libdv and the AVI classes from the dvgrab 
program.

Check it out: http://www.schirmacher.de/arne/kino/kino_0.01.tar.gz .

Arne

Re: [libdv-dev] DV decoding performance

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

The profiler is gprof.  The documentation for it is pretty good.  

At the Intel Developer Forum, I saw a demo of real-time transcode from
DV to MPEG-2.  The vendor was Ligos (www.ligos.com), and of course, it was
Windows based.  Their product was pushing hard on a P4.

It will take a lot of engineering to to do the same with libdv and a
Linux mpeg encoder (mp1e?).  You would need to spend a great deal of
time optimizing code, as in you need to become a world-class expert at
MMX and codec optimization ;-)

(I'm only half joking).

Alternatively, you probably could do it easily enough on a multi-processor, 
where one CPU does capture and DV decode, and the other does MPEG encode.

-- Buck


Rodney Schneider <ro...@bi...> writes:

> Hello again!
 
> Thanks for the info.  The front-end/display performance is not that
> important to me.  I want to write some software that will allow me
> to use my DV camera to create live webcasts (similar to cheaper web
> cams, but with better quality video) so that when I put on partys,
> friends who are in other countries can watch what is happening from
> home.

> To do this, I suppose I would need to decode a DV stream into YUV
> raw video and PCM raw audio and simultaneously encode the data into
> MPEG or another suitably compressed format for transmission.

> I am wondering how close to real time the actual decoding of DV is,
> without displaying it.  What profiler do you recommend for me to
> use, and could you give me any useful tips on what to look for?  I
> am an experienced Java programmer, but my C skills are a little
> rusty.

> Thanks again,
> 
> -- Rodney

Re: [libdv-dev] DV decoding performance

[Vladimir V. <vla...@In...>]

On Tue, 26 Sep 2000, Rodney Schneider wrote:

> Hi!
> 
> I was wondering if anyone had any performance statistics for libdv?  On
> the main page at SourceForge it says:
> 
> "Performance is still in need of major improvement: we are currently
>  several times slower than real-time on typical hardware."
> 
> I had a look at the basic task list, which shows that there are quite a
> few performance enhancements being worked on.  How close to real-time is
> the decoding now, and can anyone give me a basic idea of where the main
> performance bottlenecks are?  On a powerful machine, is currently possible
> to get real time performance?

Hi Rodney,

In my experience with an Athlon 750 and 512MB of ram, it is not possible
to get real-time performance with software only. I can only get between
15-20 fps (and that's the upper limit). However, if the XVideo extension
is used for display (where the YUV->RGB happens on the video card), I can
easily get 35+ fps. Unfortunately, the Xv extension is only available in
XF4, and only on a few cards so far.

	- Vlad

[libdv-dev] DV decoding performance

[Rodney S. <ro...@bi...>]

Hi!

I was wondering if anyone had any performance statistics for libdv?  On
the main page at SourceForge it says:

"Performance is still in need of major improvement: we are currently
 several times slower than real-time on typical hardware."

I had a look at the basic task list, which shows that there are quite a
few performance enhancements being worked on.  How close to real-time is
the decoding now, and can anyone give me a basic idea of where the main
performance bottlenecks are?  On a powerful machine, is currently possible
to get real time performance?

I have ordered a copy of the standard from SMPTE and hope to help your
development in any way that I can.  Any information would be greatly
appreciated.

Thanks in advance,

-- Rodney

[libdv-dev] new xdvplay version

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

This version will display both Type-1 and Type-2 AVI files.
It is not more than my AVI code merged to the playdv program from the libdv 
project, but, hey, I like it.

Download from here: http://www.schirmacher.de/arne/xdvplay/index_english.html

I noticed that the libdv code now has a quality parameter, but the difference 
between best and fastest was less than 30% on my system (an AMD 333). So I 
thought about making that a command line parameter but it is probably not worth 
the effort.

Arne

[libdv-dev] Re: libdv and the open source DV CODEC.

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

David A Newman <da...@ap...> writes:

> Hello,

> I was researching the availablity of software  DV CODECs when I came
> across   the  Quasar DV  CODEC  on  sourceforge.net   (your email is
> connected  with this project).  Is this  still an active project and
> are  you still involved?   I hope so,  but if  not  I would still be
> interested   in discussing what  you   found  when undertaking  this
> project.

The project is still active, although the majority of effort happened
in the April to June period.  Since then most of the work has come
from a few outside contributors.  (Yay!)  Part of the reason I have
had less time to contribute is that I've gone through a major career
change.  I've recently left OGI (and suspended my Phd) to join a
startup.  We're called Digital Mercury.

> A little background.  I work with Applied Magic
> (www.applied-magic.com) and we make stand-alone real-time video
> editing applicances.  It is a fun business involving a lot of custom
> software and hardware.  We currently uses a hardware DV CODEC, which
> is the one costly part of the system that we have little control
> over (everything else was developed at Applied Magic, OS and
> graphics processors included).  We are currently researching a
> software approach to DV, to find out how much CPU performance is
> required to do real-time DV (and hopefully reduce cost).  I am
> interest for any input you might have, or if you can direct me to
> someone who worked in these areas.

> Thank you.   

> David A Newman
> Chief Technology Officer
> Applied Magic Inc
> (760)931-6417 x358
> da...@ap...
> www.appled-magic.com

That's reasonably easy to answer.  The Canopus software codec was, and
still is my benchmark for what can be done in software.  They can do
real time decode on a 300MHz range PII.  (www.canopuscorp.com)

I think with time, libdv could reach that goal.  But I have a lot of
respect for their level of performance.  I think right now libdv is
around a factor of 2 slower than the Canopus decoder.  Libdv already
includes some use of MMX, some critical sections hand converted to
scalar assembly, and use of graphics card overlay for YUV color
conversion.  Given that, I seriously doubt if you could do much better
than the Canopus people have done on IA32 processors.  

Hope this helps.

-- Buck

[libdv-dev] Broadcast2000 now supports DV

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

Hi all,

the well-known Video Editing software now supports DV format and ieee1394 
cards. The developer(s) included the libdv and some code from dvgrab in their 
application.

This is great. Although the binary distribution did not run on my system for a 
reason, I got the source code and I'll give it several more tries.

Here's the link: 
http://www.schirmacher.de/cgi-bin/dclinks.cgi?action=redirect&id=32&URL=http  
://heroine.linuxave.net/bcast2000.html

(This is of course a shameless plug to increase my link list counter.... 
However check out the new link list area, it is now much better integrated into 
the rest of the website: http://www.schirmacher.de/cgi-bin/dclinks.cgi )

Arne

[libdv-dev] Re: simpledv interface to libdv

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

Vladimir Vukicevic <vla...@In...> writes:

> Ah, beautiful.. I never noticed those before. I'll use the non-SDL
> patches. Is there anything else you'd like to see in the simpledv
> interface? 

Probably, but I don't have specifics at the moment.

So the best way, as you are doing, is to start simple and proceed from
there.

> I'm still going to maintain getting a RGB frame out, but
> YUV will be an option dvf_open. Note that I plan to keep using
> GdkPixbuf because then the interface can be transparent whether it's
> YUV or RGB, if gdk_pixbuf_render is used to draw. The only concern I
> have is if someone wants to use simpledv without Gtk/GdkPixbuf --
> I'll probably make this a compiletime #define at least.

Sounds good.  

> Also, I thought that the native NTSC DV format was 4:1:1, but there seems
> to be cases where it's 4:2:0? I don't have the spec so I can't check...

> 	- Vlad

You should get the spec from smpte.  It is only $34 USD.  There's a pointer
on libdv.sourceforget.net.

For NTSC, DV uses 4:2:0 for the rightmost two columns of macroblocks
in each frame.  This is because 720 is not a exact multiple of 32
(each 4:1:1 macroblock is 4 blocks wide).  Plus "superblocks" which
are groups of macroblocks are not square.  What a hack, eh?

PAL DV is different.  The original PAL DV, as defined by the IEC
61834, uses 4:2:0 throughout the entire frame.  The newer version
defined by smpte 314M uses 4:1:1 throughout.  I'm not sure why they
switched, but I think it has to do with interoperability with newer
high bitrate modes.  50Mbit DV looks a great deal like 25, except it
uses 4:2:2.  

There are a newer family of IEC specs for DV, number 61883?, that I
have not seen yet.  I don't know if they match smpte version of PAL
yet.

So far, I think we've only tested IEC style PAL bitstreams.

-- Buck

[libdv-dev] Re: simpledv interface to libdv

[Vladimir V. <vla...@In...>]

On 7 Aug 2000, Charles 'Buck' Krasic wrote:

> 
> Hi there.  I have one comment so far on your simpledv api.  
> 
> You may want to reconsider the direct use of GdkPixmaps in DVFile.  I
> think that the natural output format of the decoder should be YUV, not
> an RGB format like the GdkPixmap.  When HW assist for YUV color
> conversion and scaling are available, they make a massive difference
> in performance.
> 
> There are currently two patches in the libdv project page on
> sourceforge.net which implement YUV rendering.  One uses the Xv
> extension directly, while the other uses the SDL library as a shim
> over Xv (when it is present).  Another as yet unimplemented approach
> is to use OpenGL textures.
> 

I'm currently extending GdkPixbuf to handle YUV Pixbufs, using the Xv
extension (if available) to render to screen, otherwise do YUV->RGB
conversion. However, I'm having trouble figuring out how to get the libdv
code to spit out a YUV frame (hopefully encoded in IYU1 format, i.e.
UYYVYY, in the NTSC 4:1:1 case -- what does the encoding look like in the
PAL 4:2:0 case? The only FOURCC standard that I'm aware of for 4:2:0 is a
planar not packed standard...)

What I've done is just not do the ycrcb calls, and I wrote up two
functions that place the 411 and 420 data straight into the buffer; but
I'm getting garbled data. Note that I'm not sure if it's the data from
there that's garbled, or if it's just being written to screen
incorrectly.. still working on that.

If you have any pointers, I'd appreciate any :-)

	- Vlad

[libdv-dev] XvImages are now scaleable

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

Hi,

I uploaded an extension to XvImage patch with the following change:
        support to rescale to an arbitrary size or aspect.

Further improvements could be:
    keep aspect ratio constant
    rescale to 16:9 aspect ratio

Is wide screen (16:9 PAL or 16:10 NTSC?) tagged in dv datastream ?

-- 

mfg

  Stefan Lucke (lu...@sn...)

[libdv-dev] [Patch #101136] XvImage HW scaleing

[<no...@so...>]

Patch #101136 has been updated. 

Project: 
Category: None
Status: Open
Summary: XvImage HW scaleing

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=101136&group_id=4393

[libdv-dev] Re: simpledv interface to libdv

[Vladimir V. <vla...@In...>]

Yeah, I had considered YUV output and will probably implement it soon..
when I first wrote this up, I just needed a quick-and-dirty way to access
a DV file. I need to read up on the Xv extension some more..

	- Vlad


On 7 Aug 2000, Charles 'Buck' Krasic wrote:

> 
> Hi there.  I have one comment so far on your simpledv api.  
> 
> You may want to reconsider the direct use of GdkPixmaps in DVFile.  I
> think that the natural output format of the decoder should be YUV, not
> an RGB format like the GdkPixmap.  When HW assist for YUV color
> conversion and scaling are available, they make a massive difference
> in performance.
> 
> There are currently two patches in the libdv project page on
> sourceforge.net which implement YUV rendering.  One uses the Xv
> extension directly, while the other uses the SDL library as a shim
> over Xv (when it is present).  Another as yet unimplemented approach
> is to use OpenGL textures.
> 
> -- Buck
> 
> 
> Vladimir Vukicevic <vla...@In...> writes:
> 
> > Howdy.. I wrote up a simple API for using libdv from external apps;
> > it gets the job done, for the most part. I'm currently beginning a
> > gnome DV editing software project; it will be available as gnome cvs
> > module 'gnomotion' sometime in the near future, and I've been using
> > this API (and your library) extensively without any problems.
> 
> > I've attached the tar.gz; please email me any questions/etc., I'm
> > out of the country until next weekend so my email access will be
> > sporadic until then.
> 
> >       - Vladimir
> >       - vla...@he...
> 

[libdv-dev] new dvgrab version

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

Hi all,

a new dvgrab version is available. Download it from: 
http://www.schirmacher.de/arne/dvgrab/index_e.html .

This version contains a few bug fixes in the audio section for the Type-2 AVI 
file format. I believe that the clicks and dropouts of the earlier version are 
now fixed and that 16 bit audio data now works good with both PAL and NTSC 
formats. Please send me a note otherwise.

My SMTP 314M specification does not contain all values for the "number of audio 
samples per frame" field in the AAUX source pack. It has only the values 20, 22 
and 24 for 1600, 1602 and 1920 samples. My camcorder sends also a value 25 on 
occasion, other users have send me samples that contain the value 21.

If I switch my camcorder to 12 bit audio, it will send the value 16 (which 
corresponds to 32 kHz instead of 48 kHz). Since dvgrab can't deal with 12 bit 
audio yet, it will send lots of error messages when you are using 12 bit audio 
mode. So please use 16 bit for now. If you have audio error messages while 
using 16 bit audio and --format dv2, please send me an email.

If you have DV specifications other than the 314M document or if you have other 
information on these new types of AAUX packs (12 bit audio and what else might 
be available), I would appreciate it if you can send me these documents (or the 
relevant excerpts). The shuffle algorithm for 12 bit audio seems to be 
different too, the existing algorithm did not work when applied to 12 bit audio 
data.

Thanks, Arne

 

[libdv-dev] Re: simpledv interface to libdv

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

Hi there.  I have one comment so far on your simpledv api.  

You may want to reconsider the direct use of GdkPixmaps in DVFile.  I
think that the natural output format of the decoder should be YUV, not
an RGB format like the GdkPixmap.  When HW assist for YUV color
conversion and scaling are available, they make a massive difference
in performance.

There are currently two patches in the libdv project page on
sourceforge.net which implement YUV rendering.  One uses the Xv
extension directly, while the other uses the SDL library as a shim
over Xv (when it is present).  Another as yet unimplemented approach
is to use OpenGL textures.

-- Buck


Vladimir Vukicevic <vla...@In...> writes:

> Howdy.. I wrote up a simple API for using libdv from external apps;
> it gets the job done, for the most part. I'm currently beginning a
> gnome DV editing software project; it will be available as gnome cvs
> module 'gnomotion' sometime in the near future, and I've been using
> this API (and your library) extensively without any problems.

> I've attached the tar.gz; please email me any questions/etc., I'm
> out of the country until next weekend so my email access will be
> sporadic until then.

>       - Vladimir
>       - vla...@he...

RE: [libdv-dev] Re: decoding pal dv

[<Mat...@no...>]

> From: EXT Charles 'Buck' Krasic 
>
> What I really need now is a way to get some test input and the YUV out
> of a known "good" decoder.

Take a dv stream and play it in the quicktime player (the one that comes
with NT4 is good). Choose the frame you want to check and press ctrl-v and
then paste it in a paint program. This is a known good decoder.

/Mattias

Re: [libdv-dev] Re: decoding pal dv

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

Today I did some fairly extensive testing of the idct code in libdv.
Before this, I thought the 248 idct was the source of the noisy blocks
people were noticing.  I now conclude it has to be something else.

My test harness consists of two main pieces.  

The first is a modified playdv that reads a dv movie and dumps the
coefficients of every DCT block to a text file.  Each block in the
file is also identified as either 88 or 248.

The second part is a program which reads the coefficient file and
feeds each block to two versions of the idct routine.  One is the
integer idct used in libdv, the other is a brute force floating point
based directly on the standard iDCT equations.  The program dumps the
difference between the two results for each block.  The integer 248
routine is extremely accurate, with only occasional pixel values off
by 1.  The integer 88 is less accurate, with values often off by one,
and sometimes off by at most as 3.  This is not suprising, since the
88 routine is mmx and uses 16 bit math.

While debugging, I also checked many blocks by hand via matlab.

After all that, looking real close at the video with 248 blocks
identified (hard coded to display white) shows that bad messed up
blocks are highly correlated with the 248s, but there are enough 88s
messed up too.

So the problem has to lie somewhere else: parse, quantize or weight.
I'm pretty confident in the parser, as it has fairly extensive
scaffolding, which should reveal errors quickly (if parsing
when wrong, vlc errors should be obvious).  But, I will recheck
anyway.

Another clue.  Turning off the various hand coded assembler routines
doesn't seem to make a difference.

What I really need now is a way to get some test input and the YUV out
of a known "good" decoder.

-- Buck

Re: [libdv-dev] Re: decoding pal dv

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

Yes, libdv does all three passes.  

-- Buck

Mat...@no... writes:

> Does libdv do all three passes on a 8x8 block? If not this is quite
> probably the result of only doing pass1. With three passes I refer
> to the gathering of the bits for a 8x8 block that is scattered in
> other parts of the macroblock (pass2) and video segment (pass3).

> /Mattias

RE: [libdv-dev] Re: decoding pal dv

[<Mat...@no...>]

Does libdv do all three passes on a 8x8 block? If not this is quite probably
the result of only doing pass1. With three passes I refer to the gathering
of the bits for a 8x8 block that is scattered in other parts of the
macroblock (pass2) and video segment (pass3).

/Mattias

> From: EXT Charles 'Buck' Krasic
>
> I'm fairly certain that the problem you are seeing is a bug in the
> 2-4-8 idct code.  If so, a fix is not yet available.
> 
> I'm going to investigate some tomorrow.  This has been a nagging
> problem for several months that I have not been able to attend to.
> 
> So the short answer is that no fix is currently available.
> 
> One partial workaround: if your camera has a progressive scan mode,
> you should use it.   There should be far fewer 2-4-8 blocks in the
> video.  The 2-4-8 DCT is mainly to deal with motion between fields
> of an interlaced frame.  
> 
> -- Buck
> 
> "Jan M. Hemmi" <jh...@ca...> writes:
> 
> > Dear Charles
> > 
> > I have been using your libdv for decoding dv from a Sony 
> Pal camcorder.
> > While it works generally ok, there are some obvious faults 
> in the image.
> > If one looks closely, the image seems to consist of blocks, 
> that almost,
> > but don't quite match up on the borders. In addition, especially in
> > moving targets, there are often blocks that are very badly 
> out. I tried
> > to look through sourceforge, but could not find any hint, 
> that this was
> > a known problem and has been fixed. 
> > the next lines are the top entry of the change-log file 
> from the version
> > I use, to give you an Idea of the version I use
> > 
> > 2000-04-20  Charles 'Buck' Krasic  <kr...@ac...>
> > * place.c: Fixes to 4:2:0 placement.  Color resembles something
> > like correct now. :}
> > * Add initial macroblock placement for 4:2:0 (IEC61834).  Initial
> > test shows luma is OK, but color isn't working correctly.
> >  
> > I am using libdv though Arne's dvplay.c, after grabbing the 
> images with
> > dvgrab. (without error messages (X)). I normaly only grab every 6th
> > frame, but that does not seem to be responsible for the problem. 
> > Could you tell me of wheter there are any upgrades that 
> might help? I
> > have invested some time in makeing changes both dvplay.c and libdv
> > (minor stuff, such as the order of bytes in the 
> ycrcb_to_rgb24.c ...),
> > to make them better suited to my application (tracking and 
> digitasing of
> > fiddler crab positions), so it would take me quite some 
> time to move to
> > a newer version. However, I would certainly do that if I 
> new it improved
> > the image. The squares do a times pose a problem with my automated
> > tracking. (I know I should have made my changes in a more 
> upgradeable
> > way, but I am a biologist, lacking both skill and time.....
> > 
> > I would greatly appreciate any information.
> > 
> > 
> > thank you
> > 
> > Jan 
> > 
> > 
> > _______________________________________________________
> > 
> > Jan M. Hemmi
> > Visual Sciences
> > Research School of Biological Sciences
> > Australian National University
> > P.O. Box 475
> > Canberra, ACT, 2601
> > 
> > Australia
> > 
> > email: jan...@an...
> > tel  : ++61 (02) 6279 85 61
> > fax  : ++61 (02) 6249 38 08
> > 
> > _______________________________________________________
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/mailman/listinfo/libdv-dev
> 

[libdv-dev] Re: decoding pal dv

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

Jan,

I'm fairly certain that the problem you are seeing is a bug in the
2-4-8 idct code.  If so, a fix is not yet available.

I'm going to investigate some tomorrow.  This has been a nagging
problem for several months that I have not been able to attend to.

So the short answer is that no fix is currently available.

One partial workaround: if your camera has a progressive scan mode,
you should use it.   There should be far fewer 2-4-8 blocks in the
video.  The 2-4-8 DCT is mainly to deal with motion between fields
of an interlaced frame.  

-- Buck

"Jan M. Hemmi" <jh...@ca...> writes:

> Dear Charles
> 
> I have been using your libdv for decoding dv from a Sony Pal camcorder.
> While it works generally ok, there are some obvious faults in the image.
> If one looks closely, the image seems to consist of blocks, that almost,
> but don't quite match up on the borders. In addition, especially in
> moving targets, there are often blocks that are very badly out. I tried
> to look through sourceforge, but could not find any hint, that this was
> a known problem and has been fixed. 
> the next lines are the top entry of the change-log file from the version
> I use, to give you an Idea of the version I use
> 
> 2000-04-20  Charles 'Buck' Krasic  <kr...@ac...>
> * place.c: Fixes to 4:2:0 placement.  Color resembles something
> like correct now. :}
> * Add initial macroblock placement for 4:2:0 (IEC61834).  Initial
> test shows luma is OK, but color isn't working correctly.
>  
> I am using libdv though Arne's dvplay.c, after grabbing the images with
> dvgrab. (without error messages (X)). I normaly only grab every 6th
> frame, but that does not seem to be responsible for the problem. 
> Could you tell me of wheter there are any upgrades that might help? I
> have invested some time in makeing changes both dvplay.c and libdv
> (minor stuff, such as the order of bytes in the ycrcb_to_rgb24.c ...),
> to make them better suited to my application (tracking and digitasing of
> fiddler crab positions), so it would take me quite some time to move to
> a newer version. However, I would certainly do that if I new it improved
> the image. The squares do a times pose a problem with my automated
> tracking. (I know I should have made my changes in a more upgradeable
> way, but I am a biologist, lacking both skill and time.....
> 
> I would greatly appreciate any information.
> 
> 
> thank you
> 
> Jan 
> 
> 
> _______________________________________________________
> 
> Jan M. Hemmi
> Visual Sciences
> Research School of Biological Sciences
> Australian National University
> P.O. Box 475
> Canberra, ACT, 2601
> 
> Australia
> 
> email: jan...@an...
> tel  : ++61 (02) 6279 85 61
> fax  : ++61 (02) 6249 38 08
> 
> _______________________________________________________

[libdv-dev] Re: Camcorder recommendation (FAQ?)

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

Mads Bondo Dydensborg <ma...@ch...> writes:

> OK - that is nice. I forgot to mention that I live in a country
> where we use PAL. Is that a "problem" with the DV format? (Sorry if
> I appear clueless - it was easy to find information about IEEE 1394,
> but I have yet to find anything usefull about the DV format).

You will get a PAL DV camera if you buy it in Europe.  

The DV format defines separate PAL and NTSC modes.  The DV format is
different for each, which is good.  It does not attempt to find
"common denominator" that would necessisarily be sub-optimal for one
or both.  Lucky for you, PAL is better. ;-)  PAL DV is 720x576, where
NTSC is 720x480.

Actually, there are two PAL DV formats.  The original IEC standard,
and the newer smpte one.  The difference is in how color sampling is
done.  IEC DV does 4:2:0 for PAL.  SMPTE does 4:1:1 for PAL.  

From the software perspective, 4:2:0 is the best.  Only because it is
slightly easier to display on a computer.  The reason is that most
graphics cards support YUV overlays for 4:2:0 video (it's the same
that MPEG uses), and under Linux it is possible to take advantage of
that with the new Xv extension present in XFree86 4.0.x.

This makes a huge reduction in CPU requirements for software decoder.

Almost no video cards support YUV 4:1:1, and Xv doesn't support it at
all.  But YUV 4:2:2 is about as commonly supported as 4:2:0.  So we
can still take advantage of YUV but, we have to upsample from 4:1:1 to
4:2:2.

I am one of the authors of libdv, http://libdv.sourceforge.net, a
software DV decoder for Linux.  Libdv supports PAL (both kinds) and
NTSC.  

There are lots of sites with good information.  For Linux stuff 
check out Arne's:

  http://www.schirmacher.de/arne/dvgrab/index_e.html

-- Buck

> Thanks for all the information. I had not thought about the progressive
> scan thing at all. That is nice to know.

> The Sony models seems to be very nice, although a bit higher priced then
> jvc and panasonic, though.

> Mads