libdv-dev

[libdv-dev] Utility to split a DV file based on the timestamps

[Olivier C. <ocr...@fr...>]

Hi all

For my own needs, I have written a command line utility based on libdv 
to split a DV file in smaller DV files based on the frame timestamps.

It may be useful to other people, so I post it here. Is there also a way 
to include it in the libdv distribution?

Best regards

Olivier

[libdv-dev] Cross compile error

[Will W. <wil...@ca...>]

Hi All,

I am trying to build libdv in a cross compile environment and it is 
failing with the following error:

make[2]: Entering directory
`/home/willw/buildroot/build_i686/libdv-1.0.0'
Making all in libdv
make[3]: Entering directory
`/home/willw/buildroot/build_i686/libdv-1.0.0/libdv'
if
/home/willw/buildroot/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc
-Os -pipe  -I/home/willw/buildroot/build_i686/staging_dir/usr/include
-I/home/willw/buildroot/build_i686/staging_dir/include
--sysroot=/home/willw/buildroot/build_i686/staging_dir/ -isysroot
/home/willw/buildroot/build_i686/staging_dir -mtune=i686 -march=i686
-DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -Wall -g -MT gasmoff.o -MD -MP
-MF ".deps/gasmoff.Tpo" -c -o gasmoff.o gasmoff.c; \
	then mv -f ".deps/gasmoff.Tpo" ".deps/gasmoff.Po"; else rm -f
".deps/gasmoff.Tpo"; exit 1; fi
/bin/sh ../libtool --silent --tag=CC --mode=link
/home/willw/buildroot/build_i686/staging_dir/usr/bin/i686-linux-uclibc-gcc
-Os -pipe  -I/home/willw/buildroot/build_i686/staging_dir/usr/include
-I/home/willw/buildroot/build_i686/staging_dir/include
--sysroot=/home/willw/buildroot/build_i686/staging_dir/ -isysroot
/home/willw/buildroot/build_i686/staging_dir -mtune=i686 -march=i686  -g
-O2 -Wall -g   -o gasmoff  gasmoff.o  -lm
./gasmoff > asmoff.h
/bin/sh: ./gasmoff: No such file or directory
make[3]: *** [asmoff.h] Error 127

Inside the libdv directory it has built an executable gasmoff

willw@phosphorus:~/buildroot/build_i686/libdv-1.0.0/libdv$ file gasmoff
gasmoff: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped

I am cross compiling using buildroot (www.buildroot.org), the host 
system is i686 as is the target. However the target system is for an 
embedded platform using uClibc.

Looking at the make file it would seem that gasmoff is compiled with the 
target compiler which I think would explain why I am unable to run it on 
the host system. Would that explain my error?

How can I fix this issue? I guess I could disable assembler 
optimisations but I would prefer not to. What does that step do so that 
I can work round this issue?

Thanks

Will


-- 
------------------------------------------------------------------------
Will Wagner                                     wil...@ca...
Senior Project Engineer                  Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------

Re: [libdv-dev] audio block/sample failure

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

On Thu, Mar 27, 2008 at 6:26 AM, Daniel Harris
<mai...@go...> wrote:
> Hello Guys
>
> I am having trouble capturing video from my canon MD235 camera, and I
> suspect it is a problem with libdv.  dvcapture works fine but when I play
> the file back in playdv the following messages keep appearing
>
> abf 00:00:42.02 2008-03-22 13:07:42 77 17 00 12 48/48
[...]
> I have posted a message on the kino-dev list but I now think it is a problem
> with libdv.

It is not a problem with libdv. There are some errors detected and
libdv is reporting them - it is being verbose. Usually, they are not a
big deal. Use your ears. If you are not pleased with what you hear,
then you have to either re-shoot, edit out that part, or do something
else in an waveform editor to try to clean it up. Kino tells libdv to
try to rewrite the bad PCM with an average between the previous and
next good PCM samples.

-- 
+-DRD-+

