libdv-dev

[libdv-dev] [ libdv-Bugs-3466606 ] dvconnect needs additional include for _IOWR on solaris

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

Bugs item #3466606, was opened at 2011-12-28 15:18
Message generated for change (Tracker Item Submitted) made by enchanter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104393&aid=3466606&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: Tim Mooney (enchanter)
Assigned to: Nobody/Anonymous (nobody)
Summary: dvconnect needs additional include for _IOWR on solaris

Initial Comment:
Building libdv-1.0.0 on x86_64-sun-solaris2.10 (not OpenSolaris) with the no-cost Sun/Oracle Workshop 12.2 compiler toolchain.

When building dvconnect.c I get a compile failure because _IOWR is not defined:

"dvconnect.c", line 373: warning: implicit function declaration: _IOWR
"dvconnect.c", line 373: syntax error before or at: struct
"dvconnect.c", line 378: syntax error before or at: if
"dvconnect.c", line 378: syntax error before or at: =
"dvconnect.c", line 378: syntax error before or at: )
"dvconnect.c", line 380: syntax error before or at: 0

and so on.

dvconnect.c is including sys/ioctl.h, but the problem is that on Solaris, the _IOWR macro and friends are not defined in sys/ioctl.h.  They're actually defined in sys/ioccom.h, but it appears that the best way to get them is to include sys/filio.h.  In fact, sys/ioctl.h would include sys/filio.h, but only if the BSD-backwards compatibility -DBSD_COMP define is present, and there are warnings in sys/ioctl.h about unpleasant side-effects from that define.

Long story short, it appears the best way to get _IOWR on Solaris is to include sys/filio.h.

Do you want a patch that does something like

#ifdef (__sun)
#include <sys/filio.h>
#endif

or would you prefer an

AC_CHECK_HEADER([sys/filio.h])

and a

#if HAVE_SYS_FILIO_H
#include <sys/filio.h>
#endif

?  Seems like the second one is better and might help out other odd duck platforms, but I'll code up whichever you want and supply a patch.



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

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

[libdv-dev] [ libdv-Bugs-3466591 ] dvconnect.c needs -lrt on Solaris

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

Bugs item #3466591, was opened at 2011-12-28 15:08
Message generated for change (Tracker Item Submitted) made by enchanter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104393&aid=3466591&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: Tim Mooney (enchanter)
Assigned to: Nobody/Anonymous (nobody)
Summary: dvconnect.c needs -lrt on Solaris

Initial Comment:
Building libdv-1.0.0 on x86_64-sun-solaris2.10 (not OpenSolaris) with the no-cost Sun/Oracle Workshop 12.2 compiler toolchain.

Although all the pthread-related stuff is in libpthread and is correctly being detected by configure, on Solaris the sched_* functions are in the "realtime" library, librt.  The simple fix is to check for sched_setscheduler in -lrt after checking for libpthread.

Here's what configure now outputs for me:

checking for pthread_create in -lpthread... yes
checking for sqrt in -lm... yes
checking for sched_setscheduler in -lrt... yes

Simple patch is attached.

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

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

[libdv-dev] need help on DV video file format

[pcuser p <pcu...@gm...>]

I am trying to write a wrapper for dv dec(dv,dvcpro25/50) by reading
input from a dv encoded video file.I have some progressive encoded dv
video files in my pc.(ntsc & pal resolution)

But I don't know how to interpret the (.dv) file,I dont have the file
format spec for dv.
can somebody provide me insight on dv file format, or atleast provide
me the link for the file format spec of dv.

I have seen that libdv can decode all types of dv files.
"on what file format libdv dv decoder is implemented?how it
interprets dv files and extract header and metadata?"

If a dv file is contained in avi container,will there be any
modification in dv header & metadata.if we extract dv from avi
file,will the dv file contain header and metadata conforming with dv
standard file format (hope one exists,which i am searching for...)

PS:I have looked into SMPTE314M standard,it has info about data
compression but not on dv file format

I really got struck at the dv decoder wrapper for sometime without
having a dv file format specification...
Any help would be greatly appreciated!

Regards,
RJ

Re: [libdv-dev] observations from dv_decode_full_audio()

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

