Menu
▾
▴
libdv-dev
This list is closed, nobody may subscribe to it.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(36) |
May
(15) |
Jun
(7) |
Jul
(8) |
Aug
(15) |
Sep
(3) |
Oct
(2) |
Nov
(59) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(43) |
Feb
(11) |
Mar
(10) |
Apr
(39) |
May
(22) |
Jun
(25) |
Jul
(10) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
(22) |
Dec
(2) |
| 2002 |
Jan
(4) |
Feb
(20) |
Mar
(50) |
Apr
(13) |
May
(39) |
Jun
(36) |
Jul
(14) |
Aug
(16) |
Sep
(3) |
Oct
(23) |
Nov
(34) |
Dec
(16) |
| 2003 |
Jan
(37) |
Feb
(37) |
Mar
(2) |
Apr
(14) |
May
(10) |
Jun
(23) |
Jul
(33) |
Aug
(16) |
Sep
(27) |
Oct
(17) |
Nov
(76) |
Dec
(10) |
| 2004 |
Jan
(89) |
Feb
(13) |
Mar
(13) |
Apr
(14) |
May
(43) |
Jun
(27) |
Jul
(34) |
Aug
(14) |
Sep
(4) |
Oct
(15) |
Nov
(14) |
Dec
(33) |
| 2005 |
Jan
(9) |
Feb
(4) |
Mar
(12) |
Apr
(19) |
May
|
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2006 |
Jan
(3) |
Feb
(4) |
Mar
(7) |
Apr
(11) |
May
(3) |
Jun
(7) |
Jul
|
Aug
(8) |
Sep
(11) |
Oct
(2) |
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(5) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(7) |
Nov
(7) |
Dec
|
| 2008 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
(8) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
(4) |
Nov
|
Dec
(2) |
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Erik W. <om...@te...> - 2006-02-27 21:36:21
|
-------- Original Message --------
Subject: Bug in libdv MMX inline asm
From: Zan Lynx <zl...@ac...>
To: ome...@us...
Date: Mon, 27 Feb 2006 13:58:04 -0700
Testing a new GCC 4.1 beta I discovered that it put one of the global
statics into a register. AMD-64 has a lot of them to use. :)
This caused a build error because the asm code was using memory to
register functions to try to do reg to reg operations.
To fix this, use the memory constraint in the m2r and r2m macros instead
of the X (anything goes) constraint.
Here's a patch (double-check it though, I only saw it build not run):
--- libdv-0.104/libdv/mmx.h 2001-10-27 21:23:57.000000000 -0600
+++ libdv-0.104.patched/libdv/mmx.h 2006-02-27 13:47:20.000000000 -0700
@@ -272,15 +272,15 @@
fprintf(stderr, #op "_m2r(" #mem "=0x%08x%08x, ", \
mmx_trace.d[1], mmx_trace.d[0]); \
__asm__ __volatile__ ("movq %%" #reg ", %0" \
- : "=X" (mmx_trace) \
+ : "=m" (mmx_trace) \
: /* nothing */ ); \
fprintf(stderr, #reg "=0x%08x%08x) => ", \
mmx_trace.d[1], mmx_trace.d[0]); \
__asm__ __volatile__ (#op " %0, %%" #reg \
: /* nothing */ \
- : "X" (mem)); \
+ : "m" (mmx_trace)); \
__asm__ __volatile__ ("movq %%" #reg ", %0" \
- : "=X" (mmx_trace) \
+ : "=m" (mmx_trace) \
: /* nothing */ ); \
fprintf(stderr, #reg "=0x%08x%08x\n", \
mmx_trace.d[1], mmx_trace.d[0]); \
@@ -290,7 +290,7 @@
{ \
mmx_t mmx_trace; \
__asm__ __volatile__ ("movq %%" #reg ", %0" \
- : "=X" (mmx_trace) \
+ : "=m" (mmx_trace) \
: /* nothing */ ); \
fprintf(stderr, #op "_r2m(" #reg "=0x%08x%08x, ", \
mmx_trace.d[1], mmx_trace.d[0]); \
@@ -298,7 +298,7 @@
fprintf(stderr, #mem "=0x%08x%08x) => ", \
mmx_trace.d[1], mmx_trace.d[0]); \
__asm__ __volatile__ (#op " %%" #reg ", %0" \
- : "=X" (mem) \
+ : "=m" (mem) \
: /* nothing */ ); \
mmx_trace = (mem); \
fprintf(stderr, #mem "=0x%08x%08x\n", \
@@ -338,8 +338,8 @@
__asm__ __volatile__ ("movq %0, %%mm0\n\t" \
#op " %1, %%mm0\n\t" \
"movq %%mm0, %0" \
- : "=X" (memd) \
- : "X" (mems)); \
+ : "=m" (memd) \
+ : "m" (mems)); \
mmx_trace = (memd); \
fprintf(stderr, #memd "=0x%08x%08x\n", \
mmx_trace.d[1], mmx_trace.d[0]); \
@@ -358,11 +358,11 @@
#define mmx_m2r(op, mem, reg) \
__asm__ __volatile__ (#op " %0, %%" #reg \
: /* nothing */ \
- : "X" (mem))
+ : "m" (mem))
#define mmx_r2m(op, reg, mem) \
__asm__ __volatile__ (#op " %%" #reg ", %0" \
- : "=X" (mem) \
+ : "=m" (mem) \
: /* nothing */ )
#define mmx_r2r(op, regs, regd) \
@@ -372,8 +372,8 @@
__asm__ __volatile__ ("movq %0, %%mm0\n\t" \
#op " %1, %%mm0\n\t" \
"movq %%mm0, %0" \
- : "=X" (memd) \
- : "X" (mems))
+ : "=m" (memd) \
+ : "m" (mems))
#endif
--
Zan Lynx <zl...@ac...>
|
|
From: Roman S. <rv...@su...> - 2006-02-15 17:40:57
|
On Wed, Feb 15, 2006 at 10:24:49AM +0000, John Emmas wrote: > Hi there, > > I'm interested in looking at the LibDV project to supplement one of the > other projects I'm involved with at SourceForge (AAF). I program for the > Windows Platform (XP & 2000). For a Windows Platform I would definitely recommend looking into FFMpeg project (http://ffmpeg.sourceforge.net/index.php) which has a decent DV codec. I'm not sure whether libdv would be easy to port to win. FFmpeg, however, is available on a wide variety of platforms (including the one you need) already. Thanks, Roman. |
|
From: John E. <jo...@ti...> - 2006-02-15 10:25:15
|
Hi there, I'm interested in looking at the LibDV project to supplement one of the other projects I'm involved with at SourceForge (AAF). I program for the Windows Platform (XP & 2000). Is there a zip file anywhere that I could download to "get me started"? Also, how do I go about joining the project? Thanks, John |
|
From: SourceForge.net <no...@so...> - 2006-01-28 17:51:32
|
Patches item #1417509, was opened at 2006-01-28 12:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1417509&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 Submitted By: Matthew L Daniel (mdaniel) Assigned to: Nobody/Anonymous (nobody) Summary: Follow-up on 1266603 Initial Comment: It seems I can't attach files to someone else's ticket. While patch #1266603 is one way, this is the way Autotools prefer such things to be declared (since "-I..." is not an include subject to dependency tracking, it's a flag). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1417509&group_id=4393 |
|
From: SourceForge.net <no...@so...> - 2006-01-19 17:34:35
|
Bugs item #1410072, was opened at 2006-01-19 17:34 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=1410072&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 Submitted By: jan gerber (qjp) Assigned to: Nobody/Anonymous (nobody) Summary: to many messages indicating an error with audio Initial Comment: trying to use gstreamer to capture dv from a camcorder(JVC | Thomson) i get lots of error messages printed out on the terminal: # audio block/sample failure for 0 blocks, 42 samples of 1920 asf 00:22:16.23 2002-01-10 23:39:30 73 07 02 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 07 04 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 07 05 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 07 08 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 17 02 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 17 04 16 1/36 asf 00:22:16.23 2002-01-10 23:39:30 73 17 05 16 1/36 ... this is a pointless messages, since otherwise can use the camera. the endless output on the temrinal slows down my system though. it would be great if the issue could be solved. otherwise just printing out the error message once and that silencing the output would be better than the current situation. is i can help with solving this issue please let me know.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1410072&group_id=4393 |
|
From: Dan D. <da...@de...> - 2006-01-15 21:11:12
|
On Tuesday 13 December 2005 14:09, pl...@ip... wrote: > This patch calls dv_cleanup() automatically before a dynamic > libdv is unloaded. It is realized with the __attribute__ ((destructor)) > mechanism. I did the same for libquicktime and ffmpeg and got no > single complaint so far. This fixes potential memory leak (>200kB) > when repeatedly loading and unloading libdv. Appled. Better late than never? Thanks. |
|
From: Anders G. <and...@te...> - 2005-12-26 10:33:50
|
Hi!
All applications that use libdv (gstreamer, cinelerra, and libdv's
playdv) display swapped colours on my machine (powerbook Titanium 1 Ghz.
Ati Radeon 9000m .Ubuntu Breezy PPC) when playing raw PAL dv files.
(This only applies to PAL, managed to get hold of some NTSC dv's and
they played with correct colours.. albeit slow)
Searching through your mailing list I noticed there were issues with ATI
cards a couple of years ago so I tried to switch off DRI, playing with
SDL, using the -V switches but the problem persists.
I wonder if xorg's implementation of Xv has changed or...
Playback is also very slow (3-4 fps), what is the expected framerate on
ppc? Building Kino 0.8.0 with --libavcodec works perfectly and so did
using iMovie and other editing apps on OS X.
Is there some hack I can try on libdv?
It would be nice to resolve this issue as I believe most new editing
apps on Linux will use the gstreamer framework (Diva, Pitivi...)
some output from xvinfo:
anders@jupiter:~$ xvinfo
X-Video Extension version 2.2
screen #0
Adaptor #0: "ATI Radeon Video Overlay"
number of ports: 1
port base: 69
operations supported: PutImage
supported visuals:
depth 24, visualID 0x23
depth 24, visualID 0x24
depth 24, visualID 0x25
depth 24, visualID 0x26
depth 24, visualID 0x27
depth 24, visualID 0x28
depth 24, visualID 0x29
depth 24, visualID 0x2a
depth 24, visualID 0x2b
depth 24, visualID 0x2c
depth 24, visualID 0x2d
depth 24, visualID 0x2e
depth 24, visualID 0x2f
depth 24, visualID 0x30
depth 24, visualID 0x31
depth 24, visualID 0x32
number of attributes: 15
"XV_SET_DEFAULTS" (range 0 to 1)
client settable attribute
"XV_AUTOPAINT_COLORKEY" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_COLORKEY" (range 0 to -1)
client settable attribute
client gettable attribute (current value is 30)
"XV_DOUBLE_BUFFER" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 1)
"XV_BRIGHTNESS" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_CONTRAST" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_SATURATION" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_COLOR" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_HUE" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_RED_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_GREEN_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_BLUE_INTENSITY" (range -1000 to 1000)
client settable attribute
client gettable attribute (current value is 0)
"XV_SWITCHCRT" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
"XV_GAMMA" (range 100 to 10000)
client settable attribute
client gettable attribute (current value is 1000)
"XV_COLORSPACE" (range 0 to 1)
client settable attribute
client gettable attribute (current value is 0)
maximum XvImage size: 2048 x 2048
Number of image formats: 4
id: 0x32595559 (2YUY)
guid: 59555932-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x59565955 (YVYU)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (21VY)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (024I)
guid: 49343230-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
|
|
From: <pl...@ip...> - 2005-12-13 22:11:34
|
Hi, This patch calls dv_cleanup() automatically before a dynamic libdv is unloaded. It is realized with the __attribute__ ((destructor)) mechanism. I did the same for libquicktime and ffmpeg and got no single complaint so far. This fixes potential memory leak (>200kB) when repeatedly loading and unloading libdv. Cheers Burkhard |
|
From: SourceForge.net <no...@so...> - 2005-12-10 04:02:38
|
Bugs item #1377536, was opened at 2005-12-09 20:02 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=1377536&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Cann't build libdv rpm under FC4 with fresh install Initial Comment: I looked through the open bug reports on libdv's SourceForge and did not see any mention of the following problem I encountered when attempting to build the libdv rpm. After downloading from CVS the current libdv source I ran $ ./configure $ make $ make distribution with no problem. Attempting to build rpm with # make rpm returned the following error: . . . rpmbuild -ta libdv-0.104.tar.gz error: Legacy syntax is unsupported: copyright error: line 7: Unknown tag: CopyRight: GPL make: *** [rpm] Error 1 # Changing the libdv.spec file's CopyRight: GPL line to License: GPL corrected the problem. I run Fedora Core 4 on a AMD64 machine which currently has rpmbuild Version 4.4.1. I do not know when (what version) of rpmbuild stopped supporting legacy syntax (i.e. CopyRight flag) and began requiring the License flag but this is probably going to become an issue as users/developers begin using newer versions of rpm. Dave ea...@ho... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1377536&group_id=4393 |
|
From: Joshua B. <jd...@jd...> - 2005-10-15 22:51:26
|
I'm having trouble getting dvconnect to work on an IBM R51 laptop running Ubuntu 5.04 connected to a Miranda DV-Bridge+. Previously, I had dvconnect working with the miranda unit on RHEL on another machine. Now, I try this: sudo dvconnect -v -s --device=/dev/video1394/0 ~/SMPTEbars.dv and it prints: VIDEO1394_TALK_WAIT_BUFFER: Bad address jdboyd@jd-mobile:~/dv$ and outputs nothing. The same miranda device connected to a Audigy card in a Shuttle computer running the same version of Ubuntu works just fine, using the SMPTE bars file. Does anyone know what is likely to cause this? I've checked the obvious suspects like non-existant /dev entries and not having the proper modules loaded. -- Joshua D. Boyd jd...@jd... http://www.jdboyd.net/ http://www.joshuaboyd.org/ |
|
From: Dan D. <da...@de...> - 2005-10-05 03:37:38
|
On Tuesday 04 October 2005 06:56 pm, Joshua Boyd wrote: > I'm just trying to get my program to read each frame of pond.dv and toss pond.dv is NTSC format > the results. My basic code looks like this: > #define READ_SIZE 144000 That is the size of a PAL DV frame. The size of an NTSC frame is 120000. > How I know this isn't working correctly is because at the end it prints > 761 instead of 915. (144000 * 716) / 120000 = 913, which is much closer to what you were looking for. > I think the short of my questions are, first how much do I need to read > in each read? isPAL = ( dv_buffer[3] & 0x80 ) size = isPAL ? 144000 : 120000 > Second, how do I know for sure if dv_parse_header and dv_parse_header returns <0 on error > dv_decode_full_frame succeed? dv_decode_full_frame always succeeds given you have supplied adequate size buffers; otherwise, segfault like most C apps. The only failure case for this is visual garbage. > Third, what is the deal with having > pixels be a uchar*pixels[3], then always apparently using only > pixels[0]? The original design intention (forward looking API design) was to support what is called a planar video format where there is a separate buffer for each type of pixel component. The opposite, which you are familiar with, is called "packed" or sometimes "chunky." Alas, planar was never implemented, and we always strive to minimize interface changes. > Also, what is the pitches stuff about? A pitch is the length of one row of image data in the buffer. |
|
From: Joshua B. <jd...@jd...> - 2005-10-05 02:10:30
|
I'm trying to write my first decoding program using libdv. I'm flipping
back and forth between reppm.c and playdv.c.
I'm just trying to get my program to read each frame of pond.dv and toss
the results. My basic code looks like this:
#define READ_SIZE 144000
unsigned char dv_buffer[READ_SIZE];
dv_decoder_t *decoder;
/*I under stand that the application provides the buffer, but I don't
really understand why it needs to be so complicated. The next five
lines are pretty much from reppm.c.*/
unsigned char vb[720*576*3];
unsigned char *pixels[3];
int pitches[3];
pitches[0]=720*3;
pixels[0]=vb;
decoder = dv_decoder_new(TRUE, FALSE, FALSE);
if(!decoder) printf("decoder new failed\n");
if(READ_SIZE!=read(fd, dv_buffer, READ_SIZE))
{
printf("Read failed\n");
close(fd);
return 0;
}
if(dv_parse_header(decoder, dv_buffer)< 0)
printf("header parse error\n");
printf("x: %d y: %d\n", decoder->width, decoder->height);
dv_decode_full_frame(decoder, dv_buffer, e_dv_color_rgb, pixels, pitches);
while(go)
{
if(READ_SIZE==read(fd, dv_buffer, READ_SIZE))
{
printf("test3 %d %d\n", ret, count);
dv_decode_full_frame(decoder, dv_buffer, e_dv_color_rgb,
pixels,
pitches);
count++;
}else go =0;
}
printf("count: %d\n", count);
How I know this isn't working correctly is because at the end it prints
761 instead of 915.
I think the short of my questions are, first how much do I need to read
in each read? Second, how do I know for sure if dv_parse_header and
dv_decode_full_frame succeed? Third, what is the deal with having
pixels be a uchar*pixels[3], then always apparently using only
pixels[0]? Also, what is the pitches stuff about? I think that sums up
my confusion for the moment.
--
Joshua D. Boyd
jd...@jd...
http://www.jdboyd.net/
http://www.joshuaboyd.org/
|
|
From: ScottZ <my...@pi...> - 2005-09-22 21:01:15
|
<div> </div> <div> </div> <div>Is this the correct mailing list for these questions?</div> <div> </div> <div>Is there a forum or IRC channel that would be more appropriate?<BR></div> <div>Thanks,</div> <div>Scott<BR></div> <BLOCKQUOTE style="PADDING-LEFT: 8px; MARGIN-LEFT: 8px; BORDER-LEFT: blue 2px solid"><BR>-------- Original Message --------<BR>Subject: [libdv-dev] a few questions about latest cvs release<BR>From: ScottZ <my...@pi...><BR>Date: Sun, September 18, 2005 10:20 pm<BR>To: lib...@li...<BR><BR>Hello all,<BR><BR>I'm a bit new with libdv, so apologize in advance for my possible<BR>ignorance about the following questions.<BR><BR>I've compiled the latest cvs release on Fedora Core 4 and openSuSE 10<BR>RC1 on an AMD64 3800+ dual core system.<BR>I was curious about the following:<BR><BR>gtk+ and glib<BR><BR>libdv requires gtk+ and glib version 1.2.4 or > and will fail with v2.x<BR>due to lack of glib-config.<BR>Is there no way to make libdv work with the 2.x versions of gtk+ and<BR>glib? <BR>Or is it really that tied in to the v1.2.4+ flavor of these libraries?<BR><BR>playback speed<BR><BR>There was a slow playdv speed issue with AMD64 that had some fixes in<BR>CVS.<BR>Right now with the sample pond.dv and some clips I captured, 1st use of<BR>playdv still has some slow (but not near as bad) playback issues.<BR>Second use of playdv will rip right through any .dv clip as fast as<BR>possible (so it seems)..<BR>What speed is playdv shooting for: Framerate of .dv file or as fast as<BR>possible?<BR><BR>playback with dvconnect<BR><BR>I'm using a Canopus ADVC-110 DV Converter box on firewire. The box has<BR>both Analog in/out and DV in/out and looks like a generic DV camera<BR>device on the firewire. I can capture fine with the box via dvconnect,<BR>but can not seem to be able to playback through the ADVC when using<BR>dvconnect -s file.dv. I'm guessing there's an AVC command needed to do<BR>that? Is that beyond the scope of dvconnect and if so, is there<BR>something else I can use to do this?<BR><BR><BR>Please let me know if you need any more info <BR><BR>Thanks<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR> <BR><BR><BR><BR>-------------------------------------------------------<BR>SF.Net email is sponsored by:<BR>Tame your development challenges with Apache's Geronimo App Server. Download<BR>it for free - -and be entered to win a 42" plasma tv or your very own<BR>Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php<BR>_______________________________________________<BR>libdv-dev mailing list<BR>lib...@li...<BR>https://lists.sourceforge.net/lists/listinfo/libdv-dev </BLOCKQUOTE> |
|
From: ScottZ <my...@pi...> - 2005-09-19 05:20:59
|
Hello all, I'm a bit new with libdv, so apologize in advance for my possible ignorance about the following questions. I've compiled the latest cvs release on Fedora Core 4 and openSuSE 10 RC1 on an AMD64 3800+ dual core system. I was curious about the following: gtk+ and glib libdv requires gtk+ and glib version 1.2.4 or > and will fail with v2.x due to lack of glib-config. Is there no way to make libdv work with the 2.x versions of gtk+ and glib? Or is it really that tied in to the v1.2.4+ flavor of these libraries? playback speed There was a slow playdv speed issue with AMD64 that had some fixes in CVS. Right now with the sample pond.dv and some clips I captured, 1st use of playdv still has some slow (but not near as bad) playback issues. Second use of playdv will rip right through any .dv clip as fast as possible (so it seems).. What speed is playdv shooting for: Framerate of .dv file or as fast as possible? playback with dvconnect I'm using a Canopus ADVC-110 DV Converter box on firewire. The box has both Analog in/out and DV in/out and looks like a generic DV camera device on the firewire. I can capture fine with the box via dvconnect, but can not seem to be able to playback through the ADVC when using dvconnect -s file.dv. I'm guessing there's an AVC command needed to do that? Is that beyond the scope of dvconnect and if so, is there something else I can use to do this? Please let me know if you need any more info Thanks |
|
From: Dan D. <da...@de...> - 2005-08-26 03:41:00
|
On Thursday 25 August 2005 07:26 pm, pl...@ip... wrote: > Hi all, > > I discovered, that dv_cleanup(void) frees all statically allocated memory. > The problem is, that the right time for calling this function cannot be > determined, if we have a modular program (e.g. which does en- and decoding > in multiple threads). Yes, this problem affects MLT as well, but we did something to workaround. Don't ask me the details now because I am in hurry at the moment as I prepare for a move across the country (USA). > - Better solution IMHO: Call dv_cleanup() automatically by a function, > which has __attribute__ ((destructor)). This is a gcc only solution, > but It's portable and works fine in ffmpeg and libquicktime. When I return to normal life, I will see if any objections have been raised before persuing this. Thanks, Burkhard. Keep up the good work as usual! +-DRD-+ |
|
From: <pl...@ip...> - 2005-08-25 23:28:29
|
Hi all, I discovered, that dv_cleanup(void) frees all statically allocated memory= . The problem is, that the right time for calling this function cannot be determined, if we have a modular program (e.g. which does en- and decodin= g in multiple threads). Reference counting isn't always possible, since plugin based apps don't even know, if libdv is used by some plugin or not. Possible solutions are: - Include a reference counter into libdv, which is increased by dv_init() and decreased by dv_cleanup(). Should be thread save ideally. - Better solution IMHO: Call dv_cleanup() automatically by a function, which has __attribute__ ((destructor)). This is a gcc only solution, but It's portable and works fine in ffmpeg and libquicktime. Any thoughts? BTW I use libdv ONLY for extracting the audio samples from a DV frame. Actual decoding is done via libavcodec. If there are better solutions for this task (except libavformat), let me know. I need this for decoding raw DV streams and type 1 DV AVIs, code is here: http://cvs.sourceforge.net/viewcvs.py/gmerlin/gmerlin_avdecoder/lib/dvfra= me.c?rev=3D1.3&view=3Dmarkup Please CC me, I'm not subscribed. Cheers Burkhard |
|
From: SourceForge.net <no...@so...> - 2005-08-22 21:30:31
|
Patches item #1266603, was opened at 2005-08-22 14:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1266603&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 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Build from outside source tree Initial Comment: From be...@br... I prefer to do keep the source tree clean, so why not? It hasn't been tested for every possible build target, but it seems fine for make/make install. make clean still ought to work, but why bother, when one merely has to delete a directory? I'm fairly sure I haven't broken anything. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=304393&aid=1266603&group_id=4393 |
|
From: Pierre D. <pmd...@me...> - 2005-07-05 06:57:47
|
Hi all, I'm not a member of the libdv-dev list, but thought that those who are might be interested in this: http://www-user.rhrk.uni-kl.de/~dittrich/cedocida/index.html It's an open-source encoder / decoder for windows. The thing is, the source is included!! (It is also under gnu) so I thought that you may possibly find some of the code in there usefull to assist in your library?? Pierre -- __________________________________________________________________ Get Firefox! http://www.mozilla.org/products/firefox/ Mr Pierre Dumuid Phd Student Active Noise and Vibration Control Group School of Mechanical Engineering The University of Adelaide SA 5005 AUSTRALIA Email: pie...@ad... pmd...@me... Work: +61 (0)8 8303 3847 Mobile: 0407 570 263 Web Page : http://www.mecheng.adelaide.edu.au/ __________________________________________________________________ CRICOS Provider Number 00123M ----------------------------------------------------------- This email message is intended only for the addressee(s) and contains information that may be confidential and/or copyright. If you are not the intended recipient please notify the sender by reply email and immediately delete this email. Use, disclosure or reproduction of this email by anyone other than the intended recipient(s) is strictly prohibited. No representation is made that this email or any attachments are free of viruses. Virus scanning is recommended and is the responsibility of the recipient. |
|
From: Dan D. <da...@de...> - 2005-06-14 01:31:34
|
DV decoding is quite CPU intensive. It is still not very realistic to decode two DV streams, push them through V4L loopback, do realtime processing, display *and* record to the HDD! However, it can be coded and attemped. Just make sure you use some buffer mechanism in the DV decoder to drop video frames as needed (on overflow of the DV input buffer) to maintain realtime behaviour. Also, you will notice some fair latency compared to your previous experience with uncompressed sources. See libiec61883 from linux1394.org if you want to capture from two DV devices on the same bus. On Sat, 2005-06-11 at 12:31 +0200, Gauthier DELERCE wrote: > Dear all, > > I use to develop acquisition software with libdc or proprietary libs . > > I would develop a small gpl software to a friend, the goal is to connect > n camcorders to firewire boards and be able to output the signal from > one camcorder to output and hard drive. > > This is to mix live record during performance. > > My first idea is to use libdv for in/out and Qt for user interface ; the > basic code would do a live redirection from each camera to /dev/video/n > ; the soft display each source in a small window and the user is able to > select/switch one source to the output. > > This looks quite simple for me and I would have your opinion about this > project > > Further developpement would add transition effects and record every > source to hard disk. > > > Thanks > > Gauthier > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > libdv-dev mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdv-dev |
|
From: Dan D. <da...@de...> - 2005-06-14 01:26:41
|
On Mon, 2005-06-06 at 00:58 -0400, Adam Goldman wrote: > It seems that when dubbing an NTSC stream, dubdv wants to put 1600 audio > samples in each frame. This is way too low. I think the correct number is > more like 48000/30000*1001 =1601.6 samples per frame. This can result in > A/V sync problems. Yes, there is a libdv function to compute the number of samples per frame along a "locked audio" sequence: dv_get_num_samples(). The reason dubdv (and all utilities in encodedv) do not use this and the encoder interface of the library is due to historical reasons. These utilities are not necssaruly the best tools and rarely maintaiined, but remain for historical value and to honor the developer who originally contributed them as well as the libdv encoder. |
|
From: Gauthier D. <gau...@ja...> - 2005-06-11 10:31:55
|
Dear all, I use to develop acquisition software with libdc or proprietary libs . I would develop a small gpl software to a friend, the goal is to connect n camcorders to firewire boards and be able to output the signal from one camcorder to output and hard drive. This is to mix live record during performance. My first idea is to use libdv for in/out and Qt for user interface ; the basic code would do a live redirection from each camera to /dev/video/n ; the soft display each source in a small window and the user is able to select/switch one source to the output. This looks quite simple for me and I would have your opinion about this project Further developpement would add transition effects and record every source to hard disk. Thanks Gauthier |
|
From: Adam G. <ad...@po...> - 2005-06-06 04:58:41
|
It seems that when dubbing an NTSC stream, dubdv wants to put 1600 audio samples in each frame. This is way too low. I think the correct number is more like 48000/30000*1001 =1601.6 samples per frame. This can result in A/V sync problems. -- Adam |
|
From: Jonathan W. <jw...@ph...> - 2005-04-11 03:16:19
|
> > > In general, I agree with the way you did your experiments but: > > > > > > 1. You shouldn't be doing deinterlancing. There are very few > > > tools for that to handle PAL chroma issues correctly. > > > > Um, the only deinterlacing I did was after the (interlaced) DV frame had > > been extracted to a PNG file. This (as mentioned on the web page) used > > ffmeg's decoder via mplayer. The resulting extracted PNG frame was still > > interlaced, so any PAL chroma issues should have been taken care of by the > > DV decoder used. > > Nope. PNG uses RGB color space, while PAL DV operates in YUV420, thus > you need a conversion. And the conversion of PAL chroma is a picky > thing. Ok, to eliminate any possibility (I think) that what we're seeing is related to chroma conversion, I redid some tests over the weekend using YUV-planar as an intermediate format and mjpegtools to handle the chroma conversions. Thanks to Steven Schultz for his helpful tips. Details of these revised tests including command lines can be found towards the bottom of http://www.atrad.com.au/~jwoithe/mpeg/pantest/ Included in the description are links to the files created. The practical upshot is that the field shadows appear in the output from these tests in exactly the same was as they did when mplayer was used to extract the frames. Unless there has been another error in the test method, this would indicate that the shadowing effects are not related to chroma sampling effects. Note that I also repeated the test on libdv-encoded footage, again with the same results as obtained previously. > ... the correct sequence of steps to get a truly telling result would > be: > > 1. Extract to YUV4MPEG (make sure it's labeled as PAL). > 2. Use the deinterlacer from the mjpeg tools. This is what I have done (I think). > > The other thing to note is that these artifacts are not present in the raw > > footage. > > Interesting. Could you post a sample of that raw footage somewhere for > me to play with ? http://www.atrad.com.au/~jwoithe/mpeg/pantest/straight_copy.mov For completeness it's also linked as the source for straight_copy.m2v at the top of http://www.atrad.com.au/~jwoithe/mpeg/pantest/ I didn't get a chance to use ffmpeg's DV decoder in a DV->MPEG2 over the weekend; I'll try to get to that during the week. Suffice to say that even when my current libdv-based DV decoder is used as described in a previous post, straight_copy.mov shows no artifacts on the DVD player (or in extracted frames on the PC) whereas the same source encoded with libdv before DV->MPEG2 conversion does. Regards jonathan |
|
From: Steven M. S. <sm...@2B...> - 2005-04-08 00:54:30
|
On Fri, 8 Apr 2005, Jonathan Woithe wrote: > From DV to MPEG2 I use tools only from mjpegtools. These do of course use > libdv's decoder. I haven't as yet had time to work out how to get ffmpeg > into the pipeline - I'll see if time allows such experiments over the The way I use ffmpeg's dv decoder is to build the smilutils against ffmpeg/libavcodec (in the smilutils configure it's "--with-avcodec --with-avcodec-include=yourdirectorytolibavcode"). smilutils is on the Kino site somewhere as I recall (I checked it out from cvs ':pserver:ano...@cv...:/cvsroot/kino' and project/module 'smilutils'). By default smilutils builds with libdv but it can also work with ffmpeg/libavcodec > weekend. Anyway, given a DV stream (in a QT container, but that's not > relevant for this), the process at its simplest form is > > lav2yuv foo.mov | mpeg2enc -f 8 -q 6 -N 0.5 -E -10 -c -s \ ^lav2yuv^smil2yuv^ > were foo.mov is a raw DV stream encapsulated in a Quicktime file. My preference is for 'raw DV' - makes using 'dd' as a poor man's editor trivial (fixed record size) and less overhead. > I haven't yet had a chance to look into how one could use ffmpeg to do the > DV->YUV4MPEG conversion - it's another thing for the weekend. Based on the ffmpeg can produce raw 420planar data - once you have that then the little utility from mjpegtools called 'yuv4mpeg' can be used to put the YUV4MPEG2 headers/framemarkers in. > of difference. As far as the decoders go, ffmpeg and libdv seem (at first > glance anyway) to give equivalent output. When I switched from libdv to smilutil+libavcodec/dv the average bitrate of the final MPEG-2 file was 10-15% *lower* (and ALL other parameters/programs in the pipeline were the same). Your mileage may vary of course. Cheers, Steven Schultz |
|
From: Jonathan W. <jw...@ph...> - 2005-04-08 00:29:12
|
> > Um, the only deinterlacing I did was after the (interlaced) DV frame had
> > been extracted to a PNG file. This (as mentioned on the web page) used
> > ffmeg's decoder via mplayer. The resulting extracted PNG frame was still
> > interlaced, so any PAL chroma issues should have been taken care of by the
> > DV decoder used.
>
> Nope. PNG uses RGB color space, while PAL DV operates in YUV420, thus
> you need a conversion. And the conversion of PAL chroma is a picky
> thing.
Yes, I understand that (I think). What puzzles me a bit though is that in
the toolchain I used for this, mplayer (using ffmpeg's DV codec) was
responsible for writing the extracted (interlaced) frame in PNG format from
the raw DV stream:
mplayer -vo png -z 9 foo.dv
Therefore, any necessary colourspace conversions were handled by
mplayer/ffmpeg. Assuming this is true, if there is a chroma problem in
these extracted images it must therefore mean that the colourspace
conversion in mplayer/libavcodec doesn't get it right. In principle at
least, mplayer should be capable of extracting a (interlaced) frame
(interlaced YUV420), doing YUV420->RGB conversion (giving interlaced RGB)
and writing the resulting frame out to some format. The accuracy of the
conversion would be limited to mplayer's algorithm and the internal image
formats used by mplayer - the actual output format shouldn't come into it.
> Unfortunately, you can't really tell whether you've got artifacts from
> the colorpsace conversion or from the decoder. That's the reason I recommend
> using YUV4MPEG.
Ok, so from all this I take it that the conversion is not supplied by libdv
and that therefore it's possible that the conversion in mplayer isn't up to
scratch when considering these artifacts?
> the correct sequence of steps to get a truly telling result would be:
>
> 1. Extract to YUV4MPEG (make sure it's labeled as PAL).
> 2. Use the deinterlacer from the mjpeg tools.
For completeness I'll try this over the weekend.
> > With this supposed correct handling of chroma, the DVD player shows
> > exactly the field shadow artifacts which are illustrated in the PNG
> > files I mentioned.
>
> Hm. That is interesting. Could you show us the full command line you use
> to go from DV to MPEG2 using ffmpeg and mjpegtools ?
From DV to MPEG2 I use tools only from mjpegtools. These do of course use
libdv's decoder. I haven't as yet had time to work out how to get ffmpeg
into the pipeline - I'll see if time allows such experiments over the
weekend. Anyway, given a DV stream (in a QT container, but that's not
relevant for this), the process at its simplest form is
lav2yuv foo.mov | mpeg2enc -f 8 -q 6 -N 0.5 -E -10 -c -s \
--no-dualprime-mpeg2 -D 10 -o foo.m2v
were foo.mov is a raw DV stream encapsulated in a Quicktime file.
If foo.mov is raw footage captured directly from a camera using dvgrab (ie:
having undergone *no* processing on the computer at all), movement on the
resulting DVD is smooth with no field shadows appearing in the frames.
Extracting frames to PNG from such a file using mplayer as described
elsewhere similarly shows no field shadow artifacts. If, however, foo.mov is
the same footage but run through a libdv decode/encode cycle the movement on
the DVD is not smooth and frames (both extracted on the computer and on the
DVD) display the field shadows.
As an aside, based on other tests I've done I would expect that the footage,
after run through the ffmpeg encoder, will look better on the DVD than that
encoded with libdv but that there will still be issues. I'll try to confirm
this over the weekend.
I haven't yet had a chance to look into how one could use ffmpeg to do the
DV->YUV4MPEG conversion - it's another thing for the weekend. Based on the
results of my earlier tests though I don't expect this to make a great deal
of difference. As far as the decoders go, ffmpeg and libdv seem (at first
glance anyway) to give equivalent output.
> > The other thing to note is that these artifacts are not present in the raw
> > footage.
>
> Interesting. Could you post a sample of that raw footage somewhere for
> me to play with ?
The webpage has a bz2 tarball of a series of still interlaced CGI PNG images
which comprise one of my test cases (the logo*.png files mentioned on the
website). That is available now - see the link to still_pngs.tar.bz2 on
http://www.atrad.com.au/~jwoithe/mpeg/
Unfortunately I don't have the raw camera DV footage with me today - I'll
bring it with me on Monday and advise when it's available.
Regards
jonathan
|
16 messages has been excluded from this view by a project administrator.
