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: Charles 'B. K. <kr...@ac...> - 2001-01-02 23:31:25
|
Arne Schirmacher <ar...@sc...> writes: > As far as I know some compressed video data of a particular frame > can be stored in the next (or previous?) frame if there is room for > it. No. The "spilling" of bits in DV refers only to units of data within frames. The byte-stream for a frame is divided into units called DIF segments. A DIF segment is a fixed size, 150*80=12000 bytes. NTSC frames contain 10 DIF segments, PAL frames contain 12. Each DIF segment contains 27 video segments. Each video segment contains 5 macroblocks. Each macroblock contains 6 blocks, 4 luma plus 2 chroma. A block is an 8x8 array of video samples. In DV, the space allocated to each unit is a fixed size. If the compressed data doesn't fit, it is allowed to spill, but only upto the level of a video segment. So, if the compressed data for a block does not fit into it's own space, it is allowed to spill over into unused space of other blocks in the same macroblock. If there is no room in the current macroblock, then it is allowed to spill into unused space of other macroblocks in the same video segment. If there is still not enough space, then the data is dropped. This is why the parsing algorithm in libdv makes 3 passes over each video segment. > What happens if I rearrange the frames in my editor program? Would > the decoder attempt to access the spilled bits from the wrong frame? > Maybe we need a clear_spilled_bits() function? No. See above. :) > Arne -- Buck (back from the holidays) |
|
From: Arne S. <ar...@sc...> - 2001-01-02 10:05:50
|
As far as I know some compressed video data of a particular frame can be stored in the next (or previous?) frame if there is room for it. What happens if I rearrange the frames in my editor program? Would the decoder attempt to access the spilled bits from the wrong frame? Maybe we need a clear_spilled_bits() function? Arne |
|
From: Arne S. <ar...@sc...> - 2000-12-29 03:01:01
|
Hi all, I have integrated the dvgrab code with the Kino editor. Download the latest version from http://www.schirmacher.de/arne/kino/ . Kino now has a Capture window which displays whatever is being transmitted by the camcorder at this time. If you hit the "start grabbing" button, the current video data is being saved into an AVI file according to the current settings in the preferences dialog. Arne |
|
From: <no...@so...> - 2000-12-27 00:33:53
|
Patch #103019 has been updated. Project: libdv Category: None Status: Open Submitted by: schlaile Assigned to : nobody Summary: encoder speed up by a factor of 8 ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=103019&group_id=4393 |
|
From: Daniel K. <ko...@ta...> - 2000-12-21 12:56:04
|
On 20 Dec 2000, Charles 'Buck' Krasic wrote: > I made some changes based on the recommendations in there. For > example, I used the name "bootstrap" instead of autogen.sh. I > tightened up some of the dependencies. I added a configure argument > to build a slow version without any of the assembler code, for people > who want maximum quality. Extremely cool. Thanks Buck. Just a small note however. The clean target so far doesn't remove any of the optionally generated files. The following patch works for me, there may well be a cleaner version though. Regards, Daniel. Index: Makefile.am =================================================================== RCS file: /cvsroot/libdv/libdv/Makefile.am,v retrieving revision 1.3 diff -u -r1.3 Makefile.am --- Makefile.am 2000/12/21 04:10:17 1.3 +++ Makefile.am 2000/12/21 12:54:56 @@ -67,4 +67,6 @@ asmoff.h: gasmoff ./gasmoff > asmoff.h -endif \ No newline at end of file +clean-local: + -rm -f $(EXTRA_PROGRAMS) asmoff.h +endif -- GNU/Linux Audio Mechanics - http://www.glame.de Cutting Edge Office - http://www.c10a02.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
|
From: Charles 'B. K. <kr...@ac...> - 2000-12-21 04:27:34
|
I've applied Daniel's patch, combined with a few changes.
I got the NewRiders autotools book:
http://sources.redhat.com/autobook/
I made some changes based on the recommendations in there. For
example, I used the name "bootstrap" instead of autogen.sh. I
tightened up some of the dependencies. I added a configure argument
to build a slow version without any of the assembler code, for people
who want maximum quality.
-- Buck
Daniel Kobras <ko...@ta...> writes:
> To add a few notes:
> As libdv is heading more and more towards a standalone lib, a more
> sophisticated build system is desirable I think. So I did this
> quick&dirty conversion to libtool/automake&friends. It should
> faciliate a boilerplate approach to packaging libdv for various
> distributions.
> I'm not quite sure if I got all the build dependencies right, but at
> least for me it built fine. Furthermore, I'm not certain about what
> headers should be installed as API headers in /usr/include/dv/. For
> now I took playdv's includes as reference, but someone of the main
> developers should be able to adjust the pkginclude_HEADERS line in
> Makefile.am accordingly, I hope.
> If you choose to apply the patch, please run a chmod a+x on
> autogen.sh before committing to CVS, so it gets restore with the
> correct permissions.
> Regards,
> Daniel.
|
|
From: <no...@so...> - 2000-12-21 04:15:53
|
Bug #126562, was updated on 2000-Dec-20 20:15 Here is a current snapshot of the bug. Project: Quasar DV Codec Category: None Status: Open Resolution: None Bug Group: None Priority: 3 Submitted by: krasic Assigned to : nobody Summary: separate mmx from x86 asm Details: At the moment, it is not possible to disable MMX without disabling *all* of the x86 assembly in libdv. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=126562&group_id=4393 |
|
From: <no...@so...> - 2000-12-19 19:12:00
|
Patch #102931 has been updated. Project: libdv Category: None Status: Open Submitted by: schlaile Assigned to : nobody Summary: Make encode.c work again ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102931&group_id=4393 |
|
From: Daniel K. <ko...@ta...> - 2000-12-18 17:19:30
|
On Mon, 18 Dec 2000 no...@so... wrote: > Patch #102908 has been updated. > > Project: libdv > Category: None > Status: Open > Submitted by: nold > Assigned to : nobody > Summary: Fix compile error on mmx.h with gcc 2.95. Lately, there was a thread on gcc 2.95's reluctance to compile mmx.h. This patch fixes the issue. I hope it also fixes it correctly. :-) But as eax is already given as an output register, it should be unnecessary to declare it clobbered, so the change should be okay. 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 |
|
From: Daniel K. <ko...@ta...> - 2000-12-18 17:16:04
|
On Mon, 18 Dec 2000 no...@so... wrote: > Patch #102910 has been updated. > > Project: libdv > Category: None > Status: Open > Submitted by: nold > Assigned to : nobody > Summary: Convert build system to libtool/automake To add a few notes: As libdv is heading more and more towards a standalone lib, a more sophisticated build system is desirable I think. So I did this quick&dirty conversion to libtool/automake&friends. It should faciliate a boilerplate approach to packaging libdv for various distributions. I'm not quite sure if I got all the build dependencies right, but at least for me it built fine. Furthermore, I'm not certain about what headers should be installed as API headers in /usr/include/dv/. For now I took playdv's includes as reference, but someone of the main developers should be able to adjust the pkginclude_HEADERS line in Makefile.am accordingly, I hope. If you choose to apply the patch, please run a chmod a+x on autogen.sh before committing to CVS, so it gets restore with the correct permissions. 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 |
|
From: <no...@so...> - 2000-12-18 16:53:56
|
Patch #102910 has been updated. Project: libdv Category: None Status: Open Submitted by: nold Assigned to : nobody Summary: Convert build system to libtool/automake ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102910&group_id=4393 |
|
From: <no...@so...> - 2000-12-18 16:52:46
|
Patch #102909 has been updated. Project: libdv Category: None Status: Open Submitted by: nold Assigned to : nobody Summary: Fix typo in dv.c ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102909&group_id=4393 |
|
From: <no...@so...> - 2000-12-18 16:52:15
|
Patch #102908 has been updated. Project: libdv Category: None Status: Open Submitted by: nold Assigned to : nobody Summary: Fix compile error on mmx.h with gcc 2.95. ------------------------------------------------------- For more info, visit: http://sourceforge.net/patch/?func=detailpatch&patch_id=102908&group_id=4393 |
|
From: Dan D. <dde...@co...> - 2000-12-12 02:51:52
|
I see. I just read the Changes doc myself and its warnings about gcc 2.95. The no-strict-aliasing flag does nothing to fix the assembler error. The following is from the README.Debian that comes with its gcc package. --- In Debian 2.2 the default C compiler was changed to gcc-2.95.2. That's basically the unreleased and renamed egcs-1.2 compiler (The egcs steering committee was appointed official GNU maintainer for GCC in April 1999; the egcs team will be responsible for rolling out future GCC releases). The old gcc-2.7.2.3 C compiler is still available for compatibility reasons (compilation of 2.0.xx kernels). -- I can find no Debian packages for egcs gcc 2.91. I could build it myself, but I'm not sure what implications that has on some of the standard libraries on my system, and I am not confident about introducing such a major change to my otherwise good working bleeding edge development box. I understand that this is my choice. I wonder, but I have no clue, if there is an intention to move the kernel to supporting gcc 2.95. Otherwise, it must be very difficult for the Debian maintainers to continue with their approach. Even if there is no move toward the new version, then, according to the FAQ topic, mmx.h should still be revised simply as a matter of correctness. Also, I looked for a flag in my version of gcc to not detect an invalid operand clobber specifier. But I can not find one. Stefan Lucke wrote: > > On Don, 07 Dez 2000, Dan Dennedy wrote: > > Stefan wrote: > > > The error message is the same Arne reported. Buck modified mmx.h > > > about two weeks ago. Did you use current snapshot of libdv ? > > > I never got such an error message (K6/2-400, K6/2+-500@550) so this > > > is perhaps compiler/distribution dependent (SuSE 6.3). > Checked my gcc version. It is: > lucke@jarada:~ > gcc -v > Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > >From kernel Documentaion/Changes this is recommended/minimal gcc version. > There is also a hint for gcc 2.95 to use -fno-strict-aliasing. > > > > > I checked out from CVS just last night. I'm running Debian woody (unstable), > > which I upgrade every other week. My gcc is version 2.95.2. > > > > READ THIS gcc FAQ NOTE (Problems with invalid 'asm' statements) --> > > http://gcc.gnu.org/cgi-bin/fom.cgi?_highlightWords=egcs&file=23 > > -- > > mfg > > Stefan Lucke (lu...@sn...) |
|
From: Lukas K. <lu...@ra...> - 2000-12-11 13:03:57
|
Activity seems low on this list recently, and I'll be going soon as well for Christmas. But I still need help on getting these accelerated speeds. Here is a clue from when I play the pond.dv using playdv. [lukas@sto-lknutsson libdv]$ Xlib: extension "XVideo" missing on display ":0.0". Xlib: extension "XVideo" missing on display ":0.0". Using gtk for display Help ! How is encode development getting on ? /Lukas |
|
From: Dan D. <dde...@co...> - 2000-12-07 14:46:41
|
Stefan wrote: > The error message is the same Arne reported. Buck modified mmx.h > about two weeks ago. Did you use current snapshot of libdv ? > I never got such an error message (K6/2-400, K6/2+-500@550) so this > is perhaps compiler/distribution dependent (SuSE 6.3). I checked out from CVS just last night. I'm running Debian woody (unstable), which I upgrade every other week. My gcc is version 2.95.2. READ THIS gcc FAQ NOTE (Problems with invalid 'asm' statements) --> http://gcc.gnu.org/cgi-bin/fom.cgi?_highlightWords=egcs&file=23 +-DRD-+ |
|
From: Dan D. <dde...@co...> - 2000-12-07 14:46:36
|
Stefan wrote: > The error message is the same Arne reported. Buck modified mmx.h > about two weeks ago. Did you use current snapshot of libdv ? > I never got such an error message (K6/2-400, K6/2+-500@550) so this > is perhaps compiler/distribution dependent (SuSE 6.3). I checked out from CVS just last night. I'm running Debian woody (unstable), which I upgrade every other week. My gcc is version 2.95.2. READ THIS gcc FAQ NOTE (Problems with invalid 'asm' statements) --> http://gcc.gnu.org/cgi-bin/fom.cgi?_highlightWords=egcs&file=23 +-DRD-+ |
|
From: Lukas K. <lu...@ra...> - 2000-12-07 09:09:13
|
Could somebody give me advice on how to get RedHat 7 installation running playdv at the accelerated speeds that Arne is reporting. I have a Matrox G200 on an OK P3 566 Mhz machine. Here is a link to my XF86config file, http://zelda.spray.se/~lukas/XF86Config I am confused on whether to turn on or off the extmod section, it is currently commented out. I ain't no X guru so a little help would go a long way. If I make a change to this file, what is the easiest way to restart X when I am in run level 5 ? /Lukas |
|
From: <lu...@sn...> - 2000-12-07 08:32:35
|
> Hi, I'm new here. I have been working with Arne Schirmacher over at > linux1394. > > When I compile libdv with the MMX option on, I receive the following > error in mmx.h: > > mmx.h:213: Invalid `asm' statement: > mmx.h:213: fixed or forbidden register 0 (ax) was spilled for class > AREG. > > I noticed in the list archives that Arne reported the same issue, but I > did not see him post the actual error in a followup message. Has anyone > looked into this? The error message is the same Arne reported. Buck modified mmx.h about two weeks ago. Did you use current snapshot of libdv ? I never got such an error message (K6/2-400, K6/2+-500@550) so this is perhaps compiler/distribution dependent (SuSE 6.3). > > I have an AMD K6-2 333MHz. I have successfully compiled by disabling > MMX. > > I'm working with Arne to improve the display performance of Kino with Xv > support. Your playdv.c is obviously an inspiration. Is SDL worth the > effort? I have heard very mixed opinions about it. Libdv has now SDL and XvImage support buildin (selectable in Makefile). SDL version I got did not compile so I have to search a more recent one. Stefan Lucke Ste...@sn... |
|
From: Dan D. <dde...@co...> - 2000-12-07 06:42:03
|
Hi, I'm new here. I have been working with Arne Schirmacher over at linux1394. When I compile libdv with the MMX option on, I receive the following error in mmx.h: mmx.h:213: Invalid `asm' statement: mmx.h:213: fixed or forbidden register 0 (ax) was spilled for class AREG. I noticed in the list archives that Arne reported the same issue, but I did not see him post the actual error in a followup message. Has anyone looked into this? I have an AMD K6-2 333MHz. I have successfully compiled by disabling MMX. I'm working with Arne to improve the display performance of Kino with Xv support. Your playdv.c is obviously an inspiration. Is SDL worth the effort? I have heard very mixed opinions about it. Thanks for noticing me, +-DRD-+ |
|
From: Stefan L. <lu...@sn...> - 2000-11-27 17:11:50
|
On Mon, 27 Nov 2000, Charles 'Buck' Krasic wrote: > Stefan, > > I just did a commit to CVS. I see some speedup on my machine. Can > you check on yours? I just did my tests and it looks good, speed is back: pond.dv (180 frames - NTSC (6 secs): Displayed 180 frames in 11.4 seconds real 0m11.485s user 0m9.710s sys 0m0.140s mytest.dv (149 frames - PAL (~6 secs): Displayed 149 frames in 12.7 seconds real 0m12.867s user 0m10.540s sys 0m0.110s -- mfg Stefan Lucke (lu...@sn...) |
|
From: Arne S. <ar...@sc...> - 2000-11-27 16:46:01
|
My system is an Asus A7V, AMD Duron 750 running at 950 MHz (rock-solid), a Matrox G200 PCI card, SuSE 6.4 Linux distribution with XFree 4.0 update from their ftp site. -----Original Message----- From: Charles 'Buck' Krasic Sent: Sunday, November 26, 2000 10:40 PM To: Arne Schirmacher Cc: lib...@li... Subject: Re: [libdv-dev] Credits > As an aside, I tried a recent libdv snapshot with hardware support and I > got 45 fps. Cool. Now I need it to slow it down somehow..... Nice! What are the specs of your machine? -- Buck |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-27 00:36:01
|
Stefan, I just did a commit to CVS. I see some speedup on my machine. Can you check on yours? -- Buck |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-26 23:02:27
|
"John A. Griffin" <jag...@ho...> writes: > Dear Mr. Krasic and Mr. Walthinsen, > I am a software developer whose current project is very much > in need of a full-size (720x480) full-speed (30 frames per > second) DV to RGB decoder. > I recently came across your Quasar DV Codec Home Page, and realized > that you were working on such a decoder. You say that you are not > yet at real-time performance, and I have been unable to find any > other source for a real-time decoder. Our rough target has been real-time performance on a 400Mhz PII. This is based on the fact that we know that Canopus' commercial codec, see http://www.canopuscorp.com, does a good job with around 300Mhz class machine. > At this point I am considering writing a decoder of my own. I have > considerable experience in writing optimized assembly language code > on IBM PCs, but I have little if any applicable experience with > video codecs. Answers to the questions below would be of great help > to me in determining the feasibility of the project and getting me > started in the right direction. If either of you could give me some > guidance on these questions it would be much appreciated, and I > would be happy to keep you posted on my progress. As you'll see below, your project may only require piecing together of off-the-shelf code. For your purposes, you may not need to do nearly as much work as you are thinking. However, I would be very glad if you could contribute to improving our code anyway! > Sincerely, > John Griffin > -------------------------------------------------------------- > What computer hardware is currently used to run your decoder? Linux/IA32 machines. We havn't tried other OS's, but they shouldn't be too hard at all. However, getting optimal performance on non IA32 architectures would require a considerable amount of work. > What are your current estimates on the feasibility of achieving > real-time performance on say an 800 MHz Pentium PC with MMX > instruction set assuming that the code is fully optimized and > possibly hand-written in assembly language? In other words, based > on your current experience, do you think there is any chance of my > work succeeding? Short answer: Yes. The libdv decoder should achieve real-time on an 800 MHz machine today. My test machine is only 400 Mhz. Just today, one of our contributors reported 45fps performance with the latest libdv code. Our codec includes a fair amount of hand-tuned assembly, and MMX. More is needed. Especially in the parser. Unlike other codecs, the relatively low compression ratio of DV places large performance pressure on the parsing code. Either that, or I'm doing the parsing in a really stupid way. :-( > You mentioned that developers should obtain a copy of the SMPTE > standard 314M-1999 document. Since I am capturing my video from a > commercial DV camcorder over a FireWire interface, would I also > possibly need either the 321M-1999 (Television - Data Stream Format > for the Exchange of DV-Based Audio, Data and Compressed Video) or > 322M-1999 (Television - Format for Transmission of DV Compressed > Video, Audio and Data Over a Serial Data Transport Interface)? I don't have those other documents, so I don't know. There are certainly people who are already using libdv as part of the process of capturing from commercial camcorders over 1394. Arne Schirmacher's site has lots of good information and relevant links: http://www.schirmacher.de/arne/dvgrab/index_e.html -- Buck |
|
From: Charles 'B. K. <kr...@ac...> - 2000-11-26 22:40:22
|
Arne Schirmacher <ar...@sc...> writes:
> My Kino program contains the libdv code, which form of credits should I
> include? Quasar Codec? Or the names of the programmers? What is the
> complete list?
I think the list in AUTHORS file is correct. It says:
Erik Walthinsen <om...@cs...>
Charles 'Buck' Krasic <kr...@ac...>
Contributors:
James Bowman <ja...@ex...>
Scott F. Johnston <sc...@fl...>
Stefan Lucke <lu...@be...>
I do not think it is necesary to include the list of libdv developers
in the kino program. I'd rather see a link to libdv.sourceforge.net.
I guess I need to make the list of contributors more prominent on that
page.
> As an aside, I tried a recent libdv snapshot with hardware support and I
> got 45 fps. Cool. Now I need it to slow it down somehow.....
Nice! What are the specs of your machine?
-- Buck
|
16 messages has been excluded from this view by a project administrator.