On Tue, Dec 2, 2008 at 4:58 PM, salsaman <sal...@gm...> wrote:
> Running dv_decode_full_audio() on a 1GB file, I get quite a few
> errors/warnings like:
>
> # audio block/sample failure for 0 blocks, 32 samples of 1280
> asf 00:00:00.00 2000-00-00 00:00:00 77 07 05 12 1/48
> asf 00:00:00.00 2000-00-00 00:00:00 77 07 08 12 1/48
> asf 00:00:00.00 2000-00-00 00:00:00 77 17 02 12 1/48
> asf 00:00:00.00 2000-00-00 00:00:00 77 17 05 12 1/48
> asf 00:00:00.00 2000-00-00 00:00:00 77 17 08 12 1/48
>
>
> Is this anything to be concerned about ? Is it possible to turn this

It depends upon your requirements and the frequency of these warnings.
If you need perfect audio, then it is a problem, but for most people
some of this is quite tolerable.

> debugging output off ?

you can direct to /dev/null using dv_set_error_log(). I do that in
Kino and dvgrab.

> Also, running through valgrind, at the end of audio processing I see this:
>
> ==8132== Use of uninitialised value of size 8
> ==8132==    at 0x1D126C26: (within /usr/lib/libdv.so.4.0.3)
> ==8132==    by 0x5: ???
> ==8132==    by 0x7FEFD36BF: ???
> ==8132==    by 0x1D11A8D8: dv_parse_ac_coeffs (in /usr/lib/libdv.so.4.0.3)
> ==8132==    by 0x1D1181DF: dv_decode_full_frame (in /usr/lib/libdv.so.4.0.3)

I use valgrind, but not heavily, and I always feel like such a noob
when doing so. I cross reference many messages with code and try to
figure out if there is really a problem or some silly complaining, or
I am just stupid? In this case, I have no comment. I try not to look
at its code much, but I still value it for its metadata and audio
functions.

-- 
+-DRD-+

[libdv-dev] observations from dv_decode_full_audio()

[salsaman <sal...@gm...>]

Running dv_decode_full_audio() on a 1GB file, I get quite a few
errors/warnings like:

# audio block/sample failure for 0 blocks, 32 samples of 1280
asf 00:00:00.00 2000-00-00 00:00:00 77 07 05 12 1/48
asf 00:00:00.00 2000-00-00 00:00:00 77 07 08 12 1/48
asf 00:00:00.00 2000-00-00 00:00:00 77 17 02 12 1/48
asf 00:00:00.00 2000-00-00 00:00:00 77 17 05 12 1/48
asf 00:00:00.00 2000-00-00 00:00:00 77 17 08 12 1/48


Is this anything to be concerned about ? Is it possible to turn this
debugging output off ?


Also, running through valgrind, at the end of audio processing I see this:

==8132== Use of uninitialised value of size 8
==8132==    at 0x1D126C26: (within /usr/lib/libdv.so.4.0.3)
==8132==    by 0x5: ???
==8132==    by 0x7FEFD36BF: ???
==8132==    by 0x1D11A8D8: dv_parse_ac_coeffs (in /usr/lib/libdv.so.4.0.3)
==8132==    by 0x1D1181DF: dv_decode_full_frame (in /usr/lib/libdv.so.4.0.3)



Regards,
Gabriel,
http://lives.sourceforge.net

Re: [libdv-dev] dv_decode_full_frame

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

On Dienstag, 7. Oktober 2008, salsaman wrote:
> + 1 other point, I was presuming that dv_get_samples() would return the
> sample size in bits, however it appears to return the number of samples per
> frame (which can of course be calculated as frequency/fps, so not very
> useful).

I know next to nothing about DV, but I do know that the number of samples per 
frame varies and can *not* be computed from frequency/fps. Google for 'locked 
unlocked audio dv'.

-- Hannes

