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: <no...@so...> - 2001-04-28 23:41:44
|
Bugs item #419875, was updated on 2001-04-28 16:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=419875&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: YUV still overloading the lookup tables Initial Comment: In YUY2.c the Ytmp and cbcr_frame values still overload the lookup tables and produce artifacts when decompressing car break lights and fluorescent signs at night. The artifacts are very difficult to see unless you watch the video in fullscreen. Also the lookup tables seem to clamp between 16 and 240. Camcorders store information in these super black and super white regions which videographers often need for color correction and rounding. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=419875&group_id=4393 |
|
From: Dan D. <dde...@co...> - 2001-04-28 09:59:59
|
Hi all, I was building the newest libdv today--both the recent tarball and a CVS update. As noted in an outstanding patch from Daniel Kobras, libdv/headers.c is missing the "#include <time.h>." I too had to add this to compile, but Daniel's patch is dated Mar 20. Are you still overlooking that? Or is there something in particular with our system headers (<sys/time.h>) that causes it? I am running Debian Sid (bleeding edge). +-DRD-+ |
|
From: <pin...@ya...> - 2001-04-28 06:48:37
|
I get the following errors when trying to build this release under RedHat 6.1 on a K6-2 gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -I . -I .. -Wall -O2 -g -I/usr/lib/glib/include -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/include/SDL -D_REENTRANT -c encode_x86.S -o encode_x86.o /tmp/ccutH2Ls.s: Assembler messages: /tmp/ccutH2Ls.s:76: Error: operands given don't match any known 386 instruction /tmp/ccutH2Ls.s:144: Error: operands given don't match any known 386 instruction Any ideas.. I have tried to build with configure --disable-asm but I get other error messages then Steve ===== -- If you listen very carefully you can sometimes hear the dolphins sing pin...@ya... ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie |
|
From: Daniel K. <ko...@ta...> - 2001-04-27 07:21:54
|
Moi Charles! On Thu, Apr 26, 2001 at 12:34:29PM -0700, Charles 'Buck' Krasic wrote: > Heads up to developers: I've re-organized the source tree! > > There are now subdirectories for libdv, playdv, and encodedv. Looks like a few binaries slipped into the repository during the merge. Was this intentional? That's encodedv/scan_packet_headers, libdv/dovlc, libdv/testbitstream, and libdv/testvlc. Oh, and there's still a dv.c in top-level. Looks like it should get removed as well. Regards, Daniel. |
|
From: Charles 'B. K. <kr...@ac...> - 2001-04-26 19:34:32
|
I've just cut the 0.8 release. Heads up to developers: I've re-organized the source tree! There are now subdirectories for libdv, playdv, and encodedv. This helps a lot with include file handling and autotools. Makefile.vanilla is broken by this. -- Buck |
|
From: <pin...@ya...> - 2001-04-23 21:46:05
|
Haven't got round to upgrading my RedHat install yet, but I am running the 2.2.19 kernel with iee1394 support patched in. My problem is I can't install your RPMS due to wrong libraries so I tried building from source and the make dies on encode_x86.S reporting that it contains illegal x86 instructions.. Which version of gcc do I need to be running to build this? Thanks Steve ===== -- If you listen very carefully you can sometimes hear the dolphins sing pin...@ya... ____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie |
|
From: Christoph S. <ch...@ne...> - 2001-04-20 21:24:03
|
> > > As for YUV422 - I think the mjpeg tools should work with this. At least > > > the main change I made some time ago to support JPEG from bttv capture was > > > to make things work with YUV422 JPEG. You'll need to have a hunt around > > > inside the mjpeg lib and/or the io libraries if it doesn't work. The > > > biggest likelihood is simply that the YUV422/YUV420 info is getting lost > > > somewhere. > > Support for YUV422 would be really good since that is now the default output > > format from libdv for all DV formats (YUV 420 and 411 are upsampled) and it > > NO. libdv does no upsampling. Color information is just repeated. A common planar > output format for post processing would be very useful. Thanks for pointing that out with the repeated color information. Is there anybody working on providing a common planar YUV output format for libdv? It is pretty straightforward to reorder the data, but it would be nicer if the library would already provide a call that returns planar data for post-processing even if the planar format is slower when passed to video cards through Xv. I guess that would also give better performance than an additional reordering step to go from packed -> planar. > Interlacing: > Some DV camcorders are able to record progressive mode sequences at full > frame rate. If this information is useful for encoding in into other formats > it is possible to provide this information per frame. An example for > progressive mode recording is pond.dv . I think that would be very convenient to have that information since mpeg2enc already has options for progressive or field based MPEG 2 output. Would it be possible to pass this information through the stream? Or is there a general problem with switching between interlace modes while encoding MPEG? Christoph ------------------------------------------------------------------------------ Christoph Scheurer e-mail: ch...@fe... Department of Chemistry WWW: http://markov.chem.rochester.edu/chris University of Rochester P.O. Box RC 270216 phone: +1-716-275-8289 Rochester, NY 14627-0216 +1-716-242-0989 (private) USA Fax: +1-716-473-6889 ------------------------------------------------------------------------------ GnuPG public key: http://markov.chem.rochester.edu/chris/key.html |
|
From: Stefan L. <Ste...@sn...> - 2001-04-20 18:37:10
|
On Fre, 20 Apr 2001, Christoph Scheurer wrote: > Date: Fri, 20 Apr 2001 08:29:44 -0400 > To: mjp...@li... > Subject: Re: [Mjpeg-users] yuv2lav problem and NTSC DV decoding > From: Christoph Scheurer <ch...@ne...> > Reply-To: mjp...@li... > > > As for YUV422 - I think the mjpeg tools should work with this. At least > > the main change I made some time ago to support JPEG from bttv capture was > > to make things work with YUV422 JPEG. You'll need to have a hunt around > > inside the mjpeg lib and/or the io libraries if it doesn't work. The > > biggest likelihood is simply that the YUV422/YUV420 info is getting lost > > somewhere. > Support for YUV422 would be really good since that is now the default output > format from libdv for all DV formats (YUV 420 and 411 are upsampled) and it NO. libdv does no upsampling. Color information is just repeated. A common planar output format for post processing would be very useful. Interlacing: Some DV camcorders are able to record progressive mode sequences at full frame rate. If this information is useful for encoding in into other formats it is possible to provide this information per frame. An example for progressive mode recording is pond.dv . > would mean that it wouldn't be necessary to compile libdv with a special > configure flag to support planar YUV 420. > > But, if I understand it right, you mean planar YUV 422? Or can I also send > packed YUV 422 through a YUV4MPEG pipe? I think by accident I used packed YUV > 422 in the beginning, when I starte using libdv and the results from mpeg2enc > were bright green and scrambled. So I would just have to reorder packed -> > planar, which is simple enough. And how do I tell the receiver of the > YUV4MPEG data that the stream is 422 not 420? Or do the tools autodetect that > by the size? > -- mfg Stefan Lucke (Ste...@sn...) |
|
From: <no...@so...> - 2001-04-20 09:34:34
|
Bugs item #417583, was updated on 2001-04-20 02:34 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=417583&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: OSS audio output breaks on big-endian. Initial Comment: oss.c/rev 1.5 changed the audio format to use from native to little endianness. The sanity check still tests for native endianness. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=417583&group_id=4393 |
|
From: <no...@so...> - 2001-04-20 08:57:11
|
Bugs item #417569, was updated on 2001-04-20 01:57 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=417569&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: encode.c uses MMX on non-x86. Initial Comment: encode.c pulls in MMX headers unconditionally, which obviously blows up the build process on non-x86 archs. Fix is to wrap #include "mmx.h" in #if ARCH_X86. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=104393&aid=417569&group_id=4393 |
|
From: Christoph S. <ch...@ne...> - 2001-04-19 17:34:01
|
Hello, I am looking for an NTSC DV file in 'Type 2' DV AVI format. It needs to be only a few frames long so I can test my program. Does anybody have such a file or can anybody tell me where I can download one? The NTSC files on the ftp site of libdv.sourceforge.net all seem to be the raw DV data and I don't have a tool to convert them to AVI format. Thanks, Christoph ------------------------------------------------------------------------------ Christoph Scheurer e-mail: ch...@fe... Department of Chemistry WWW: http://markov.chem.rochester.edu/chris University of Rochester P.O. Box RC 270216 phone: +1-716-275-8289 Rochester, NY 14627-0216 +1-716-242-0989 (private) USA Fax: +1-716-473-6889 ------------------------------------------------------------------------------ GnuPG public key: http://markov.chem.rochester.edu/chris/key.html |
|
From: Christoph S. <ch...@ne...> - 2001-04-18 20:10:58
|
On Wed, Apr 18, 2001 at 09:19:49PM +0200, Stefan Lucke wrote: > On Mit, 18 Apr 2001, Christoph Scheurer wrote: > > Hello, > > > > My first e-mail about my PAL -> YUV 4:2:0 conversion problems with libdv-0.7 > > was probably a little cryptic. > YUV output format of libdv is probably not that one, other encoders > expect. By default libdv will produce packed 422 for NTSC and PAL > source (4CC 0x32595559). For PAL there is an optional compile time > format available (4CC 0x32315659) 420 planar. That is what some > encoders prefer. > Some time ago, we set that output format as the default, which processed > fastest by Xv. Thanks! That solved the problem for the MPEG encoding which wants 420 planar and, as I just found out, also the U and V arrays just in the reverse order from how libdv produces them. I will have to check whether that also solves the problem with kino (I assume so). What surprises me is that my r128 card with Xv didn't like the YUV 422. Or do I have to tell Xv what kind of YUV format it has to expect? Christoph ------------------------------------------------------------------------------ Christoph Scheurer e-mail: ch...@fe... Department of Chemistry WWW: http://markov.chem.rochester.edu/chris University of Rochester P.O. Box RC 270216 phone: +1-716-275-8289 Rochester, NY 14627-0216 +1-716-242-0989 (private) USA Fax: +1-716-473-6889 ------------------------------------------------------------------------------ GnuPG public key: http://markov.chem.rochester.edu/chris/key.html |
|
From: Stefan L. <Ste...@sn...> - 2001-04-18 19:43:14
|
On Mit, 18 Apr 2001, Christoph Scheurer wrote: > Hello, > > My first e-mail about my PAL -> YUV 4:2:0 conversion problems with libdv-0.7 > was probably a little cryptic. YUV output format of libdv is probably not that one, other encoders expect. By default libdv will produce packed 422 for NTSC and PAL source (4CC 0x32595559). For PAL there is an optional compile time format available (4CC 0x32315659) 420 planar. That is what some encoders prefer. Some time ago, we set that output format as the default, which processed fastest by Xv. -- mfg Stefan Lucke (Ste...@sn...) |
|
From: Christoph S. <ch...@ne...> - 2001-04-18 15:44:46
|
Hello,
My first e-mail about my PAL -> YUV 4:2:0 conversion problems with libdv-0.7
was probably a little cryptic.
This is the kind of code I use to decode the DV frame:
static dv_decoder_t *decoder;
guint16 pitches[3];
unsigned char *frame[3]
static unsigned char dv_data[512*1024];
...
allocate memory for frame
...
decoder = dv_decoder_new();
dv_init();
decoder->quality = DV_QUALITY_BEST;
...
read dv_data from AVI file
...
dv_parse_header(decoder, dv_data);
switch(decoder->sampling) {
case e_dv_sample_420:
pitches[0] = decoder->width;
pitches[1] = decoder->width / 2;
pitches[2] = decoder->width / 2;
res = dv_decode_full_frame(decoder, dv_data, e_dv_color_yuv,
(guchar **) frame, pitches);
break;
default:
break;
}
I also prepared two 5 second MPEG-1 sequences (VCD compatible video streams)
that show the correct output using RGB decoding of the DV data (through
dv2jpg) and the result I get using YUV decoding or Xv output in kino-0.4. The
files are about 700K each and you can download them from
http://markov.chem.rochester.edu/chris/dv_tst.mpg
http://markov.chem.rochester.edu/chris/dv_tst_correct.mpg
The setup I am using is Debian woody and XFree 4.0.2 with the Xv patch from
Gatos for my r128 video card (Xpert2000).
Thanks in advance,
Christoph
------------------------------------------------------------------------------
Christoph Scheurer e-mail: ch...@fe...
Department of Chemistry WWW: http://markov.chem.rochester.edu/chris
University of Rochester
P.O. Box RC 270216 phone: +1-716-275-8289
Rochester, NY 14627-0216 +1-716-242-0989 (private)
USA Fax: +1-716-473-6889
------------------------------------------------------------------------------
GnuPG public key: http://markov.chem.rochester.edu/chris/key.html
|
|
From: Christoph S. <ch...@ne...> - 2001-04-18 01:11:31
|
Hello, I tried to get YUV output from my PAL DV source but the picture I get is scrambled and bright green. The DV file was recorded with a Sony DVR-320E Digital-8 camcorder and transferred using dvgrab. I used libdv-0.7 to decode the frames and I wrote them in the YUV4MPEG format that is used by mpeg2enc from the MJPEG project (on sourceforge). The resulting output is bright green and scrambled. When I use dv2jpg (also on sourceforge) and go through MJPEG encoding in between, everything looks fine. I looked at dv2jpg and noticed that it uses RGB decoding from libdv. When I use kino-0.4 to look at the file everything is o.k. as long as I don't use Xv as output option. With Xv I get exactly the same wrong output (green, scrambled). I took a look at the libdv-dev archive but all the messages I found that related to YUV were from last year and it seemed that they were fixed in the meantime. I have the impression the problem is related to YUV decoding but I don't see what is going wrong. Any help is appreciated, Christoph ------------------------------------------------------------------------------ Christoph Scheurer e-mail: ch...@fe... Department of Chemistry WWW: http://markov.chem.rochester.edu/chris University of Rochester P.O. Box RC 270216 phone: +1-716-275-8289 Rochester, NY 14627-0216 +1-716-242-0989 (private) USA Fax: +1-716-473-6889 ------------------------------------------------------------------------------ GnuPG public key: http://markov.chem.rochester.edu/chris/key.html |
|
From: <no...@so...> - 2001-04-17 22:17:20
|
Patches item #416864, was updated on 2001-04-17 15:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=416864&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Schlaile (schlaile) Assigned to: Nobody/Anonymous (nobody) Summary: better dct 88 / 248 distinct. bug fixes Initial Comment: * Removed "bttv bug work around". It was my VIA board... * Changed DV_WIDTH in rgbtoyuv to make things more clear and compile on more platforms * need_dct_248 now uses the ratio between field error and error in x-direction. Hopefully fixes encoding of cartoons with hard edges. * --force-dct added. Just in case. * Added updated man page for encodedv ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=416864&group_id=4393 |
|
From: Alastair M. <aj...@ca...> - 2001-04-17 21:13:52
|
Hi, and apologies for cross-posting. The BackFire project -- to develop an app to allow file backup to digital (DV, D8) camcorders -- is being revived. A year ago when I first started, we couldn't yet write data back to the camcorder so the project sort of fizzled. That's changed (yay!, and thanks to those of you who made that happen), and it's time to apply the defibrillator paddles to BackFire and try to revive it. Backfire is now hosted on SourceForge (http://sourceforge.net/projects/backfire/) which I hope will encourage others to participate. It's just been created so there's not much up yet but a copy of the old web page and a brand new mailing list. I'll upload design notes and what meager code I have soon. Cheers, -- Alastair |
|
From: Stefan L. <Ste...@sn...> - 2001-04-13 21:26:16
|
On Don, 12 Apr 2001, Arne Schirmacher wrote: > If there were two versions of libdv, I would always use the faster one. If the shared lib would be slower, I would probably not use it. Performance for libdv is really a major issue, but not the only one. To my opinion a thread safe version has higher priority (implies PIC :-) ). So I don't know what else is required get PIC ready code, but it is easy to convert local variables of vlc_x86.S (m, mb_start, n_blocks) which are written and read, to stack variables. Other ones like (blk_start,mod_10, mod_12, const_f_0_0_0) are, when my understanding is right, read only. vlc is a write only one. Attached patch is stacked on previous patch for libdv segfaults. > > Arne > > > -----Original Message----- > From: Daniel Kobras > Sent: Tuesday, April 10, 2001 6:01 PM > To: lib...@li... > Subject: Re: [libdv-dev] Lib status of libdv. > > ... > > case, too. The alternative being two completely seperate version for static > and shared linkage. What's your opinion on this? Do you consider it > worthwhile for libdv to be available as a shared lib at all? > > Regards, > > Daniel. > > -- > GNU/Linux Audio Mechanics - http://www.glame.de > Cutting Edge Office - http://www.c10a02.de > GPG Key ID 89BF7E2B - http://www.keyserver.net > << File: ATT00001.att >> > > _______________________________________________ > libdv-dev mailing list > lib...@li... > http://lists.sourceforge.net/lists/listinfo/libdv-dev -- mfg Stefan Lucke (Ste...@sn...) |
|
From: Daniel K. <ko...@ta...> - 2001-04-12 19:54:48
|
On Tue, Apr 10, 2001 at 10:31:21AM -0700, Charles 'Buck' Krasic wrote: > In linux, shared libraries are mapped into process space with > copy-on-write. If your shared-library doesn't use pic, then a process > using the library will not achieve any *memory* sharing benefit, > because the shared library loader touches all places with absolute > references which in turn triggers copy-on-write page faults for all > the pages of the library. You still get the disk space sharing > benefit, and you get potentially a run-time performance benefit (over > pic) for CPU intensive code (i.e. libdv). Umm..., as far as I understood, the ELF loader wasn't capable of performing such global relocations without the help of a compile-time generated table, but then this really isn't the area I feel competent in... > I don't think it's worth the trouble to make a PIC version of libdv. > We work so hard to get performance, why through it back for PIC? =20 Well, there's the much greater ease of maintainance with shared libs-- no need to recompile all your apps when the lib has been updated, but the performance argument is one I very much tend to agree with. At least now. Maybe it's time to raise this issue again when we're all running 10 GHz machines that decode DV for breakfast. (Another issue for me is Debian policy that requires a shared version of each lib that is packaged, but I might get permitted an exception here.) > ps I'd be very happy if you make a Debian package for libdv. I've > been a RedHat user for a long time, so I'm not equipped to do it > myself. Debian packages for the current unstable tree are available from http://antares.tat.physik.uni-tuebingen.de/~kobras/debian/ (sorry, too lazy now to make it apt-able). Once the policy issue is agreed upon, I intend to include them into the main distribution. I've submitted all non-Debian-specific patches to SourceForge's patch tracker already. Best regards, Daniel. --=20 GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
|
From: <no...@so...> - 2001-04-12 19:26:21
|
Patches item #415746, was updated on 2001-04-12 12:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415746&group_id=4393 Category: None Group: None Status: Open Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: Man page for encodedv. Initial Comment: And here for encodedv's man page. (Sourceforge lets you attach only a single file...) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415746&group_id=4393 |
|
From: <no...@so...> - 2001-04-12 19:25:22
|
Patches item #415745, was updated on 2001-04-12 12:25 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415745&group_id=4393 Category: None Group: None Status: Open Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: Man page for playdv. Initial Comment: Debian policy mandates that each executable has to be documented via a man page. Therefore I took the help output of playdv and (the already renamed) encodedv and worked from there to compile man pages for both programs. Here's the playdv part. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415745&group_id=4393 |
|
From: <no...@so...> - 2001-04-12 19:21:59
|
Patches item #415742, was updated on 2001-04-12 12:21 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415742&group_id=4393 Category: None Group: None Status: Open Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: Changing encode to encodedv. Initial Comment: The naming of 'encode' is a bit unfortunate in my opinion as it is not the only program under the moon that is likely to encode something. To avoid possible name clashes and give the users more of a clue as to what the program actually does, I renamed the executable to encodedv. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415742&group_id=4393 |
|
From: <no...@so...> - 2001-04-12 19:19:14
|
Patches item #415740, was updated on 2001-04-12 12:19 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415740&group_id=4393 Category: None Group: None Status: Open Priority: 5 Submitted By: Daniel Kobras (nold) Assigned to: Nobody/Anonymous (nobody) Summary: Bogus space in option string. Initial Comment: Option 'video system' in dv.c contains a bogus space. Changed to 'video-system'. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=304393&aid=415740&group_id=4393 |
|
From: Arne S. <ar...@sc...> - 2001-04-12 17:41:49
|
If there were two versions of libdv, I would always use the faster one. If the shared lib would be slower, I would probably not use it. Arne -----Original Message----- From: Daniel Kobras Sent: Tuesday, April 10, 2001 6:01 PM To: lib...@li... Subject: Re: [libdv-dev] Lib status of libdv. ... case, too. The alternative being two completely seperate version for static and shared linkage. What's your opinion on this? Do you consider it worthwhile for libdv to be available as a shared lib at all? Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net << File: ATT00001.att >> |
|
From: Charles 'B. K. <kr...@ac...> - 2001-04-10 17:31:28
|
I havn't looked into this myself for some time, but... I believe the PIC requirement for shared-libraries is not so clearly explained in the documents I've read. Specifically, the libtool documentation seems to imply that you must use PIC if you want to generate a shared library. As far as I know, this is is libtool specific, but not true for linux in general. In linux, shared libraries are mapped into process space with copy-on-write. If your shared-library doesn't use pic, then a process using the library will not achieve any *memory* sharing benefit, because the shared library loader touches all places with absolute references which in turn triggers copy-on-write page faults for all the pages of the library. You still get the disk space sharing benefit, and you get potentially a run-time performance benefit (over pic) for CPU intensive code (i.e. libdv). I havn't verified it for myself, but in reading the release notes for the latest version of libtool (1.3d), it appears that they may finally support generating shared-libraries without PIC (--prefer-non-pic). I don't think it's worth the trouble to make a PIC version of libdv. We work so hard to get performance, why through it back for PIC? I don't think it's a big requirement to support a shared library either. Libdv is not that large after all. But, if the new version of libtool gives us the capability for little effort, then why not. -- Buck ps I'd be very happy if you make a Debian package for libdv. I've been a RedHat user for a long time, so I'm not equipped to do it myself. Daniel Kobras <ko...@ta...> writes: > [Replying to a really ancient mail.] > I've tried to compile a sane Debian package of libdv for some time now, > and actually building libdv as a shared lib turns out to be quite a > problem, at least as far as the optimised versions are concerned. That's > because the asm routines are not coded to be relocatable. Changing this > basically involves sacrificing a register to the global offset table > and changing every reference to objects in the .data section when > __PIC__ is defined. > In detail, it appears that quant_x86.S transpose_x86.S are already fine > because they do not contain .data sections. dct_block_mmx.S, encode_x86.S, > idct_block_mmx.S appear to be trivially fixable, which leaves > rgbtoyuv.S and vlc_x86.S as the hard cases. Both make heavy uses of > registers and local data alike. Therefore, a straightforward approach > to code them relocatable might well affect performance in the static > case, too. The alternative being two completely seperate version for static > and shared linkage. What's your opinion on this? Do you consider it > worthwhile for libdv to be available as a shared lib at all? > Regards, > Daniel. |
16 messages has been excluded from this view by a project administrator.
