libdv-dev

[libdv-dev] Please look at this libdv patch

[Dan D. <da...@de...>]

Hi Peter,
I attached a patch against the current libdv CVS.
It includes your (Peter Schlaile's) recent patch as well as my work to
create a buffer-oriented public encoder interface that is consistent
with the decoder interface. As such, it accepts RGB and YUY2 (YUV 4:2:2)
video and 16-bit, 2-channel PCM audio. I tried to re-use as much as code
as possible. All video is converted to planar YUV 4:2:2 (libdv's ycb),
and I reuse the ppm macroblock fill routines.

The Problem... audio is working fine for me, but the video output is
noisy. I included my recode.c program I have been using for testing.
You'll have to adapt for PAL. It takes a raw dv file on input, decodes,
and then re-encodes dv and audio to stdout. You can toggle the defines
to make it generate ppms or read ppms. This helps verify the decoder is
working okay, and provides a test mode that isolates the encoder from
the decoder. In pure recode operation, the decoder interfers with the
encoder. dv_parse_header() on each frame before decoding affects the
output. Throwing a dv_init() between the decode and encode operations
affects it too. I am currently at a loss.

If you redirect the output of recode to a new dv file, then it is not
playable by playdv. I use dv1394 for viewing the output, but you might
be able to use dvconnect too.

Any assistance is appreciated.

[libdv-dev] Panasonic Intros 24P Mini-DV Camcorder

[Dan D. <da...@de...>]

Panasonic Intros 24P Mini-DV Camcorder
Camera designed to integrate with FireWire-based NLE systems
by David Nagel

Here's something new. Panasonic says it will ship the first mini-DV
camcorder capable of capture 24 FPS progressive-scan video. There aren't
very many details available right now, but the palm-sized AG-DVX100 will
be equipped with three 1/3-inch progressive scan CCDs that allow the
camcorder to capture images in both standard 60 field per second NTSC
and 24P.

"With its 24-frame capture capabilities, the AG-DVX100 democratizes
visual storytelling by substantially reducing the cost of entry for
digital filmmakers," said Stuart English, vice president of marketing
for Panasonic Broadcast in a prepared statement. "The AG-DVX100 is a
forward-looking tool that integrates with existing IEEE-1394 based
non-linear editing platforms and will allow the creative community,
whether video journalists, digital cinematographers or event
videographers, to express their visions at the highest creative level."

The AG-DVX100 will offer a sensitivity of f11 at 2000 lux. It will be
equipped with a new zoom lens with manual and auto focus. And it will
have two built-in XLR inputs and a phantom power supply (48V). It will
have an electronic viewfinder and a flip-out 3.5-inch LCD panel.

Panasonic will announce pricing and availability at the NAB convention
in April. For more information, visit http://www.panasonic.com. 

[libdv-dev] Re: DV codec: quality problem

[Ardi <ago...@wa...>]

Thank you for your answer. Also to Dan Dennedy for interesting links that he
sends to me.
I've made some complemantary tests that confirm my first analyse and also
shows that hardware decompressors works better, for this issue, than
existing software ones. I've updated my web page in this way.

I will be very interested by your results if ever you run my test with your
software, and try to understand the origin of the trouble.

Is it possible to find somwhere (preferably on the web) the process of DV
compression? (in theoritical point of view).

Best regards
Ardi

----- Original Message -----
From: "Charles 'Buck' Krasic" <kr...@ac...>
To: "Ardi" <ago...@wa...>
Cc: <kr...@ac...>; <lib...@li...>
Sent: Thursday, January 31, 2002 10:40 PM
Subject: Re: DV codec: quality problem


>
> Hi.
>
> In my experience writing libdv, it was very easy to have bugs which
> lead to artifacts such as you describe, and very difficult to track
> them down.  I could hazard a guess at the source of the artifacts you
> see: either they are not handling 2-4-8 dct blocks correctly, or they
> are not handling class 3 quantization correctly.  But that is only a
> guess.  Tracking these kinds of bugs down is very tricky.
>
> If I had time, it would be interesting to port libdv to be a Premiere
> plugin and compare the results.  I am confident that our quality is
> very good.  Of course, I am also afraid that our speed is worse than
> the commercial codecs.
>
> Cheers,
>
> -- Buck
>
> ps You have gone to a lot of trouble to clearly identify the problem.
>    A nice thing about open source is that someone with enough
>    motivation and skill can go all the way to try and fix the bug.
>    Not an option with Pinnacle et al.  :-|
>
> "Ardi" <ago...@wa...> writes:
>
> > Hi,
> >
> > We have here an amazing problem with DV codec.
> >
> > Until now, all Pinncale, Microsoft, Main Concept and Panasonic codec we
have tested produce very poor results.
> >
> > I explain this in the following page:
> >
> > [[http://golgolabprod.multimania.com/CODEC-problem.html]]
> >
> >
> >
> > Do agree my analyse or have an idea about this problem?
> >
> >
> >
> > Bye
> >
> > Ardi

[libdv-dev] dv1394 updates

[Dan D. <da...@de...>]

I just updated dv1394 in the linux1394 CVS to bring it functionally
complete for release. This just expands the devfs and procfs entries to
make it easier for users and apps.

The new devfs name structure is:
/dev/ieee1394/dv/host0/NTSC/in (minor 32)
/dev/ieee1394/dv/host0/NTSC/out (minor 33)
/dev/ieee1394/dv/host0/PAL/in (minor 34)
/dev/ieee1394/dv/host0/PAL/out (minor 35)
...
/dev/ieee1394/dv/host3/PAL/out (minor 47)

The new procfs name structure is:
/proc/bus/ieee1394/dv/host0/NTSC/in
/proc/bus/ieee1394/dv/host0/NTSC/out
/proc/bus/ieee1394/dv/host0/PAL/in
/proc/bus/ieee1394/dv/host0/PAL/out
...

PAL users do not have to set their video format beforehand if using the
proper device!

Nothing is strictly enforced about the use of in vs. out. This just
basically provides 2 "plugs" per host and video signal type.
Video signal format can still be configured using procfs or IOCTL, so
there is actually 4 "plugs" per host if you get fancy.
Isochronous channel read/write is now available through procs.

dv1394.h will be officially distributed with a future libdv release so
apps will be able to reliably #include <libdv/dv1394.h> instead of
distributing their own or embedding into their own code.

It is possible using IOCTL and mmap to make a capture application that
automatically detects and properly handles video signal format
regardless of device file used.

You can use libdv's playdv to preview:
% playdv --no-mmap /dev/ieee1394/dv/host0/NTSC/in

Capture and export DV using file redirection:
% cat /dev/ieee1394/dv/host0/NTSC/in >my.dv
% cat my.dv >/dev/ieee1394/dv/host0/NTSC/out

A new module/package called dv_utils is forthcoming from the libdv
project to provide all sorts of utilites to work with and between AVI,
Quicktime, and raw file formats.

p.s. Thanks, BenC, for adding the proper #ifdef CONFIG_PROC_FS to my
code!

[libdv-dev] [ libdv-Patches-514407 ] new encoder features and bugfixes

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

Patches item #514407, was opened at 2002-02-07 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=514407&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Schlaile (schlaile)
Assigned to: Nobody/Anonymous (nobody)
Summary: new encoder features and bugfixes

Initial Comment:
2002-07-02  Peter Schlaile <ud...@rz...-karlsruhe.
       * New dvconnect version featuring 
         - multi-threading and buffer control
         - new video1394 interface support
         - underrun picture support
       
       * Updated insert_audio to plugin interface
       
       * Added dvavi, a small utility to convert
DV-AVIs to RAW-DV
       
       * Added wide-screen option to encoder
       
       * Made the encoder detect PAL/NTSC on /dev/video
input
       
       * Various bugfixes



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=514407&group_id=4393

Re: [libdv-dev] Re: DV codec: quality problem

[Dan D. <da...@de...>]

Here is an interesting article about a utility and image processing
techniques to reduce the artifacting:
http://www.dvformat.com/2001/11_nov/features/dfilmmakingpt1.htm

Also, I recently built a new Windows2000 DV/DVD post-production
workstation and decided to go with VegasVideo 3.0 after reading this
review. Note the comments regarding the SonicFoundry DV codec; it has a
nice tiled image comparing SonicFoundry against the MS codec!

http://www.dvformat.com/2001/12_dec/reviews/cw_vegasvid3.htm

Now, this new workstation is a dual Athlon 1600XP with 1GB RAM. I was
expecting good performance. However, previewing DV AVIs in either
VegasVideo or WindowsMediaPlayer is not as smooth as Kino or XMovie DV
Quicktimes--both using libdv--on my Athlon 800 Linux machine.
Furthermore, the MSDV.SYS driver is crashing the OS occasionally when
transmitting DV over 1394. All of this after the expensive Terratec
proaudio souncard drivers were crashing NT when playing DV. C'mon, you
mean I have to pay money for this!

I have really come to appreciate working in Linux despite the lack of
fearures. Kino is silky smooth and responsive with very savvy 1394
support. At least, one little hiccup in a Linux driver does not bring
down the entire OS. While hacking on the new dv1394 driver, there were
plenty of errors that simply prevented further use of the driver without
crashing the kernel. Also, the Terratec audio card is working fine in
Linux even though I had to purchase the OSS drivers from ForeFront.


On Thu, 2002-01-31 at 16:40, Charles 'Buck' Krasic wrote:
> 
> Hi.
> 
> In my experience writing libdv, it was very easy to have bugs which
> lead to artifacts such as you describe, and very difficult to track
> them down.  I could hazard a guess at the source of the artifacts you
> see: either they are not handling 2-4-8 dct blocks correctly, or they
> are not handling class 3 quantization correctly.  But that is only a
> guess.  Tracking these kinds of bugs down is very tricky.
> 
> If I had time, it would be interesting to port libdv to be a Premiere
> plugin and compare the results.  I am confident that our quality is
> very good.  Of course, I am also afraid that our speed is worse than
> the commercial codecs.
> 
> Cheers,
> 
> -- Buck
> 
> ps You have gone to a lot of trouble to clearly identify the problem.
>    A nice thing about open source is that someone with enough
>    motivation and skill can go all the way to try and fix the bug.
>    Not an option with Pinnacle et al.  :-|
> 
> "Ardi" <ago...@wa...> writes:
> 
> > Hi,
> > 
> > We have here an amazing problem with DV codec.
> > 
> > Until now, all Pinncale, Microsoft, Main Concept and Panasonic codec we have tested produce very poor results.
> > 
> > I explain this in the following page:
> > 
> > [[http://golgolabprod.multimania.com/CODEC-problem.html]]
> > 
> >  
> > 
> > Do agree my analyse or have an idea about this problem?
> > 
> >  
> > 
> > Bye
> > 
> > Ardi
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] Re: DV codec: quality problem

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

Hi.

In my experience writing libdv, it was very easy to have bugs which
lead to artifacts such as you describe, and very difficult to track
them down.  I could hazard a guess at the source of the artifacts you
see: either they are not handling 2-4-8 dct blocks correctly, or they
are not handling class 3 quantization correctly.  But that is only a
guess.  Tracking these kinds of bugs down is very tricky.

If I had time, it would be interesting to port libdv to be a Premiere
plugin and compare the results.  I am confident that our quality is
very good.  Of course, I am also afraid that our speed is worse than
the commercial codecs.

Cheers,

-- Buck

ps You have gone to a lot of trouble to clearly identify the problem.
   A nice thing about open source is that someone with enough
   motivation and skill can go all the way to try and fix the bug.
   Not an option with Pinnacle et al.  :-|

"Ardi" <ago...@wa...> writes:

> Hi,
>=20
> We have here an amazing problem with DV codec.
>=20
> Until now, all Pinncale, Microsoft, Main Concept and Panasonic codec we=
 have tested produce very poor results.
>=20
> I explain this in the following page:
>=20
> [[http://golgolabprod.multimania.com/CODEC-problem.html]]
>=20
> =A0
>=20
> Do agree my analyse or have an idea=A0about this=A0problem?
>=20
> =A0
>=20
> Bye
>=20
> Ardi

[libdv-dev] Segfault in libdv when decoding frame

[<mh...@in...>]

Hello,

I ran into a segfault with libdv (CVS snapshot from last saturday
and version 0.9) while trying to decode the frame¹ I've placed at

                   http://www.mark13.de/other/segfault.dv

into RGB pixels with playdv² on an AMD K6 CPU. The problem exists 
with and without x86 optimizations.

Thanks in advance,

  Mark

¹) The frames before this one are just fine.
²) It's not the playdv variant from the CVS, but my modified
   version with XShm support. But I'm pretty sure the problem 
   isn't on my side.

[libdv-dev] MMX instructions causing segfault on PIII patched?

[Alan C. <al...@co...>]

Has anyone developed a patch for the MMX instructions that cause a
segfault on a Pentium III?  The list archives and bug list mention
this but I don't see that anyone's posted a fix.  Is the performance
improvement worth the effort?  I'm using libdv with --disable-asm just
fine (and slow) and wonder how much faster it would run if I tried to
fix the assembler code.
/a

[libdv-dev] [ libdv-Bugs-498636 ] bug in rgb.c

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

Bugs item #498636, was opened at 2002-01-02 10:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=498636&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in rgb.c

Initial Comment:
Hi,
I've been using extensively your package libdv together
with
others and found a weird bug on some of my AVI files.

I use raw AVI dv2 format files grabbed by dvgrab and
transform them into mjpeg stream using dv2jpg. A few
times I
got the following segmentation fault in grb.c file
(from libdv)

Starting
program: /scratch1/valya/tmp/dv2jpg-1.1/dv2jpg
/export/1/opt/DV/mik2001.08.11_16-24-08.avi p.mjpeg
reading /export/1/opt/DV/mik2001.08.11_16-24-08.avi
Compressor: WHAT
fps: 29.970629
video_frames: 684
video_strn: 0
audio_bytes: 4381992
audio_strn: 1
width: 720
height: 480
a_fmt: 1
a_chans: 2
a_rate: 48000
a_bits: 16
Video setup: width=352, height=240, fps=29.970629
audio setup: channels=2, rate=48000, bits=16, format=1
Copying 684 frames
frame 85
Program received signal SIGSEGV, Segmentation fault.
dv_mb411_rgb (mb=0x8063c58, pixels=0xbfffdc80,
pitches=0xbfffdc70)
at rgb.c:149
149               *pwrgb++ = rgblut[r];
(gdb) where
#0  dv_mb411_rgb (mb=0x8063c58, pixels=0xbfffdc80,
pitches=0xbfffdc70)
at rgb.c:149
#1  0x8052cb1 in dv_decode_full_frame (dv=0x8be0e90,
buffer=0x8069540 "\037\a",
    color_space=e_dv_color_rgb, pixels=0xbfffdc80,
pitches=0xbfffdc70)
at dv.c:220
#2  0x804b4f0 in main (ac=3, av=0xbffff574) at
dv2jpg.c:139
#3  0x40328177 in ?? ()
(gdb) p pixels
$1 = (guchar **) 0xffecec91
(gdb) p *pixels
Cannot access memory at address 0xffecec91
(gdb) p **pixels
Cannot access memory at address 0xffecec91
(gdb) p pitches
$2 = (gint *) 0xbfffdc70
(gdb) p pixels
$3 = (guchar **) 0xffecec91
(gdb) p pixels[0]
Cannot access memory at address 0xffecec91
(gdb) p mb
$4 = (dv_macroblock_t *) 0xb3b2b1b0
I don't have a clue what is that, but think you can
help. In the case if you need input file it can be
downloaded from
http://www-clued0.fnal.gov/~vkuznet/BUGS/mik2001.08.11_16-24-08.avi
as well as dv2jpg executable (with debug option
enabled):
http://www-clued0.fnal.gov/~vkuznet/BUGS/dv2jpg

Thanks,
Valentin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=498636&group_id=4393

[libdv-dev] [ libdv-Bugs-489379 ] crashes on dv_init

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

Bugs item #489379, was opened at 2001-12-05 06:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=489379&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: crashes on dv_init

Initial Comment:
Hi,

all programs that use libdv crash on dv_init (checked
with kino, playdv) on a SuSE7.1/I386. All packages from
original distro.

The funny thing is that on a SuSE7.1/PPC it works great !

HW is PIII 866MHz, 512MB RAM.

Any ideas ?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=489379&group_id=4393

alpha dv_utils package (was: Re: [libdv-dev] small encoder problem and some unrelated code)

[Arthur P. <am...@si...>]

Here is the URL to download the utils I mentioned earlier.

http://www.singingwizard.org/programming.php

To recap, the package includes: dv2avi (converts raw DV to a type 1 DV 
AVI), dvavi2mov (converts a DV AVI to a DV Quicktime file. requires 
Quicktime4Linux), mov2dv (a extended "encodedv" that can encode from a 
Quicktime file to raw DV. Audio is currently broken. If you fix it 
please send me the fix. requires Quicktime4Linux), and exportdv (the 
Kino IEEE1394 export code with a command-line interface. Not really 
needed, but it might be handy someday.).

I appolegize for the slow downloads. I'm running my own web server on a 
DSL. So downloads from my site are limited to about 14KBytes/sec. If 
someone feels like mirroring this or something it's fine with me.

Hope someone can use these utils.

-Arthur

PS: GCC-3.0+ is required at least some of the programs. I use 3.0.2.

Charles 'Buck' Krasic wrote:

>Arthur,
>
>I will gladly accept what you've done so far into libdv, but I agree
>with Dan that Quicktime support seams more relevent and useful to
>kino, and so I join him in encouraging you to direct your subsequent
>efforts there.
>
>-- Buck
>
>

Re: [libdv-dev] small encoder problem and some unrelated code

[Dan D. <da...@de...>]

Thanks for staying tuned, Erik. We in the Kino team esp. myself have
been heavily evaluating gstreamer since the beginning of the year. We
really do want to use it based upon its goals. There are several issues
preventing us from using it in whole, but I realize we could use it in
part to provide multiple import/export formats, audio processing, and
perhaps some image processing. The biggest problem though I see is the
complexity for users. I myself have trouble keeping my system updated
well enough to support building gstreamer let alone developing on it. I
do not necesarily see that as any fault in gstreamer, rather something
that can be remedied through packaging and distros.

Based upon my last evaluation, OpenQuicktime needs much more integration
with the various codecs. The yuvscaler was broken thereby breaking MPEG
export (due to its size limitations). AVI (de)muxer needed integration
with DV. dv1394src ! .. ! xvideosink crashed after a few seconds due to
buffer issues? The latest build I tried required libtool 1.4, which
broke the build of most lib tarballs I use, and I did not have the time
to figure out coexistance.

I realize this sounds lame, but most of us on the Kino team are
part-time hobbyists and have trouble keeping up with the demanding
requirements of gstreamer and then the updates we would need to provide
to get it working for us.

Do you suggest we re-evaluate now or do you have a future milestone when
we should?  Keep up the good work; I do strongly believe in the goals of
gstreamer and the progress thus far.


On Tue, 2001-11-27 at 00:13, Erik Walthinsen wrote:
> On 26 Nov 2001, Charles 'Buck' Krasic wrote:
> 
> > I will gladly accept what you've done so far into libdv, but I agree
> > with Dan that Quicktime support seams more relevent and useful to
> > kino, and so I join him in encouraging you to direct your subsequent
> > efforts there.
> 
> You might also want to look at using GStreamer, since it's designed for
> pluggable operation.  The state of the quicktime support is unknown to me
> at the moment, but a post to gstreamer-devel will undoubtedly get a quick
> answer.  The libdv-based plugin is rather primitive at the moment, I
> should go and fix it.
> 
>       Erik Walthinsen <om...@te...> - System Administrator
>         __
>        /  \                GStreamer - The only way to stream!
>       |    | M E G A        ***** http://gstreamer.net/ *****
>       _\  /_
> 

Re: [libdv-dev] small encoder problem and some unrelated code

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

On 26 Nov 2001, Charles 'Buck' Krasic wrote:

> I will gladly accept what you've done so far into libdv, but I agree
> with Dan that Quicktime support seams more relevent and useful to
> kino, and so I join him in encouraging you to direct your subsequent
> efforts there.

You might also want to look at using GStreamer, since it's designed for
pluggable operation.  The state of the quicktime support is unknown to me
at the moment, but a post to gstreamer-devel will undoubtedly get a quick
answer.  The libdv-based plugin is rather primitive at the moment, I
should go and fix it.

      Erik Walthinsen <om...@te...> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_

Re: [libdv-dev] small encoder problem and some unrelated code

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

Arthur,

I will gladly accept what you've done so far into libdv, but I agree
with Dan that Quicktime support seams more relevent and useful to
kino, and so I join him in encouraging you to direct your subsequent
efforts there.

-- Buck

Re: [libdv-dev] small encoder problem and some unrelated code

[Dan D. <da...@de...>]

Well, much more will need to change. Therefore, you understand my
previous response to just work on Qt export! We are currently discussing
major code restructuring in a forum on Arne Schirmacher's Kino site esp.
support for dynamic loading plugins. 

On Mon, 2001-11-26 at 23:23, Arthur Peters wrote:
> Another thing about adding quicktime and raw DV support.
> 
> I thought of something while doing a preliminary scan of the kino code: 
> The file type detection code is in KinoCommon. This doesn't seem like to 
> right place. It seems to me that this code should be in Playlist and 
> Playlist would have a single function Load( const char* filename ). Tell 
> me if you agree. It looks like in would be fairly easy to move the code 
> and now is the time do in since we are adding 2 new file types.
> 
> Just my 2 cents.
> 
> -Arthur

Re: [libdv-dev] small encoder problem and some unrelated code

[Arthur P. <am...@si...>]

Another thing about adding quicktime and raw DV support.

I thought of something while doing a preliminary scan of the kino code: 
The file type detection code is in KinoCommon. This doesn't seem like to 
right place. It seems to me that this code should be in Playlist and 
Playlist would have a single function Load( const char* filename ). Tell 
me if you agree. It looks like in would be fairly easy to move the code 
and now is the time do in since we are adding 2 new file types.

Just my 2 cents.

-Arthur

Dan Dennedy wrote:

>Arthur, what's the chance of you helping us with Kino? Perhaps you can
>add Quicktime and raw support to start? 
>I vote to add all of your utilities to libdv cvs.
>
>On Mon, 2001-11-26 at 00:15, Arthur Peters wrote:
>
>>Firstly, I have found that the non-MMX encoder code is broken. It 
>>produces an image with a light colored dot at the top-left of every 
>>"encoding-block" (I know nothing about the DV encoding, but that is what 
>>it looks like.)
>>
>>Secondly, I have written a input filter for the encoder that reads 
>>quicktime movies using Quicktime4Linux. (audio is currently broken, but 
>>I'll get it fixed.) I setup my own little version of encodedv that 
>>registers the filter with the encoder automaticly, but I was thinking 
>>that this code might be good to have in the libdv distrobution. If you 
>>agree, I will gladly try to intagrate it with the library in whatever 
>>way seems best to you. If you don't think it is a good idea, I'll post 
>>URL where interested parties can download it.
>>
>>BTW, I have written a few other DV related programs: dvavi2mov (converts 
>>DV AVIs to DV Quicktime files), dv2avi (converts raw DV data to a DV 
>>AVI). Both of these use the AVI code from Kino. I'll get them packaged 
>>up and put them on my website (url: http://www.singingwizard.org/) soon.
>>
>>I hope this is not too off topic and I hope my code and info is useful.
>>
>>-Arthur
>>
>>
>>
>>_______________________________________________
>>libdv-dev mailing list
>>lib...@li...
>>https://lists.sourceforge.net/lists/listinfo/libdv-dev
>>
>
>

Re: [libdv-dev] small encoder problem and some unrelated code

[Dan D. <da...@de...>]

Arthur, what's the chance of you helping us with Kino? Perhaps you can
add Quicktime and raw support to start? 
I vote to add all of your utilities to libdv cvs.

On Mon, 2001-11-26 at 00:15, Arthur Peters wrote:
> Firstly, I have found that the non-MMX encoder code is broken. It 
> produces an image with a light colored dot at the top-left of every 
> "encoding-block" (I know nothing about the DV encoding, but that is what 
> it looks like.)
> 
> Secondly, I have written a input filter for the encoder that reads 
> quicktime movies using Quicktime4Linux. (audio is currently broken, but 
> I'll get it fixed.) I setup my own little version of encodedv that 
> registers the filter with the encoder automaticly, but I was thinking 
> that this code might be good to have in the libdv distrobution. If you 
> agree, I will gladly try to intagrate it with the library in whatever 
> way seems best to you. If you don't think it is a good idea, I'll post 
> URL where interested parties can download it.
> 
> BTW, I have written a few other DV related programs: dvavi2mov (converts 
> DV AVIs to DV Quicktime files), dv2avi (converts raw DV data to a DV 
> AVI). Both of these use the AVI code from Kino. I'll get them packaged 
> up and put them on my website (url: http://www.singingwizard.org/) soon.
> 
> I hope this is not too off topic and I hope my code and info is useful.
> 
> -Arthur
> 
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] small encoder problem and some unrelated code

[Arthur P. <am...@si...>]

Firstly, I have found that the non-MMX encoder code is broken. It 
produces an image with a light colored dot at the top-left of every 
"encoding-block" (I know nothing about the DV encoding, but that is what 
it looks like.)

Secondly, I have written a input filter for the encoder that reads 
quicktime movies using Quicktime4Linux. (audio is currently broken, but 
I'll get it fixed.) I setup my own little version of encodedv that 
registers the filter with the encoder automaticly, but I was thinking 
that this code might be good to have in the libdv distrobution. If you 
agree, I will gladly try to intagrate it with the library in whatever 
way seems best to you. If you don't think it is a good idea, I'll post 
URL where interested parties can download it.

BTW, I have written a few other DV related programs: dvavi2mov (converts 
DV AVIs to DV Quicktime files), dv2avi (converts raw DV data to a DV 
AVI). Both of these use the AVI code from Kino. I'll get them packaged 
up and put them on my website (url: http://www.singingwizard.org/) soon.

I hope this is not too off topic and I hope my code and info is useful.

-Arthur

[libdv-dev] Re: [Kino-dev] RE: Audio beep issues 12bit/32kHz mode

[Dan D. <da...@de...>]

On Fri, 2001-11-23 at 17:35, Stefan Lucke wrote:
> On Wednesday 21 November 2001 21:56, Arne Schirmacher wrote:
> > How are those bad frames detected? I would like to add at least some
> > diagnostic messages in dvgrab and Kino. Is the video data affected too?
> 
> Video errors ?
> Hmmm. YES. They appear at different locations for multiple grabs of the same
> scene :-(( .
> 

What were you using for capture, dvgrab? Were you doing anything else on
the system while capturing?

The current approach to capture is somewhat sensitive because so much
happens in userspace. About a year ago, I modified dvgrab to use
video1394 for capture, and a user recently contributed a patch against
Kino 0.46 to do the same thing. I rejected the patch because Dan Maas
and I finalizing a dv1394 driver to replace the use of video1394 (esp.
for dv transmission), and it will be integrated with Kino. The patch
contributor explained that he gets more reliable captures with video1394
even while doing other tasks. If that's the case, then dv1394 should
prove even more reliable because it assembles packets into frames in the
kernel space whereas even video1394 still operates at the packet level.

[libdv-dev] Re: [Kino-dev] RE: Audio beep issues 12bit/32kHz mode

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

On Wednesday 21 November 2001 21:56, Arne Schirmacher wrote:
> How are those bad frames detected? I would like to add at least some
> diagnostic messages in dvgrab and Kino. Is the video data affected too?

Video errors ?
Hmmm. YES. They appear at different locations for multiple grabs of the same
scene :-(( .

So I think it's time to post some code to report them.
Those who applied my previous patch for libdv code, have to
revert it, because it is NOT a fix.

Now I only try to report them even in 16bit audio mode. This
one is still unchecked because my 16bit NTSC samples have some video errors
but no audio errors.

Patch should apply to released version of libdv. There should be a problem
with CVS version depending on audio array element change from 24 -> 24.

Feedback welcome.

-- 

mfg

  Stefan Lucke (Ste...@ep...)

[libdv-dev] RE: Audio beep issues 12bit/32kHz mode

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

How are those bad frames detected? I would like to add at least some =
diagnostic messages in dvgrab and Kino. Is the video data affected too?

[libdv-dev] RE: [Kino-dev] Audio beep issues 12bit/32kHz mode

[Charles Y. <cha...@pa...>]

Stefan,

Thanks for looking into this one.

I think the report would help (ideally a report could pop up when the user
presses on stop).

I also think replacing the beeps with silence would be preferable to leaving
the corrupt audio in place - an interpolation of the frames on either side
may get convoluted if you have many corruptions occuring sequentially [and
you'll also have to take into account the corruption occuring on the first
and last frames] but if you feel confident enough to work these situations
in, then I say go for it...

A second pass for a long tape could be a bit aggravating, but I guess we
have the avc controls to seek to nearby positions...

Maybe the best scenario is to offer the user the report with the choice of
blank, interpolate, second pass? The first two should be easy enough to
implement anyway...

Kind regards,

Charlie

[libdv-dev] Audio beep issues 12bit/32kHz mode

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

Hi,

after digging around with those beeps, I think they are are caused by a
hardware/tape read error at capture time. In one of my samples they were
first at frame 351 and 898 of 1508 sequence. Second capture of the same
sequence reported errors at frame 330 and 351 and a third one only 351.

The best way to resolve would be, report and keep track of thouse errors.
Kino should try in a second pass to recapture those error
frames. If frames marked with errors could not captured correctly,
then some sort of interpolation should happen.

Any other ideas ?


-- 

mfg

  Stefan Lucke (Ste...@ep...)

RE: [Kino-dev] Re: [libdv-dev] 12bit audio bleep still NOT FIXED

[Charles Y. <cha...@pa...>]

Stefan,

> For grabdv and kino it is very hard since they gernerate DV2 type avi
files
> on the fly. It seems to be impossible to do that without audio decoding
and
> filering such invalid samples.

I'm not sure about this - I use kino for recording a 'digital diary' kinda
thing (bung the cam into photo mode, start kino, go to capture and press the
red button - ie: record directly to the hard drive). When I do this, I never
get any beeps in the audio (at least, none so far and I've filled and
removed quite a few gigabytes of me gibbering to the camera ;-))...

Further, when I export the video with beeps back to the tape, I don't hear
beeps when I playback via the camera/tv, but if you really, really pay
attention you can hear that the audio has gaps corresponding to where the
beeps are. However, if you playback this tape via kino's capture, you will
get beeps in exactly the same places, no matter how often you play it...
Going back to the original tape reveals beeps also in the same places (and
tv playback having those rendered as barely detectable silence...).

At least, that's how it works with DCR-TRV11E. Can anyone confirm if that's
the case with their cam too?

Incidentally, this record to hard drive thing is pretty neat if you have
analogue in on your cam - you can plug that into a video recorder or
non-firewire cam (or a laptop with a tv out etc etc) and capture direct to
hard drive from the firewire output (no tapes, no mess, and ... no beeps?).

Cheers,

Charlie