[libdv-dev] audio block/sample failure

[Daniel H. <mai...@go...>]

Hello Guys

I am having trouble capturing video from my canon MD235 camera, and I
suspect it is a problem with libdv.  dvcapture works fine but when I play
the file back in playdv the following messages keep appearing

abf 00:00:42.02 2008-03-22 13:07:42 77 17 00 12 48/48
abf 00:00:42.02 2008-03-22 13:07:42 77 17 01 12 48/48
abf 00:00:42.02 2008-03-22 13:07:42 77 17 02 12 48/48
abf 00:00:42.02 2008-03-22 13:07:42 77 17 03 12 48/48
abf 00:00:42.02 2008-03-22 13:07:42 77 17 04 12 48/48
# audio block/sample failure for 5 blocks, 240 samples of 1280
abf 00:00:46.06 2008-03-22 13:07:46 73 57 00 12 48/48
abf 00:00:46.06 2008-03-22 13:07:46 73 57 01 12 48/48
abf 00:00:46.06 2008-03-22 13:07:46 73 57 02 12 48/48
abf 00:00:46.06 2008-03-22 13:07:46 73 57 03 12 48/48
abf 00:00:46.06 2008-03-22 13:07:46 73 57 04 12 48/48
# audio block/sample failure for 5 blocks, 240 samples of 1280

This is using 16bit audio but i think I get a slightly different error when
using 12bit.

Any Help is appreciated.

Thanks Dan.

I have posted a message on the kino-dev list but I now think it is a problem
with libdv.

[libdv-dev] [PATCH] fix dvgrab build with gcc 4.3

[Jarod W. <jw...@re...>]

We're currently rebuilding all Fedora packages for Fedora 9 using the shiny 
new gcc 4.3 compiler. One of the big chances is how the preprocessor handles 
header inclusion, which breaks most compiles where headers are implicitly 
included instead of explicitly. There are quite a few dvgrab files that need 
#include <string.h> added to 'em to build properly with gcc 4.3. Attached is 
the patch I used to get dvgrab 3.1 building again.

-- 
Jarod Wilson
jw...@re...

Re: [libdv-dev] Generational degradation study

[Roman S. <rv...@su...>]

On Nov 11, 2007, at 12:47 AM, David McNab wrote:

>>   There's also a project that provides python bindings for ffmpeg,
>> perhaps
>>    it'll be easier to use than a pure library:
>>       http://pymedia.org/faq.html
>
> I tried that. Segfault city on my box.

   Too bad. Well, perhaps using a framework as Dan has suggested will  
help.

>
>>> I might be
>>> sticking to libdv for now.
>
>>   You're not a real video-phile, are you? ;-)
>
> If you mean that I'm more into high-level programming and actual
> creative video work than delving into the guts of complicated
> under-documented low-level C code - if you mean I'm more into driving
> cars, maybe fitting a few accessories here and there, than casting
> pistons, hand-crafting valves and re-machining engine blocks, then  
> yes,
> you're absolutely right. :)

    Case closed ;-)

Thanks,
Roman.

Re: [libdv-dev] Generational degradation study

[David M. <re...@or...>]

On Sat, 2007-11-10 at 21:58 -0800, Roman Shaposhnik wrote:
> > It might be just me, but I find libavcodec very off-putting. Dozens
> > to
> > hundreds of lines of code needed just to get a stream open and start
> > accessing its contents. Added to that is the total lack of lavc
> > documentation and the scarcity of programming examples.
> > Unless I can come across some short comprehensible programming
> > examples
> > that demonstrate exactly how to encode and decode DV format, 
> 
>   Do you consider these to be inadequate: 
>      http://ffmpeg.mplayerhq.hu/documentation.html

Well, any documentation is better than no documentation.
I've been through that collection, but even with the 2 brief tutorials,
it's not very effective for helping newcomers scale the steep lavc/lavf
learning curve.