Re: [libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

On Mon, Oct 6, 2008 at 7:41 PM, salsaman <sal...@gm...> wrote:

>
>
> On Mon, Sep 22, 2008 at 2:40 PM, Dan Dennedy <da...@de...> wrote:
>
>> On Mon, Sep 22, 2008 at 10:08 AM, salsaman <sal...@gm...> wrote:
>> > OK, thanks. Actually I already figured most of this out while I was
>> waiting
>> > for a reply !
>> >
>> > Now I would like to know how to get the audio values (rate, channels,
>> sample
>> > size, signedness and endianness).
>>
>> Please see the source code of playdv, kino, MLT, gstreamer, or other
>> users of libdv.
>>
>
> Thanks for the advice, but I was hoping for a bit less cryptic answer !
>
> What I found was generally:
> - read in a full frame
> - call dv_parse_audio_header()
> - use functions like dv_get_frequency()
>
> However, a couple of things:
>
> - dv_parse_audio_header() appears to be in libdv and working, however it is
> not defined in the header file.
> - there do not seem to be functions to get the signedness, endianess or
> interleaf (interleaved/non-interleaved) for the audio. Are these values
> fixed in the dv standard ?
>

+ 1 other point, I was presuming that dv_get_samples() would return the
sample size in bits, however it appears to return the number of samples per
frame (which can of course be calculated as frequency/fps, so not very
useful).

Should one assume that there are 16 bits per sample (or 20, 24 or 32).

Sorry if my questions appear stupid, but I know nothing about dv format - I
am approaching it from simply a programmatical point of view.




>
> Thanks in advance for any help, it is much appreciated.
>
> Gabriel.
> http://lives.sourceforge.net
>
>

Re: [libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

On Mon, Sep 22, 2008 at 2:40 PM, Dan Dennedy <da...@de...> wrote:

> On Mon, Sep 22, 2008 at 10:08 AM, salsaman <sal...@gm...> wrote:
> > OK, thanks. Actually I already figured most of this out while I was
> waiting
> > for a reply !
> >
> > Now I would like to know how to get the audio values (rate, channels,
> sample
> > size, signedness and endianness).
>
> Please see the source code of playdv, kino, MLT, gstreamer, or other
> users of libdv.
>

Thanks for the advice, but I was hoping for a bit less cryptic answer !

What I found was generally:
- read in a full frame
- call dv_parse_audio_header()
- use functions like dv_get_frequency()

However, a couple of things:

- dv_parse_audio_header() appears to be in libdv and working, however it is
not defined in the header file.
- there do not seem to be functions to get the signedness, endianess or
interleaf (interleaved/non-interleaved) for the audio. Are these values
fixed in the dv standard ?

Thanks in advance for any help, it is much appreciated.

Gabriel.
http://lives.sourceforge.net

Re: [libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

Apologies, replying to my own post again:

- I should have specified, what I am really interested in is the output from
dv_decode_full_audio(). The internal format of the dv clip is irrelevant to
me.


Regards,
Gabriel.
http://lives.sourceforge.net





On Mon, Oct 6, 2008 at 7:46 PM, salsaman <sal...@gm...> wrote:

>
>
> On Mon, Oct 6, 2008 at 7:41 PM, salsaman <sal...@gm...> wrote:
>
>>
>>
>> On Mon, Sep 22, 2008 at 2:40 PM, Dan Dennedy <da...@de...> wrote:
>>
>>> On Mon, Sep 22, 2008 at 10:08 AM, salsaman <sal...@gm...> wrote:
>>> > OK, thanks. Actually I already figured most of this out while I was
>>> waiting
>>> > for a reply !
>>> >
>>> > Now I would like to know how to get the audio values (rate, channels,
>>> sample
>>> > size, signedness and endianness).
>>>
>>> Please see the source code of playdv, kino, MLT, gstreamer, or other
>>> users of libdv.
>>>
>>
>> Thanks for the advice, but I was hoping for a bit less cryptic answer !
>>
>> What I found was generally:
>> - read in a full frame
>> - call dv_parse_audio_header()
>> - use functions like dv_get_frequency()
>>
>> However, a couple of things:
>>
>> - dv_parse_audio_header() appears to be in libdv and working, however it
>> is not defined in the header file.
>> - there do not seem to be functions to get the signedness, endianess or
>> interleaf (interleaved/non-interleaved) for the audio. Are these values
>> fixed in the dv standard ?
>>
>
> + 1 other point, I was presuming that dv_get_samples() would return the
> sample size in bits, however it appears to return the number of samples per
> frame (which can of course be calculated as frequency/fps, so not very
> useful).
>
> Should one assume that there are 16 bits per sample (or 20, 24 or 32).
>
> Sorry if my questions appear stupid, but I know nothing about dv format - I
> am approaching it from simply a programmatical point of view.
>
>
>
>
>>
>> Thanks in advance for any help, it is much appreciated.
>>
>> Gabriel.
>> http://lives.sourceforge.net
>>
>>
>

Re: [libdv-dev] dv_decode_full_frame

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

On Mon, Sep 22, 2008 at 10:08 AM, salsaman <sal...@gm...> wrote:
> OK, thanks. Actually I already figured most of this out while I was waiting
> for a reply !
>
> Now I would like to know how to get the audio values (rate, channels, sample
> size, signedness and endianness).

Please see the source code of playdv, kino, MLT, gstreamer, or other
users of libdv.

> Also, does the add_ntsc_setup field do anything (I see that it is ignored in
> init, but can be set separately) ? I seem to be able to encode NTSC without
> it.

no, it longer does anything
-- 
+-DRD-+

Re: [libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

OK, thanks. Actually I already figured most of this out while I was waiting
for a reply !

Now I would like to know how to get the audio values (rate, channels, sample
size, signedness and endianness).

Also, does the add_ntsc_setup field do anything (I see that it is ignored in
init, but can be set separately) ? I seem to be able to encode NTSC without
it.

If anyone is interested, the code is here:
http://lives.cvs.sourceforge.net/lives/lives-plugins/plugins/decoders/dv_decoder.c

it could be a useful example of a simple decoder.


Regards,
Salsaman.
http://lives.sourceforge.net


On Mon, Sep 22, 2008 at 1:48 PM, Dan Dennedy <da...@de...> wrote:

> On Sun, Sep 21, 2008 at 1:24 PM, salsaman <sal...@gm...> wrote:
> > Hi,
> > sorry if this is posted twice, my original message seems to have not
> reached
> > the list.
> >
> > could somebody please explain how yuv_mode of dv_decode_full_frame()
> works ?
>
> It is by default YUY2. It requires a build-time define for YV12.
> See here, start at line 278 for a quick example:
>
> http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/mlt/src/modules/dv/producer_libdv.c?v
> iew=markup
>
> > Also, do I need the dv_parse_header() and/or dv_parse_packs() ?
>
> dv_parse_header just for decoding video, use dv_parse_packs if you
> need certain metadata. It is safe to just call both.
>
> --
> +-DRD-+
>

Re: [libdv-dev] dv_decode_full_frame

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

On Sun, Sep 21, 2008 at 1:24 PM, salsaman <sal...@gm...> wrote:
> Hi,
> sorry if this is posted twice, my original message seems to have not reached
> the list.
>
> could somebody please explain how yuv_mode of dv_decode_full_frame() works ?

It is by default YUY2. It requires a build-time define for YV12.
See here, start at line 278 for a quick example:
http://mlt.svn.sourceforge.net/viewvc/mlt/trunk/mlt/src/modules/dv/producer_libdv.c?view=markup

> Also, do I need the dv_parse_header() and/or dv_parse_packs() ?

dv_parse_header just for decoding video, use dv_parse_packs if you
need certain metadata. It is safe to just call both.

-- 
+-DRD-+

[libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

Hi,
sorry if this is posted twice, my original message seems to have not reached
the list.

could somebody please explain how yuv_mode of dv_decode_full_frame() works ?

I have the following code for example (for PAL), but it is crashing:

    uint8_t fbuffer[144000];

    int frame=1;
    size_t bytes=144000;
    int rowstrides[3];

    if (cdata.palette==YUV420) {
      rowstrides[0]=720;
      rowstrides[1]=360;
      rowstrides[2]=360;
    }
    else {
      rowstrides[0]=cdata.width*6; // YUV411 - 6 bytes per pixel
    }

    lseek(fd,bytes,SEEK_SET);

    if (read (fd, fbuffer, 144000) < 144000) return FALSE;

    dv_parse_header(dv_dec, fbuffer);
    //dv_parse_packs(dv_dec, fbuffer);

    dv_decode_full_frame(dv_dec,fbuffer,e_dv_color_yuv,(uint8_t
**)pixel_data,rowstrides);




Here pixel_data is an array of pointers to the Y,U, and V planes for YUV420.

Also, do I need the dv_parse_header() and/or dv_parse_packs() ?


Regards,
Salsaman.
http://lives.sourceforge.net

Re: [libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

I should have mentioned cdata->width=720


Salsaman.
http://lives.sourceforge.net


On Sat, Sep 20, 2008 at 1:52 PM, salsaman <sal...@gm...> wrote:

> Hi,
> could somebody please explain how dv_decode_full_frame() works ?
>
> I have the following code for example (for PAL), but it is crashing:
>
>     uint8_t fbuffer[144000];
>
>     int frame=1;
>     size_t bytes=144000;
>     int rowstrides[3];
>
>     if (cdata.palette==YUV420) {
>       rowstrides[0]=cdata.width;
>       rowstrides[1]=cdata.width>>1;
>       rowstrides[2]=cdata.width>>1;
>     }
>     else {
>       rowstrides[0]=cdata.width*6; // YUV411 - 6 bytes per pixel
>     }
>
>     lseek(fd,bytes,SEEK_SET);
>
>     if (read (fd, fbuffer, 144000) < 144000) return FALSE;
>
>     dv_parse_header(dv_dec, fbuffer);
>     //dv_parse_packs(dv_dec, fbuffer);
>
>     dv_decode_full_frame(dv_dec,fbuffer,e_dv_color_yuv,(uint8_t
> **)pixel_data,rowstrides);
>
>
>
>
> Here pixel_data is an array of pointers to the Y,U, and V planes for
> YUV420.
>
> Also, do I need the dv_parse_header() and/or dv_parse_packs() ?
>
>
> Regards,
> Salsaman.
> http://lives.sourceforge.net
>
>
>
>

[libdv-dev] dv_decode_full_frame

[salsaman <sal...@gm...>]

Hi,
could somebody please explain how dv_decode_full_frame() works ?

I have the following code for example (for PAL), but it is crashing:

    uint8_t fbuffer[144000];

    int frame=1;
    size_t bytes=144000;
    int rowstrides[3];

    if (cdata.palette==YUV420) {
      rowstrides[0]=cdata.width;
      rowstrides[1]=cdata.width>>1;
      rowstrides[2]=cdata.width>>1;
    }
    else {
      rowstrides[0]=cdata.width*6; // YUV411 - 6 bytes per pixel
    }

    lseek(fd,bytes,SEEK_SET);

    if (read (fd, fbuffer, 144000) < 144000) return FALSE;

    dv_parse_header(dv_dec, fbuffer);
    //dv_parse_packs(dv_dec, fbuffer);

    dv_decode_full_frame(dv_dec,fbuffer,e_dv_color_yuv,(uint8_t
**)pixel_data,rowstrides);




Here pixel_data is an array of pointers to the Y,U, and V planes for YUV420.

Also, do I need the dv_parse_header() and/or dv_parse_packs() ?


Regards,
Salsaman.
http://lives.sourceforge.net

Re: [libdv-dev] [PATCH] sched_setscheduler

[Michael W. <mfwitten@MIT.EDU>]

On 10 Jul 2008, at 12:26 PM, Dan Dennedy wrote:

> On Wed, Jul 9, 2008 at 11:38 PM, Michael Witten <mfw...@mi...>  
> wrote:
>> Hello,
>>
>> Apparently sched_setscheduler() isn't quite fully supported,
>> and it certainly isn't defined in Mac OS X 10.5.3.
>
> And neither is the video1394 Linux kernel module for which dvconnect
> is written.  You should consider a patch that suppresses the
> compilation of dvconnect on OS X (as well as possibly playdv).

Good point!

Re: [libdv-dev] [PATCH] sched_setscheduler

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

On Wed, Jul 9, 2008 at 11:38 PM, Michael Witten <mfw...@mi...> wrote:
> Hello,
>
> Apparently sched_setscheduler() isn't quite fully supported,
> and it certainly isn't defined in Mac OS X 10.5.3.

And neither is the video1394 Linux kernel module for which dvconnect
is written.  You should consider a patch that suppresses the
compilation of dvconnect on OS X (as well as possibly playdv).

[libdv-dev] [PATCH] sched_setscheduler

[Michael W. <mfwitten@MIT.EDU>]

Hello,

Apparently sched_setscheduler() isn't quite fully supported,
and it certainly isn't defined in Mac OS X 10.5.3.

Following this:

	http://lists.apple.com/archives/Unix-porting/2005/Jul/msg00027.html

I have attached a patch that better handles the case in which
priority scheduling is not implemented (use the attached file,
because my MTA seems to remove empty lines, thereby corrupting
the patch; I should also note that I haven't really thought
about the consequences of my changes, though it should just
be rearrangement with a slight compile-time optimization due
to the use of preprocessor conditionals):

--- encodedv/dvconnect.c.old	2008-07-10 02:27:10.000000000 -0400
+++ encodedv/dvconnect.c	2008-07-10 02:26:38.000000000 -0400
@@ -857,24 +857,19 @@

  int rt_raisepri (int pri)
  {
-#ifdef _SC_PRIORITY_SCHEDULING
+#if (_POSIX_PRIORITY_SCHEDULING - 0) >=  200112L
  	struct sched_param scp;

-	/*
-	 * Verify that scheduling is available
-	 */
-	if (sysconf (_SC_PRIORITY_SCHEDULING) == -1) {
-		fprintf (stderr, "WARNING: RR-scheduler not available, "
-			 "disabling.\n");
-		return (-1);
-	} else {
-		memset (&scp, '\0', sizeof (scp));
-		scp.sched_priority = sched_get_priority_max (SCHED_RR) - pri;
-		if (sched_setscheduler (0, SCHED_RR, &scp) < 0)	{
-			fprintf (stderr, "WARNING: Cannot set RR-scheduler\n");
-			return (-1);
-		}
-	}
+    memset (&scp, '\0', sizeof (scp));
+    scp.sched_priority = sched_get_priority_max (SCHED_RR) - pri;
+    if (sched_setscheduler (0, SCHED_RR, &scp) < 0)	{
+        fprintf (stderr, "WARNING: Cannot set RR-scheduler, disabling 
\n");
+        return (-1);
+    }
+
+#else
+    fprintf (stderr, "WARNING: RR-scheduler not available, disabling. 
\n");
+    return (-1);
  #endif
  	return (0);
  }


Sincerely,
Michael Witten

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

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

Dan Dennedy wrote, On 30/06/08 18:59:
 > dvgrab already reads dv from stdin and has
> several file splitting and file naming options. However, I did not
> want to respond immediately with any words of discouragement,  but now
> you have put me on the spot ;-).

Well I am not really keen on reinventing the wheel, so I would of course 
have appreciated a word about dvgrab sooner.

It wouldn't have solve my problem though, since dvgrab is not trivial to 
port to my platform (MacOS X) which doesn't have libraw1394.

 > I do strongly suggest adding it to
> the SourceForge tracker. Then, if there ever is a new libdv release,
> it might get included.

OK, even if, to get "officially" the DV splitting on MacOS X, the 
chances look better to adapt dvgrab and create a port for the MacOS X 
platform.

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

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

On Mon, Jun 30, 2008 at 3:04 AM, Bernhard Kaindl <bk...@su...> wrote:
> Did you get an answer from Dan Dennedy <da...@de...> about including
> the patch?

I see no point in this really because I no longer actively work on
libdv (no one does), it would likely not be released, and it is
redundant with dvgrab. dvgrab already reads dv from stdin and has
several file splitting and file naming options. However, I did not
want to respond immediately with any words of discouragement,  but now
you have put me on the spot ;-). I do strongly suggest adding it to
the SourceForge tracker. Then, if there ever is a new libdv release,
it might get included.

-- 
+-DRD-+

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

[Bernhard K. <bk...@su...>]

On Sat, 28 Jun 2008, Olivier Croquette wrote:
>
> Hi all
>
> Here is the corresponding patch for splitdv, with the man page.
> Comments (or inclusion :)) welcome.
>
> I can't test the integration in the libdv build chain, I still have
> difficulties unterstanding the autotools...

Does not look bad at least. You should be able to test the integration
into the libdv build chain (which uses the GNU autotools) by running
for example these commands in a copy of your changed libdv directory:

libtoolize --copy --force
automake
autoconf
./configure ...
make

This should rebuild the libdv autotools build setup and build libdv
with them. If you get a working splitdv binary from them, at least
the most important basics should be ok.

Did you get an answer from Dan Dennedy <da...@de...> about including
the patch?

About the license, I saw that you agreed to license it under LGPL v2.1
using the same license header as the other C files of libdv:

Bernhard Kaindl wrote:
>Olivier Croquette wrote: 
>> Just to not complicate things for adding one utility, I'd prefer if you would
>> license dvsplit under LGPL v2.1 using the same license header as the other C
>> files use.
>
> Sure, I don't really care.

I just saw that you didn't replace the license header of splitdv.c:

+    dvsplit.c
+
+    Copyright (C) Olivier Croquette, 2008
+
+    This program is free software: you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation, version 3.
+
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+
+    You should have received a copy of the GNU General Public License
+    along with this program.  If not, see <http://www.gnu.org/licenses/>.

The header should look similar to this one (referring to LGPL v2.1):

 *  splitdv.c
 *
 *  Copyright (C) Olivier Croquette, 2008
 *
 *  This file is part of libdv, a free DV (IEC 61834/SMPTE 314M)
 *  codec.
 *
 *  libdv is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU Lesser Public License as published by
 *  the Free Software Foundation; either version 2.1, or (at your
 *  option) any later version.
 *
 *  libdv is distributed in the hope that it will be useful, but
 *  WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Lesser Public License for more details.
 *
 *  You should have received a copy of the GNU Lesser Public License
 *  along with libdv; see the file COPYING.  If not, write to
 *  the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 *  The libdv homepage is http://libdv.sourceforge.net/.

Sourceforge also has a section "patches" (below Tracker) which where
you can publish the final patch using an (free) developer account at
sf.net:

http://sourceforge.net/tracker/?group_id=4393&atid=304393

Bernhard

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

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

Olivier Croquette wrote, On 28/06/08 16:07:
> Here is the corresponding patch for splitdv, with the man page.
> Comments (or inclusion :)) welcome.

Like always, I forgot the attachment.
Here it is.

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

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

Hi all

Here is the corresponding patch for splitdv, with the man page.
Comments (or inclusion :)) welcome.

I can't test the integration in the libdv build chain, I still have 
difficulties unterstanding the autotools...

Best regards

Olivier

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

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

Bernhard Kaindl wrote, On 5/06/08 16:45:
> Just to not complicate things for adding one utility, I'd prefer if you would
> license dvsplit under LGPL v2.1 using the same license header as the other C
> files use.

Sure, I don't really care.

> To make the name consistent with playdv and encodedv, I'd name it splitdv.

OK.

I will try to sort your other recommendations out soon and provide a 
nice patch.

BR

Olivier

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

[Bernhard K. <bk...@su...>]

Hi Olivier,

On Sun, 1 Jun 2008, Olivier Croquette wrote:
> 
> 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

while I can't speak for the authors of libdv, I can give you my perspective as
the maintainer of the libdv package in openSUSE:

libdv C source files (including tools like playdv, excluding man pages, which
are licensed under the GPL) appear to be licensed by using these license header
in the files:

 *  This file is part of libdv, a free DV (IEC 61834/SMPTE 314M)
 *  codec.
 *
 *  libdv is free software; you can redistribute it and/or modify it
 *  under the terms of the GNU Lesser Public License as published by
 *  the Free Software Foundation; either version 2.1, or (at your
 *  option) any later version.
 *   
 *  libdv is distributed in the hope that it will be useful, but
 *  WITHOUT ANY WARRANTY; without even the implied warranty of
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 *  Lesser Public License for more details.
 *   
 *  You should have received a copy of the GNU Lesser Public License
 *  along with libdv; see the file COPYING.  If not, write to
 *  the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. 
 *
 *  The libdv homepage is http://libdv.sourceforge.net/.  

That means the source code of libdv seems to be released under LGPL v2.1
or newer.

The license header which you used uses GPLv3. To your file as is to libdv,
one would have to add the GPLv3 COPYING file as COPYING.GPLv3 and indicate
that dvsplit is licensed under GPLv3 while the rest is LGPL v2.1.

Just to not complicate things for adding one utility, I'd prefer if you would
license dvsplit under LGPL v2.1 using the same license header as the other C
files use.

To make the name consistent with playdv and encodedv, I'd name it splitdv.

It would also be needed to have a manual page for dvsplit/splitdv, you can
likely take e.g. the file playdv.1 as base and copy the entries in
Makefile{,in,am} from playdv.1 to cause that the the autoconf/make
process builds and installs your man page.

If you then create a patch  between the old and the new libdv tree using
'diff -u', people could add it to their libdv builds, and it would make it
also easyer for Dan Dennedy <da...@de...> to add it to the CVS repository
of libdv.

You may want to contact Dan directly if you are unsure wether creating
a man page and an update patch with 'diff -u' which compiles and installs
the tool and its man page is something for you, but I guess it could help,
especially the availability of a man page and using the same license as
the rest of libdv should help.

Bernhard