libdv-dev

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

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

On Saturday 17 November 2001 22:56, Erik Walthinsen wrote:
> On Sat, 17 Nov 2001, Stefan Lucke wrote:
> > So does that mean we may not trust the given value of samples per frame ?
> > Do we need a on the fly resamlper to adjust such differences for playing
> > ?
>
> IIRC, the IEC spec states that the number of samples per frame can vary
> within certain bounds, especially for certain types of audio.  I don't
> have the spec (Buck does), so I'm not sure how exactly it deals with these
> mismatches.  They are caused by unmatched hardware clocks in the recording
> device, and are common just about everywhere.  One of the problems in PC
> hardware is that the vertical retrace and the audio clocks are almost
> never truly in sync... ;-(

Libdv doesn't use hardcoded numbers of samples. From audio.c numbers
may vary between 1264 and 1296 samples per frame for PAL at 32000Hz
(31600 to 32400). But those from dv header calculated values are perhaps
wrong.

Did you solve such fine tuning issues with GStreamer ?
I know that there are some issues har to resolve. Recording at 31993 instead
of 32000 and playback at 32007 implies that you are off by 1 second
within 2/3 of an hour.

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.

-- 

mfg

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

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

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

On Sat, 17 Nov 2001, Stefan Lucke wrote:

> So does that mean we may not trust the given value of samples per frame ?
> Do we need a on the fly resamlper to adjust such differences for playing ?

IIRC, the IEC spec states that the number of samples per frame can vary
within certain bounds, especially for certain types of audio.  I don't
have the spec (Buck does), so I'm not sure how exactly it deals with these
mismatches.  They are caused by unmatched hardware clocks in the recording
device, and are common just about everywhere.  One of the problems in PC
hardware is that the vertical retrace and the audio clocks are almost
never truly in sync... ;-(

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

[libdv-dev] 12bit audio bleep still NOT FIXED

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

Hi
I've got a bit deeper into this problem, and it seems to be a more
serious thing.

In my sample files where these beeps occure there are, when beeps happen,
9 consecutive audio blocks filled with 0x800 (2048). In 16bit recording mode
value 0x8000 indicates an error and should be replaced by 0x8001.

One sequence with 1508 frames has 2 beeps. From header information there
should be 1930308 samples (most frames with 1280 samples some with 1281).
But 2 beeps means that there are
 2 * 9 * (72bytes / (2channels * 1.5 bytesPerSample)) = 432 samples
missing or filled with invalid values.
1508 frames / 25 FramesPerSecond at 32000 Hz would require 1930240.

Found samples ((1930308 - 432) * 25 FramesPerSecond) / 1508 frames
= 31993.97 Hz.

So does that mean we may not trust the given value of samples per frame ?
Do we need a on the fly resamlper to adjust such differences for playing ?


-- 

mfg

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

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

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

For release, we decided to set audioRendering=0 to use libdv, right?
Frame::ExtractAudio seems stable now, but I was experiencing some
horrible stuttering sound at the start of playback that I felt would be
annoying. Is that fixed?

On Sat, 2001-11-17 at 05:24, Charles Yates wrote:
> Well, that certainly sounds better :-)... but playback in kino via libdv's
> extract_full_audio has always had (and still has) a hissy quality - Arne's
> implementation of the ExtractAudio (in kinos/src/frame.cc) sounds better
> [for those not following the kinodev lists, 0.5 allows you to choose between
> the libdv and ExtractAudio rendering - for me the ExtractAudio method is
> working much better].
> 
> I am currently applying Stefan's fix to ExtractAudio and it currently plays
> bleepless (but slightly distorted) audio there too ... Will continue with
> this and post soon.
> 
> Thanks,
> 
> Charlie
> 
> -----Original Message-----
> From: kin...@li...
> [mailto:kin...@li...]On Behalf Of Stefan Lucke
> Sent: 17 November 2001 10:17
> To: lib...@li...; kino-dev
> Subject: [Kino-dev] 12bit audio bleep FIXED
> 
> 
> Hi,
> 
> for thouse using 12bit audio should try the following
> patch for fixing sound quality and audio bleeps in
> 32kHz 12bit mode. Patch is for libdv code
> (directory: YOUR_LIBDV_BASE_DIR/libdv).
> 
> ------- cut ------
> --- audio.c.orig        Fri Nov 16 22:59:57 2001
> +++ audio.c     Sat Nov 17 09:53:55 2001
> @@ -500,9 +500,11 @@
>        lsb   = inbuf[bp+2];
> 
>        y = ((msb_y << 4) & 0xff0) | ((lsb >> 4) & 0xf);
> -      if(y > 2047) y -= 4096;
> +      if(y == 2048) y = 4095;
> +      if(y > 2048) y -= 4096;
>        z = ((msb_z << 4) & 0xff0) | (lsb & 0xf);
> -      if(z > 2047) z -= 4096;
> +      if(z == 2048) z = 4095;
> +      if(z > 2048) z -= 4096;
> 
>        ysamples[i] = dv_upsample(y);
>        zsamples[i] = dv_upsample(z);
> ------- cut ------
> 
> 
> --
> 
> mfg
> 
>   Stefan Lucke (Ste...@ep...)
> 
> _______________________________________________
> Kino-dev mailing list
> Kin...@li...
> https://lists.sourceforge.net/lists/listinfo/kino-dev
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

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

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

Well, that certainly sounds better :-)... but playback in kino via libdv's
extract_full_audio has always had (and still has) a hissy quality - Arne's
implementation of the ExtractAudio (in kinos/src/frame.cc) sounds better
[for those not following the kinodev lists, 0.5 allows you to choose between
the libdv and ExtractAudio rendering - for me the ExtractAudio method is
working much better].