>   There's also a project that provides python bindings for ffmpeg,
> perhaps
>    it'll be easier to use than a pure library:
>       http://pymedia.org/faq.html

I tried that. Segfault city on my box.

> > I might be
> > sticking to libdv for now.

>   You're not a real video-phile, are you? ;-)

If you mean that I'm more into high-level programming and actual
creative video work than delving into the guts of complicated
under-documented low-level C code - if you mean I'm more into driving
cars, maybe fitting a few accessories here and there, than casting
pistons, hand-crafting valves and re-machining engine blocks, then yes,
you're absolutely right. :)

Cheers
David

Re: [libdv-dev] Generational degradation study

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

On Saturday 10 November 2007, David McNab wrote:
> On Sat, 2007-11-10 at 19:33 -0800, Dan Dennedy wrote:
> > libdv is no longer maintained, and ffmpeg has a much better DV codec:
> > http://web.archive.org/web/20070119194244/www.sfendt.de/dvstress.html
>
> One thing libdv has that ffmpeg (libavcodec) doesn't - a stable coherent
> API.

True, and I think that is fine if you are just coding this to amuse yourself 
or do something simple and ad hoc without much re-encoding. libdv is still 
handy for parsing DV streams such as to get timecode and other metadata.

> It might be just me, but I find libavcodec very off-putting. Dozens to
> hundreds of lines of code needed just to get a stream open and start
> accessing its contents. Added to that is the total lack of lavc
> documentation and the scarcity of programming examples.
>
> Unless I can come across some short comprehensible programming examples
> that demonstrate exactly how to encode and decode DV format, I might be
> sticking to libdv for now.

Also, consider using a framework. There are plenty of choices including 
gstreamer, libquicktime, and MLT. I maintain Kino and MLT. Kino has a Frame 
class that shows how I access just the dvvideo codec in ffmpeg. MLT is not 
only an editing framework around ffmpeg. It is similar to gstreamer+gnonlin, 
which pitivi and jokosher use. OpenMovieEditor uses libquicktime, and 
kdenlive is using MLT. You can sort of evaluate the relative maturity and 
capability of each by playing with the apps or reading about them. MLT has a 
C++ wrapper that generates Python bindings through swig:

#!/usr/bin/env python
import mltpp
import time
import sys

# Start the mlt system
mltpp.Factory.init( )

# Create the producer
p = mltpp.Producer( sys.argv[1] )

if p:
        # Create the consumer
        c = mltpp.Consumer( "sdl" )

        # Connect the producer to the consumer
        c.connect( p )

        # Start the consumer
        c.start( )

        # Wait until the user stops the consumer
        while c.is_stopped( ) == 0:
                time.sleep( 1 )
else:
        # Diagnostics
        print "Unable to open ", sys.argv[ 1 ]

Re: [libdv-dev] Generational degradation study

[Roman S. <rv...@su...>]

On Nov 10, 2007, at 8:27 PM, David McNab wrote:

> On Sat, 2007-11-10 at 19:33 -0800, Dan Dennedy wrote:
>> libdv is no longer maintained, and ffmpeg has a much better DV codec:
>> http://web.archive.org/web/20070119194244/www.sfendt.de/dvstress.html
>
> One thing libdv has that ffmpeg (libavcodec) doesn't - a stable  
> coherent
> API.

   I wish I had spare time :-( I've been so detached from ffmpeg lately
that it actually hurts :-( Perhaps integrating DVCPRO HD might change
that.

> It might be just me, but I find libavcodec very off-putting. Dozens to
> hundreds of lines of code needed just to get a stream open and start
> accessing its contents. Added to that is the total lack of lavc
> documentation and the scarcity of programming examples.
>
> Unless I can come across some short comprehensible programming  
> examples
> that demonstrate exactly how to encode and decode DV format,

   Do you consider these to be inadequate:
       http://ffmpeg.mplayerhq.hu/documentation.html
   There's also a project that provides python bindings for ffmpeg,  
perhaps
    it'll be easier to use than a pure library:
       http://pymedia.org/faq.html

> I might be
> sticking to libdv for now.

   You're not a real video-phile, are you? ;-)

Thanks,
Roman.

Re: [libdv-dev] Generational degradation study

[David M. <re...@or...>]

On Sat, 2007-11-10 at 19:33 -0800, Dan Dennedy wrote:
> libdv is no longer maintained, and ffmpeg has a much better DV codec:
> http://web.archive.org/web/20070119194244/www.sfendt.de/dvstress.html

One thing libdv has that ffmpeg (libavcodec) doesn't - a stable coherent
API.

It might be just me, but I find libavcodec very off-putting. Dozens to
hundreds of lines of code needed just to get a stream open and start
accessing its contents. Added to that is the total lack of lavc
documentation and the scarcity of programming examples.

Unless I can come across some short comprehensible programming examples
that demonstrate exactly how to encode and decode DV format, I might be
sticking to libdv for now.

Cheers
David

Re: [libdv-dev] Generational degradation study

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

On Saturday 10 November 2007, David McNab wrote:
> I've just done a study on the degradation when decoding/encoding from/to
> DV over increasing numbers of generations via libdv.
>
> The degradation is insignificant with 1 or 2 generations, gets noticable
> at 5, and worsens from there.
>
> http://www.freenet.org.nz/dvgens
>
> All in all, DV is a great editing format, due to the constant size of
> the encoded blocks. This makes it very fast to move through files, edit
> in place etc. But it really pushes the point that keeping the number of
> decoding/encoding generations to a bare minimum can be a good idea :)

Always a good idea, even when working with uncompressed, but libdv is no 
longer maintained, and ffmpeg has a much better DV codec:

http://web.archive.org/web/20070119194244/www.sfendt.de/dvstress.html

[libdv-dev] Generational degradation study

[David M. <re...@or...>]

Hi,

I've just done a study on the degradation when decoding/encoding from/to
DV over increasing numbers of generations via libdv.

The degradation is insignificant with 1 or 2 generations, gets noticable
at 5, and worsens from there.

http://www.freenet.org.nz/dvgens

All in all, DV is a great editing format, due to the constant size of
the encoded blocks. This makes it very fast to move through files, edit
in place etc. But it really pushes the point that keeping the number of
decoding/encoding generations to a bare minimum can be a good idea :)

Cheers
David

Re: [libdv-dev] python bindings for libdv

[David M. <re...@or...>]

On Mon, 2007-10-29 at 16:38 +0800, Roman Shaposhnik wrote:
>    True. But I thought the whole point of your exercise was to provide
> a python API. Which means that you can very well do the "API  
> translation". ;-)

Well, when/if I get up to speed with lavc/lavf, I just might do that.