I am currently applying Stefan's fix to ExtractAudio and it currently plays
bleepless (but slightly distorted) audio there too ... Will continue with
this and post soon.

Thanks,

Charlie

-----Original Message-----
From: kin...@li...
[mailto:kin...@li...]On Behalf Of Stefan Lucke
Sent: 17 November 2001 10:17
To: lib...@li...; kino-dev
Subject: [Kino-dev] 12bit audio bleep FIXED


Hi,

for thouse using 12bit audio should try the following
patch for fixing sound quality and audio bleeps in
32kHz 12bit mode. Patch is for libdv code
(directory: YOUR_LIBDV_BASE_DIR/libdv).

------- cut ------
--- audio.c.orig        Fri Nov 16 22:59:57 2001
+++ audio.c     Sat Nov 17 09:53:55 2001
@@ -500,9 +500,11 @@
       lsb   = inbuf[bp+2];

       y = ((msb_y << 4) & 0xff0) | ((lsb >> 4) & 0xf);
-      if(y > 2047) y -= 4096;
+      if(y == 2048) y = 4095;
+      if(y > 2048) y -= 4096;
       z = ((msb_z << 4) & 0xff0) | (lsb & 0xf);
-      if(z > 2047) z -= 4096;
+      if(z == 2048) z = 4095;
+      if(z > 2048) z -= 4096;

       ysamples[i] = dv_upsample(y);
       zsamples[i] = dv_upsample(z);
------- cut ------


--

mfg

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

_______________________________________________
Kino-dev mailing list
Kin...@li...
https://lists.sourceforge.net/lists/listinfo/kino-dev

[libdv-dev] 12bit audio bleep FIXED

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

Hi,

for thouse using 12bit audio should try the following
patch for fixing sound quality and audio bleeps in
32kHz 12bit mode. Patch is for libdv code 
(directory: YOUR_LIBDV_BASE_DIR/libdv).

------- cut ------
--- audio.c.orig        Fri Nov 16 22:59:57 2001
+++ audio.c     Sat Nov 17 09:53:55 2001
@@ -500,9 +500,11 @@
       lsb   = inbuf[bp+2];

       y = ((msb_y << 4) & 0xff0) | ((lsb >> 4) & 0xf);
-      if(y > 2047) y -= 4096;
+      if(y == 2048) y = 4095;
+      if(y > 2048) y -= 4096;
       z = ((msb_z << 4) & 0xff0) | (lsb & 0xf);
-      if(z > 2047) z -= 4096;
+      if(z == 2048) z = 4095;
+      if(z > 2048) z -= 4096;

       ysamples[i] = dv_upsample(y);
       zsamples[i] = dv_upsample(z);
------- cut ------


-- 

mfg

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

[libdv-dev] FYI: DV files and Dazzle Hollywood wierdness

[Alastair M. <am...@pe...>]

Hi,

  To save anyone who might be doing something similar the week of
hair pulling and head banging that it took me to figure it out,
I thought I'd mentioned the wierd problem I found with some DV files.

  First some background:  I have an app that, in part, creates a
videotape assembled from a selection of video clips stored in raw
DV format, using "dvconnect -s" to send them via 1394 to a Dazzle
Hollywood DV bridge that converts it to composite video and audio
for input to a (computer controlled) VHS recorder.

  Throughout development and testing, this process worked fine.