>    Seriously, though, I've been thinking about creating libdv2 based on
> the FFmpeg code that I wrote. That item, however, always gets
> pushed to the end of my TODO list :-(

Can your FFmpeg dv codec be used separately without going through the
main lavf/lavc API?

Or, can you point me to some simple example code for decoding DV into
raw audio/video frames, and encoding raw audio/video frames to DV?

Cheers
David

Re: [libdv-dev] python bindings for libdv

[Roman S. <rv...@su...>]

On Oct 29, 2007, at 4:32 PM, David McNab wrote:

> On Mon, 2007-10-29 at 16:00 +0800, Roman Shaposhnik wrote:
>> I believe that libdv has entered a sustaining only mode. The DV
>> development
>> has moved to the FFmpeg project: http://ffmpeg.mplayerhq.hu. There's
>> much
>> more functionality in ffmpeg's DV codec than there is in libdv. One
>> of these
>> days it may even support DVHD.
>>
>>    On top of that the quality of libdv encoding is quite bad.
>>
>>    With that in mind, perhaps looking into FFmpeg might make more
>> sense. Just
>> my 2c.
>
> One thing libdv has that ffmpeg's libavcodec/libavformat don't - a
> coherent and easily-learned API.

   True. But I thought the whole point of your exercise was to provide
a python API. Which means that you can very well do the "API  
translation". ;-)

   Seriously, though, I've been thinking about creating libdv2 based on
the FFmpeg code that I wrote. That item, however, always gets
pushed to the end of my TODO list :-(

Thanks,
Roman.

Re: [libdv-dev] python bindings for libdv

[David M. <re...@or...>]

On Mon, 2007-10-29 at 16:00 +0800, Roman Shaposhnik wrote:
> I believe that libdv has entered a sustaining only mode. The DV  
> development
> has moved to the FFmpeg project: http://ffmpeg.mplayerhq.hu. There's  
> much
> more functionality in ffmpeg's DV codec than there is in libdv. One  
> of these
> days it may even support DVHD.
> 
>    On top of that the quality of libdv encoding is quite bad.
> 
>    With that in mind, perhaps looking into FFmpeg might make more  
> sense. Just
> my 2c.

One thing libdv has that ffmpeg's libavcodec/libavformat don't - a
coherent and easily-learned API.

Cheers
David

> 
> Thanks,
> Roman.

Re: [libdv-dev] python bindings for libdv

[Roman S. <rv...@su...>]

Hi David,

On Oct 29, 2007, at 6:07 AM, David McNab wrote:
> If libdv folks are interested, I can work this binding up to a formal
> release package with API docs and examples and post a link.

   I believe that libdv has entered a sustaining only mode. The DV  
development
has moved to the FFmpeg project: http://ffmpeg.mplayerhq.hu. There's  
much
more functionality in ffmpeg's DV codec than there is in libdv. One  
of these
days it may even support DVHD.

   On top of that the quality of libdv encoding is quite bad.

   With that in mind, perhaps looking into FFmpeg might make more  
sense. Just
my 2c.

Thanks,
Roman.

[libdv-dev] chroma upsampling

[David M. <re...@or...>]

Hi,

When libdv decodes 4:2:0 or 4:1:1 frames into full raw video buffers,
does it do anything smart with the CbCr upsampling? Or does it just
duplicate the chroma values?

Cheers
David

[libdv-dev] n00b question about yuv mode

[David M. <re...@or...>]

Hi all,

When decoding frames to YUV, I notice that the buffer format is 2 bytes
per pixel (as opposed to 3 bytes/pixel - R,G,B,R,G,B... - with RGB
mode).

What is the format of the byte pairs when decoding frames as YUV?

Cheers
David

[libdv-dev] python bindings for libdv

[David M. <re...@or...>]

Hi all,

I've written some Python bindings for libdv, using the Pyrex python/C
wrapper language.

Implementation gives three classes:

 - Frame - encapsulates the audio and video data for a single frame's
   duration, and offers methods for accessing/manipulating the
   raw video and audio data

 - Decoder - wraps the major libdv decoding/query primitives, reads
   a raw DV file or stream and decodes frames into Frame objects

 - Encoder - takes Frame objects and writes DV stream to a file

Performance seems reasonably acceptable, given that it's Python. On my
Athlon 2400XP box (2.0GHz 32 bit), working with PAL DV footage, I'm
getting:

 - decoding frames without wrapping them in a Python object:
    - 68 frames/sec, 14.7 ms/frame

 - decoding frames and wrapping them in a Python Frame object:
    - 52 frames/sec, 19.2 ms/frame

 - decoding frames to Python objects, then encoding/writing them
   to a new DV file:
    - 27.5 frames/sec, 36.4 ms/frame

If libdv folks are interested, I can work this binding up to a formal
release package with API docs and examples and post a link.

Cheers
David

[libdv-dev] [ libdv-Bugs-1799770 ] powerpc colourspace issues

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

Bugs item #1799770, was opened at 2007-09-21 18:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1799770&group_id=4393

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stefan de Konink (skinkie)
Assigned to: Nobody/Anonymous (nobody)
Summary: powerpc colourspace issues

Initial Comment:
Currently using libdv on big endian systems result in green/pink output. I saw serious effort was put into the BIG_ENDIAN ifdefs, but it doesn't really solve the problem.

It looks the problem is in YUV2, because YUV12 (for PAL) results in black/green bars.

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

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

[libdv-dev] [Fwd: [PATCH] Compiling libdv 0.104 with gcc 4.1.1]

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

-------- Original Message --------
Date: Tue, 13 Mar 2007 20:50:35 +0100
From: Saint Xavier <sk...@sk...>
To: kr...@ac..., ome...@us...
Subject: [PATCH] Compiling libdv 0.104 with gcc 4.1.1

Hi,

I tried to compile libdv-0.104 today on my x86_64 machine
with gcc-4.1.1 and these options: --prefix=/usr --disable-gtk --disable-asm

Unfortunalety nasty things append because of (i think) a couple
of "extern" in front of functions in libdv/vlc.h ...

This patch solve the compilation problem, I've not yet tested the
library by the way...

Regards,
Saint Xavier

--- libdv-0.104/libdv/vlc.h.orig	2007-03-13 19:40:36.000000000 +0100
+++ libdv-0.104/libdv/vlc.h	2007-03-13 19:44:23.000000000 +0100
@@ -66,15 +66,10 @@

  // Note we assume bits is right (lsb) aligned, 0 < maxbits < 17
  // This may look crazy, but there are no branches here.
-extern void dv_decode_vlc(int bits,int maxbits, dv_vlc_t *result);
-extern void __dv_decode_vlc(int bits, dv_vlc_t *result);
+void dv_decode_vlc(int bits,int maxbits, dv_vlc_t *result);
+void __dv_decode_vlc(int bits, dv_vlc_t *result);

-extern __inline__ void dv_peek_vlc(bitstream_t *bs,int maxbits, dv_vlc_t
*result) {
-  if(maxbits < 16)
-    dv_decode_vlc(bitstream_show(bs,16),maxbits,result);
-  else
-    __dv_decode_vlc(bitstream_show(bs,16),result);
-} // dv_peek_vlc
+__inline__ void dv_peek_vlc(bitstream_t *bs,int maxbits, dv_vlc_t *result);

  #ifdef __cplusplus
  }
--- libdv-0.104/libdv/vlc.c.orig	2007-03-13 19:40:43.000000000 +0100
+++ libdv-0.104/libdv/vlc.c	2007-03-13 19:44:23.000000000 +0100
@@ -804,4 +804,12 @@
    result->amp = amps[has_sign &  /* or vlc not valid */
  		    (bits >> sign_rshift[result->len])];
  } /* __dv_decode_vlc */
+
+__inline__ void dv_peek_vlc(bitstream_t *bs,int maxbits, dv_vlc_t *result) {
+  if(maxbits < 16)
+    dv_decode_vlc(bitstream_show(bs,16),maxbits,result);
+  else
+    __dv_decode_vlc(bitstream_show(bs,16),result);
+} // dv_peek_vlc
+
  #endif /* (! ARCH_X86) && (!ARCH_X86_64) */

Re: [libdv-dev] 1920 and 1921 samples

[Leander S. <leg...@t-...>]

Jonathan Woithe wrote:

> audio as implemented on some video cameras.  The footage doesn't happen
> to come from a Sony camera which is around 7 years old, does it?

Yes, thats a good guess. It's not my cam but i know it was a Sony and
I think it was some years old.

> You can grab audiosync 0.4 from
>   http://www.physics.adelaide.edu.au/~jwoithe/audiosync-0.4.tgz


Thanks a lot for your detailed answer! And sorry for my late reply.

Leander

Re: [libdv-dev] 1920 and 1921 samples

[Leander S. <leg...@t-...>]

Johannes Sixt wrote:
> Learn about 'locked' and 'unlocked' audio. 'Locked' audio means that you get
> the expected 1920 samples per frame. Only professional systems have this.

I see. Thank you,
Leander