Install it at the customer site, load up the latest video clip
data, and we started getting dropouts as the DV bridge lost synch.
(An annoying quirk of the Dazzle box is that it takes about 5 seconds
to start sending video out after the start of a good DV data stream,
I set the system up to send 10 seconds of black first to get
around that.)

   After eliminating likely causes (eg data underruns because of
the disk not keeping up, etc -- tweaked with hdparm) we were still
getting the problem.   

   Finally (after much hair pulling, gnashing of teeth, etc, etc)
I determined that the *last frame* of each clip was bogus: all the
AAUX, Audio, etc flags were set to zero -- which caused the firmware
in the Dazzle box to hiccup and drop the output for a few seconds.

   I wrote a quick'n'dirty script to eliminate the last frame of
each file (just calculating the size and using "head") and after that
everything worked fine.

   Now, I wish I could tell you *why* the DV files had that funky
zeroed last frame.   The digitizing was done by a third party 
video shop in Hollywood, I just received a hard-drive with the
(approx 30 GB) of video clips on it.   If it's any clue, the drive
was in NTFS format so whatever they did the conversion on was
Windows-based.  (BTW, the video was originally shot/edited in NTSC
but converted to PAL since that's what the customer needed.)

   Just thought you might like to know.   I wish the Dazzle Hollywood
*didn't* discard the first few seconds of video after a change in
the format of the datastream, but that's something I can live with
(and aside from that, it's a very nice box for the price -- and about
the only one in its price range that supports both NTSC and PAL).

 Cheers,
   -- Alastair

[libdv-dev] [ libdv-Bugs-481997 ] dv_format_wide Failure

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

Bugs item #481997, was opened at 2001-11-14 23:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=481997&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charles Yates (lilo_booter)
Assigned to: Nobody/Anonymous (nobody)
Summary: dv_format_wide Failure

Initial Comment:
The wide screen flag on a frame is not being correctly 
determined from frames captured on my Sony DCR-TRV11E 
(PAL) - the function always returns 0.

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

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

[libdv-dev] [ libdv-Bugs-481046 ] Corrupted video decode (green speckles

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Craig-Wood (ncw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Corrupted video decode (green speckles 

Initial Comment:
I captured some PAL video using kino.  When I view that
video in kino I see green speckles on certain heavily
colour saturated parts of the video.  However when I
send the video back to the camera I don't see any
problem with it.

I'm pretty sure this is a problem with libdv.

I've attached a short avi file (4 frames) made with
kino as an example.  I couldn't think of a sensible way
to capture a .dv file though as I haven't any means of
editing them - I hope this will do as an example.

If you view it you'll notice that it has some
very obvious green speckles in it on the little boy's
shirt.  I'm guessing that this is a bug in libdv
because a) the green speckles persist if I use lav2yuv
on the file (ie not kino reading the file) and b) the
green speckles aren't there if export the video back to
the camera (ie the file is really ok).

I compiled libdv from source using gcc version 2.95.3
20010315 (release) (which I also compiled from source).


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

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

[libdv-dev] [ libdv-Patches-475394 ] Fix for mmx_ok SEGV with broken gcc-fPIC

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

Patches item #475394, was opened at 2001-10-26 11:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=475394&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Daney (daney)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for mmx_ok SEGV with broken gcc-fPIC

Initial Comment:
I submitted a bug for this also, but I thought I should
also put the patch here.

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

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

[libdv-dev] [ libdv-Bugs-472945 ] mmx_ok crashes + patch to work arround.

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

Bugs item #472945, was opened at 2001-10-19 15:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=472945&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Daney (daney)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmx_ok crashes + patch to work arround.

Initial Comment:
I am running linux 1.2.4 on athlon (not that I think
that  this is relevent) and using gcc 2.96 from Red Hat
(This seems to be the problem).

When linked to libdv.so, mmx_ok crashes.  The problem
is that this version of gcc thinks that ebx is still
valid even though the mm_support __asm__ code says that
it is clobbered.  The problem is either the asm code
does not properly say what is clobbered, or gcc has a
bug.  I work around the problem with the attached patch.

Dave.


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

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

Re: [libdv-dev] (no subject)

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

I've been very busy with my studies, including travelling abroad for
the last two weeks.  Just got back today.

I'll try and do some catching up on the oustanding libdv bugs, and
the various submitted fixes.

For this specific one, I'm going to see if just lifting the mmx.h from
ffmpeg does the trick.  I was perusing their code before I left on my
travels and it appeared they (ffmpeg maintainers) had been fixing up
their own copy of mmx.h.

-- Buck

Chad Page <cp...@si...> writes:

> 	I've had the same problem - I've just went into libdv and replaced
> mmx_ok() with 1 and sidestepped it.  Or 0, if you don't have MMX, but then
> again what x86 CPU powerful enough to deal with DV dosen't? 
> 
> 	- Chad
> 
> On Mon, 17 Sep 2001, Arne Schirmacher wrote:
> 
> > Can somebody please check this bug report? I have received several
> > similar emails, all having trouble with the mmx_ok function (or
> > somewhere near it). 
> > 
> > I have now the very same problem. Kino crashes in mmx_ok(). My CPU is an AMD Duron.
> > 
> > http://www.schirmacher.de/dcforum/DCForumID4/35.html
> > 
> > Thanks, Arne

Re: [libdv-dev] (no subject)

[Chad P. <cp...@si...>]

	I've had the same problem - I've just went into libdv and replaced
mmx_ok() with 1 and sidestepped it.  Or 0, if you don't have MMX, but then
again what x86 CPU powerful enough to deal with DV dosen't? 

	- Chad

On Mon, 17 Sep 2001, Arne Schirmacher wrote:

> Can somebody please check this bug report? I have received several
> similar emails, all having trouble with the mmx_ok function (or
> somewhere near it). 
> 
> I have now the very same problem. Kino crashes in mmx_ok(). My CPU is an AMD Duron.
> 
> http://www.schirmacher.de/dcforum/DCForumID4/35.html
> 
> Thanks, Arne
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev
> 

[libdv-dev] (no subject)

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

Can somebody please check this bug report? I have received several
similar emails, all having trouble with the mmx_ok function (or
somewhere near it). 

I have now the very same problem. Kino crashes in mmx_ok(). My CPU is an AMD Duron.

http://www.schirmacher.de/dcforum/DCForumID4/35.html

Thanks, Arne

[libdv-dev] [ libdv-Bugs-452411 ] occasional crashes

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

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

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

Initial Comment:
Crashes on some frames of my video streams, which were
captured from a JVC DVX90 camcorder. Crash is avoided
after adding some boundary checking codes to vlc_x86.S
as attached, though output of the affected frame is
still garbled.

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

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

Re: [libdv-dev] another libdv mm_support() problem

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

I just got back from vacation.   I'll have a look soon...

-- Buck


Taras <tar...@ho...> writes:

> Hello,
> I'm another person who is experiencing crashes during mmx support check.
> Please fix this somehow, so far I've been "fixing" it by putting return
> 1 at the top of the file. 
> This segfault really bugs me because a number of projects use some
> version of libdv and they all crash on this function.
> 
> I've got glibc2.2.3 and am on debian testing right now.
> 
> This is a mobile pIII 700 cpu. 
> 
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] another libdv mm_support() problem

[Taras <tar...@ho...>]

Hello,
I'm another person who is experiencing crashes during mmx support check.
Please fix this somehow, so far I've been "fixing" it by putting return
1 at the top of the file. 
This segfault really bugs me because a number of projects use some
version of libdv and they all crash on this function.

I've got glibc2.2.3 and am on debian testing right now.

This is a mobile pIII 700 cpu. 

[libdv-dev] [ libdv-Bugs-448856 ] Erreur dans dv_audio_unshuffle_50

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

Bugs item #448856, was opened at 2001-08-07 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=448856&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Erreur dans dv_audio_unshuffle_50

Initial Comment:
Bonjour
Je pense avoir trouvé une erreur dans le code source 
du fichier audio.c dans l'archive libdv-0.9.tar.gz :
 
static int dv_audio_unshuffle_50[6][9] = {
  {  0, 18, 36, 13, 31, 49,  8, 26, 44 },
  {  3, 21, 39, 16, 34, 52, 11, 29, 47 },
  {  6, 24, 42,  1, 19, 37, 14, 32, 50 }, 
  {  9, 27, 45,  4, 22, 40, 17, 35, 53 }, 
  { 12, 30, 48,  7, 24, 43,  2, 20, 38 },    // 
le '24' apparait pour la seconde fois. Cela fonctionne 
en le remplaçant par '25'
  { 15, 33, 51, 10, 28, 46,  5, 23, 41 },
};
 
Situation de disfonctionnement : enregistrement PAL en 
12 bits, cela produit une valeur fausse au gint16  25 
puis l'erreur se répète de 50 en 50.
 
Félicitation pour le travail fourni !
Tristan Dufay (tri...@wa...)


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

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

[libdv-dev] [ libdv-Bugs-444029 ] MMX check crashes

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

Bugs item #444029, was opened at 2001-07-24 01:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=444029&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bonneville (bonnevil)
Assigned to: Nobody/Anonymous (nobody)
Summary: MMX check crashes

Initial Comment:
I have a PIII 750MHz and my code always crashes in
dv_init() function, especially in mm_support().
I have read the other similar bug report about MMX
check on an AMD, and it looks quite the same....

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

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

Re: [libdv-dev] NTSC - PAL conversion?

[Alastair M. <ala...@aj...>]

Dan Dennedy wrote:
> 
> I know someone who has used MainActor on Linux to do this. I believe you
> need to capture AVI type-2 files for use with MainActor. Then, you could
> use Kino to send the AVI files. It might be more valuable to write
> something that can be contributed tho :-)
> 
> +-DRD-+
> 
> Alastair Mayer wrote:
> 
> > Hi,
> >     I have about three hours' worth of NTSC-format DV files that I
> > need to convert to PAL format.