Re: [libdv-dev] 1920 and 1921 samples

[Jonathan W. <jw...@ph...>]

> when decoding dv video libdv gives me sometimes
> 1921 audio samples instead of the expected 1920.
> I' assume that this is some additional sample
> to match the 25fps (PAL) timecode, but dividing
> 48000/25 gives exactly 1920 so this seems not to be
> necessary.

It sounds very much like a (non-standards compliant) form of unlocked
audio as implemented on some video cameras.  The footage doesn't happen
to come from a Sony camera which is around 7 years old, does it?

In the affected cameras the frame clock is not synchronised to the audio
clock at all - both are effectively free-running oscillators.  Therefore
relative to the video frame rate the audio sampling frequency will not
be exactly 48 kHz, but rather something like 48.00001 kHz.  This in turn
means that every so often you happen to get 1921 audio samples taken
in the time a given video frame is captured, which is why you see
periodic occurances of 1921 audio samples in some video frames.

Note that this type of unlocked audio is not described in the DV standard.
The standard unlocked audio can drift in the short term (so you can get
1921 samples per frame) but over the long term it doesn't (occurances
of 1921 samples are balanced by occurances of 1919, for example).

The behaviour you're seeing is in fact more annoying than the official
version of unlocked audio.  The problem is that the resulting audio track,
when assumed to be exactly 48 kHz relative to the video frame rate, will end
up being too long; the end of the audio track will correspond to the end of
the video track in terms of material, but (for clips 10 minutes long or
longer) the audio will end some seconds after the video.  Unless your
editing software knows about this and can correct for it, a lot of your
audio will be out of sync.

This is the situation I have with a camera I use regularly.  I wrote
a little application called audiosync to deal with it.  I capture using
dvgrab to a Qt/DV file and then run audiosync to effectively resample
the audio so it remains in sync with the video.  This process means the
pitch remains unchanged (as it should) but the resulting audio track
is sampled at exactly 48 kHz relative to the video frame rate and thus
is now the correct length.

You can grab audiosync 0.4 from

  http://www.physics.adelaide.edu.au/~jwoithe/audiosync-0.4.tgz

(I have a new version ready to go which will appear when I have
time to make it so.)

> And: when I simply ignore this additional sample the sound stops crackling
> in my program.  But maybe the timing in my program isn't that perfect yet.

Which program are you using and how are you using it?  Normally ignoring the
extra sample will produce slight clicks in the audio output - possibly not
detectable if the audio is speech, but with music they can be quite obvious.
It sounds like the program might be one you wrote yourself so there might
well be an issue in the code.  If you could make a tarball available
somewhere someone might be able to take a quick look and see if anything is
obvious.  I suspect there might be a gremlin in there somewhere because I've
never had crackling when I've played the captured DV stream (with the
periodic 1921 samples per video frame) back with things such as glav and
mplayer.

Regards
  jonathan

Re: [libdv-dev] 1920 and 1921 samples

[Johannes S. <joh...@te...>]

On Monday 05 February 2007 13:00, Leander Seige wrote:
> Hello,
>
> when decoding dv video libdv gives me sometimes
> 1921 audio samples instead of the expected 1920.
> I' assume that this is some additional sample
> to match the 25fps (PAL) timecode, but dividing
> 48000/25 gives exactly 1920 so this seems not to be
> necessary. And: when I simply ignore this additional
> sample the sound stops crackling in my program.
> But maybe the timing in my program isn't that
> perfect yet.

Learn about 'locked' and 'unlocked' audio. 'Locked' audio means that you get 
the expected 1920 samples per frame. Only professional systems have this. 
Consumer cameras only have 'Unlocked' audio, which means that you are not 
guaranteed to get the expected number of samples, not even on average. (The 
reason is that the video and audio units have separate timers that are not 
accurately in sync; this is much cheaper to manufacture, I guess.)

-- Hannes