I prototyped doing it using existing command line tools, something like:

    playdv --dump-frames=- --audio-file=foo.wav foo_ntsc.dv | \
      ppmqscale 720 576 | \
      encodedv stdin foo.wav > foo_pal.dv

Which sort of worked. I didn't get the audio stream, and I had to tweak
encodedv because I couldn't make it understand "-" for stdin (hence
"stdin"
above).  Also ppmqscale crashed on the above arguments on a zero-divide
(a
comparison on width was causing it to call shrink_picture() instead of 
enlarge_picture()).   I still need to drop every sixth frame, too.  But
it shows me that the necessary pieces are there.

When I get the audio stream figured out (yeah, I could do it with a
second
pass using encodedv, I'd rather not), I'll let you all know.  I may end
up
just rolling the relevant parts of all the above programs into a single
ntsc2pal program.  (PAL to NTSC would be similar to above but with
different
arguments to ppmqscale, and probably duplicating every 5th frame.  Not
real
pretty, I'm afraid.)

If anyone wants the specific changes to ppmqscale and encodedv I
mentioned
above, let me know and I'll post the diffs.

-- Alastair

Re: [libdv-dev] NTSC - PAL conversion?

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

I know someone who has used MainActor on Linux to do this. I believe you 
need to capture AVI type-2 files for use with MainActor. Then, you could 
use Kino to send the AVI files. It might be more valuable to write 
something that can be contributed tho :-)

+-DRD-+

Alastair Mayer wrote:

> Hi,
>     I have about three hours' worth of NTSC-format DV files that I 
> need to convert to PAL format.    It doesn't really matter whether
> this is done at capture time, from one disk file to another, or at
> playback time (actually the latter is probably least desirable).
> 
>    Does anyone have anything working for this, or am I going to
> have to use playdv/encodedv and hack each frame's PPM file?
> (I think I know what I need to do, I'm just hoping somebody else
> has already written the code :)
> 
>  -- Alastair
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libdv-dev
> 

[libdv-dev] NTSC - PAL conversion?

[Alastair M. <ala...@aj...>]

Hi,
    I have about three hours' worth of NTSC-format DV files that I 
need to convert to PAL format.    It doesn't really matter whether
this is done at capture time, from one disk file to another, or at
playback time (actually the latter is probably least desirable).

   Does anyone have anything working for this, or am I going to
have to use playdv/encodedv and hack each frame's PPM file?
(I think I know what I need to do, I'm just hoping somebody else
has already written the code :)

 -- Alastair

On vacation [[libdv-dev] crash in mmx_ok()]

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

I am on vacation in France until July 30th.

-- Buck

Arne Schirmacher <arn...@d2...> writes:

> Can somebody please check this bug report? I have received several
> similar emails, all having trouble with the mmx_ok function (or
> somewhere near it).
> 
> http://www.schirmacher.de/dcforum/DCForumID4/35.html
> 
> Thanks, Arne
> 
> 
> 
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] [ libdv-Bugs-440050 ] mmx check crashes on amd

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

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

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

Initial Comment:
I have a amd K7-1Ghz and the mm_support function
generates a segmentation fault.

So i had to disable the mmx check completely.
Sorry dont know how to fix

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

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

[libdv-dev] [ libdv-Bugs-440048 ] gtk is checked but no define for it

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

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: gtk is checked but no define for it

Initial Comment:
The configure script correctly checks the existance of
gtk
but does not define HAVE_GTK so the
code for a gtk window is not included.


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

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