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: Daniel K. <ko...@li...> - 2006-06-25 11:31:44
|
On Sun, Jun 25, 2006 at 03:45:25AM -0400, Mike Frysinger wrote: > simple patch ... if some autotool fails, abort the script, dont just keep > running How about this even simpler version to achieve the same? Regards, Daniel. |
|
From: Mike F. <va...@ge...> - 2006-06-25 07:40:10
|
simple patch ... if some autotool fails, abort the script, dont just keep running -mike |
|
From: Mike F. <va...@ge...> - 2006-06-25 07:38:11
|
sorry to hop in late ... just want to make sure you guys dont merge that=20 libdv-0.104-pic-fix.patch ... it is for sure broken :) we've been working with the PaX team to get the stuff cleaned up properly, = we=20 just havent posted anything back yet because it wasnt done ... apparently=20 =46edora missed the fact with the patch they grabbed from us, building anyt= hing=20 statically against libdv will segfault (whee!) =2Dmike |
|
From: Scott H. <sco...@si...> - 2006-05-12 17:13:21
|
I am having problems with building libdv-0.104 from sources. My linux info is: 2.6.14-1.1656_FC4 gcc version 4.0.2 20051125 I am running gtk+ 1.2.10-39 Glib 1.2.10-16 I believe these are the latest 1.2 builds, besides the 1.2.4 build for gtk+ is from about 5 years ago, or so? When I run ./configure I get the following error. Any ideas? checking for pkg-config... /usr/bin/pkg-config checking for glib >= 1.2.4 gtk+ >= 1.2.4... sh: glib-config: command not found sh: glib-config: command not found sh: glib-config: command not found sh: glib-config: command not found sh: glib-config: command not found sh: glib-config: command not found Requested 'glib >= 1.2.4' but version of GLib is configure: error: Library requirements (glib >= 1.2.4 gtk+ >= 1.2.4) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. |
|
From: <pl...@ip...> - 2006-05-09 10:06:17
|
Hi, the attached patch let's configure succeed if gtk-1.x is not found (before, one had to explicitely use the --disable-gtk flag). Furthermore it enables calling "make dist" for people, who don't have gtk-1.x. Please CC me Cheers Burkhard |
|
From: SourceForge.net <no...@so...> - 2006-05-09 04:09:12
|
Bugs item #1484362, was opened at 2006-05-09 04:09 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=1484362&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: David Foster (crystalline) Assigned to: Nobody/Anonymous (nobody) Summary: dv_decoder_new: ignores first parameter ("add_ntsc_setup") Initial Comment: If you read the source code for dv_decoder_new, you'll notice that it completely ignores its first parameter. -------------------------------------------------------- dv_decoder_t * dv_decoder_new(int add_ntsc_setup, int clamp_luma, int clamp_chroma) { dv_decoder_t *result; result = (dv_decoder_t *)calloc(1,sizeof(dv_decoder_t)); if(!result) goto no_mem; result->add_ntsc_setup = FALSE; // *** BUG! *** result->clamp_luma = clamp_luma; result->clamp_chroma = clamp_chroma; -------------------------------------------------------- I suspect that the marked line in the above source code should read as: result->add_ntsc_setup = add_ntsc_setup; At present the only way to work around this is to manually set the "add_ntsc_setup" field of the returned dv_decoder structure with the desired configuration setting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1484362&group_id=4393 |
|
From: Mark H. <ma...@mi...> - 2006-04-17 17:48:57
|
Dan Dennedy wrote: > On Wednesday 12 April 2006 07:25, Mark Heslep wrote: > >> Sure. All the patches for libdc from FC5 attached as there's no >> > [...] > >> libdv-0.104-pic-fix.patch >> > > geez, why has no one ever submitted this PIC patch to the project?! > > > > Apparently FC grabbed something they liked from Gentoo, and fairly recently. From the rpm package changelog: * Wed Feb 15 2006 Matthias Saou <http://freshrpms.net/> 0.104-1 - Update to 0.104 at last (#147311) - Include no-exec-stack, pic-fix, amd64reloc and gtk2 patches from Gentoo and PLD (merge gcc4 fix to the pic-fix patch). - Now build against gtk2 (thanks to the patch above). - Exclude static library. -Mark |
|
From: Dan D. <da...@de...> - 2006-04-14 17:11:41
|
On Wednesday 12 April 2006 07:25, Mark Heslep wrote: > Sure. All the patches for libdc from FC5 attached as there's no [...] > libdv-0.104-pic-fix.patch geez, why has no one ever submitted this PIC patch to the project?! |
|
From: Mark H. <ma...@mi...> - 2006-04-12 14:26:27
|
Dan Dennedy wrote: > On Tuesday 11 April 2006 9:47 am, Mark Heslep wrote: > > Anonymous CVS updates at SourceForge are on some huge delay :-(. Check > the > Changelog periodically, or I can make a snapshot tarball available to you. A > segfault upon exit of a very mediocre player application is probably not > worth the effort. Since the version you did pull from CVS contains post-0.104 > bugfixes, and it is working good for you, then it is another reason I do not > think it is interesting to pursue further testing. > > However, can you save me the trouble of tracking down the > libdv-0.104-gtk2.patch and send it for me to review? > > Sure. All the patches for libdc from FC5 attached as there's no segfault w/ the gtk patch applied. Note I found that at least the gtk patch does not apply cleanly against your CVS source, though the important 1st chunk does apply. I suspect one of the other patches (mmx?) causes the segfault (not referring to the playdv problem here - agree thats irrelevant). FYI, The FC5 entire source package is here, among other places: http://ftp.riken.jp/Linux/fedora/core/5/source/SRPMS/libdv-0.104-2.fc5.src.rpm rpm -ivh <libdv pkg>; rpmbuild -bp ../SPECS/libdv.spec <- will pull the tarball and patches into ../SOURCES on an FC / RedHat system. Mark |
|
From: Dan D. <da...@de...> - 2006-04-12 01:06:26
|
On Tuesday 11 April 2006 9:47 am, Mark Heslep wrote: > Dan Dennedy wrote: > > I just committed the bugfix to CVS. The bug was that the display > > functions of playdv (dv_display_cleanup) were being called twice > > Thanks for the quick response. However, I just pulled from CVS and > still get glibc double free problem on that clip at completion of the > Anonymous CVS updates at SourceForge are on some huge delay :-(. Check the Changelog periodically, or I can make a snapshot tarball available to you. A segfault upon exit of a very mediocre player application is probably not worth the effort. Since the version you did pull from CVS contains post-0.104 bugfixes, and it is working good for you, then it is another reason I do not think it is interesting to pursue further testing. However, can you save me the trouble of tracking down the libdv-0.104-gtk2.patch and send it for me to review? |
|
From: Mark H. <ma...@mi...> - 2006-04-11 17:04:49
|
Mark Heslep wrote: > Dan Dennedy wrote: >> >> I just committed the bugfix to CVS. The bug was that the display >> functions of playdv (dv_display_cleanup) were being called twice >> > Thanks for the quick response. However, I just pulled from CVS and > still get glibc double free problem on that clip at completion of the > pond.dv clip: > However, the CVS pull with the new libdv-so.4.0.2 does correct the gstreamer segfault that had been showing up with libdv-0.104-2 stock with Fedora Core 5. So other than the minor issue reported prior with playdv on close, I'm good now. Possibly the problem is with one of the 4-5 patches FC5 is applying. From the FC5 source pkg: libdv-0.103-mmx.patch libdv-0.104-amd64reloc.patch libdv-0.104-gtk2.patch libdv-0.104-no-exec-stack.patch libdv-0.104-pic-fix.patch I had to apply the gtk2 patch (config.ac items) to get CVS to compile on my FC5 but ignored the rest. Thanks, Mark |
|
From: Mark H. <ma...@mi...> - 2006-04-11 16:48:22
|
Dan Dennedy wrote: > > I just committed the bugfix to CVS. The bug was that the display functions of > playdv (dv_display_cleanup) were being called twice > Thanks for the quick response. However, I just pulled from CVS and still get glibc double free problem on that clip at completion of the pond.dv clip: > [mark@tierra playdv]$ ./playdv ~mark/pond.dv > format 4:3 > Audio is 44.1 kHz, 16 bits quantization, 2 channels, emphasis off > Xv: NV17 Video Texture: ports 294 - 294 > Xv: grabbed port 294 > Using Xv for display > # no audio > # no audio > Processed 85 frames in 02.40 seconds (35.37 fps) > *** glibc detected *** /home/mark/libdv/playdv/.libs/lt-playdv: double > free or corruption (fasttop): 0x083af620 *** > ======= Backtrace: ========= > /lib/libc.so.6[0xbacf18] > /lib/libc.so.6(__libc_free+0x79)[0xbb041d] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804ba49] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804baa3] > /lib/libc.so.6(exit+0xe6)[0xb73a06] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804ab93] > /lib/libc.so.6(__libc_start_main+0xdc)[0xb5e7e4] > /home/mark/libdv/playdv/.libs/lt-playdv[0x8049bd1] > ======= Memory map: ======== > 00284000-0028b000 r-xp 00000000 fd:00 699134 /usr/lib/libpopt.so.0.0.0 > 0028b000-0028c000 rwxp 00006000 fd:00 699134 /usr/lib/libpopt.so.0.0.0 > 00356000-0035a000 r-xp 00000000 fd:00 715152 /usr/lib/libXv.so.1.0.0 > 0035a000-0035b000 rwxp 00003000 fd:00 715152 /usr/lib/libXv.so.1.0.0 > 00971000-00a02000 r-xp 00000000 fd:00 715392 > /usr/lib/libglib-2.0.so.0.1000.1 > 00a02000-00a03000 rwxp 00091000 fd:00 715392 > /usr/lib/libglib-2.0.so.0.1000.1 > 00a05000-00a43000 r-xp 00000000 fd:00 715393 > /usr/lib/libgobject-2.0.so.0.1000.1 > 00a43000-00a44000 rwxp 0003e000 fd:00 715393 > /usr/lib/libgobject-2.0.so.0.1000.1 > 00a46000-00a65000 r-xp 00000000 fd:00 328125 /lib/libexpat.so.0.5.0 > 00a65000-00a67000 rwxp 0001e000 fd:00 328125 /lib/libexpat.so.0.5.0 > 00a69000-00ad4000 r-xp 00000000 fd:00 715411 > /usr/lib/libfreetype.so.6.3.8 > 00ad4000-00ad7000 rwxp 0006a000 fd:00 715411 > /usr/lib/libfreetype.so.6.3.8 > 00ad9000-00b00000 r-xp 00000000 fd:00 715410 > /usr/lib/libpng12.so.0.1.2.8 > 00b00000-00b01000 rwxp 00026000 fd:00 715410 > /usr/lib/libpng12.so.0.1.2.8 > 00b03000-00b0b000 r-xp 00000000 fd:00 715409 > /usr/lib/libXrender.so.1.3.0 > 00b0b000-00b0c000 rwxp 00007000 fd:00 715409 > /usr/lib/libXrender.so.1.3.0 > 00b0e000-00b17000 r-xp 00000000 fd:00 715420 > /usr/lib/libXcursor.so.1.0.2 > 00b17000-00b18000 rwxp 00008000 fd:00 715420 > /usr/lib/libXcursor.so.1.0.2 > 00b1a000-00b21000 r-xp 00000000 fd:00 715417 /usr/lib/libXi.so.6.0.0 > 00b21000-00b22000 rwxp 00007000 fd:00 715417 /usr/lib/libXi.so.6.0.0 > 00b24000-00b28000 r-xp 00000000 fd:00 715419 > /usr/lib/libXfixes.so.3.0.0 > 00b28000-00b29000 rwxp 00003000 fd:00 715419 > /usr/lib/libXfixes.so.3.0.0 > 00b2b000-00b2c000 r-xp 00b2b000 00:00 0 [vdso] > 00b2c000-00b45000 r-xp 00000000 fd:00 328117 /lib/ld-2.4.so > 00b45000-00b46000 r-xp 00018000 fd:00 328117 /lib/ld-2.4.so > 00b46000-00b47000 rwxp 00019000 fd:00 328117 /lib/ld-2.4.so > 00b49000-00c75000 r-xp 00000000 fd:00 328118 /lib/libc-2.4.so > 00c75000-00c78000 r-xp 0012b000 fd:00 328118 /lib/libc-2.4.so > 00c78000-00c79000 rwxp 0012e000 fd:00 328118 /lib/libc-2.4.so > 00c79000-00c7c000 rwxp 00c79000 00:00 0 > 00c7e000-00ca1000 r-xp 00000000 fd:00 328121 /lib/libm-2.4.so > 00ca1000-00ca2000 r-xp 00022000 fd:00 328121 /lib/libm-2.4.so > 00ca2000-00ca3000 rwxp 00023000 fd:00 328121 /lib/libm-2.4.so > 00ca5000-00ca7000 r-xp 00000000 fd:00 328120 /lib/libdl-2.4.so > 00ca7000-00ca8000 r-xp 00001000 fd:00 328120 /lib/libdl-2.4.so > 00ca8000-00ca9000 rwxp 00002000 fd:00 328120 /lib/libdl-2.4.so > 00cab000-00cbd000 r-xp 00000000 fd:00 715396 /usr/lib/libz.so.1.2.3 > 00cbd000-00cbe000 rwxp 00011000 fd:00 715396 /usr/lib/libz.so.1.2.3 > 00cc0000-00cc2000 r-xp 00000000 fd:00 715401 /usr/lib/libXau.so.6.0.0 > 00cc2000-00cc3000 rwxp 00001000 fd:00 715401 /usr/lib/libXau.so.6.0.0 > 00cc5000-00dbe000 r-xp 00000000 fd:00 715403 /usr/lib/libX11.so.6.2.0 > 00dbe000-00dc2000 rwxp 000f9000 fd:00 715403 /usr/lib/libX11.so.6.2.0 > 00dc4000-00dc9000 r-xp 00000000 fd:00 715402 > /usr/lib/libXdmcp.so.6.0.0 > 00dc9000-00dca000 rwxp 00004000 fd:00 715402 > /usr/lib/libXdmcp.so.6.0.0 > 00dcc000-00ddb000 r-xp 00000000 fd:00 715404 /usr/lib/libXext.so.6.4.0 > 00ddb000-00ddc000 rwxp 0000e000 fd:00 715404 /usr/lib/libXext.so.6.4.0 > 00df4000-00df7000 r-xp 00000000 fd:00 715395 > /usr/lib/libgmodule-2.0.so.0.1000.1 > 00df7000-00df8000 rwxp 00002000 fd:00 715395 > /usr/lib/libgmodule-2.0.so.0.1000.1 > 00dfa000-00dfd000 r-xp 00000000 fd:00 715418 > /usr/lib/libXrandr.so.2.0.0 > 00dfd000-00dfe000 rwxp 00002000 fd:00 715418 > /usr/lib/libXrandr.so.2.0.0 > 00f2d000-00f46000 r-xp 00000000 09:00 8208932 > /home/mark/libdv/libdv/.libs/libdv.so.4.0.2 > 00f46000-00f48000 rwxp 00019000 09:00 8208932 > /home/mark/libdv/libdv/.libs/libdv.so.4.0.2 > 00f48000-00f54000 rwxp 00f48000 00:00 0 > 02000000-0231d000 r-xp 00000000 fd:00 700641 > /usr/lib/libgtk-x11-2.0.so.0.800.15 > 0231d000-02325000 rwxp 0031d000 fd:00 700641 > /usr/lib/libgtk-x11-2.0.so.0.800.15 > 02325000-02328000 rwxp 02325000 00:00 0 > 04f0e000-04f46000 r-xp 00000000 fd:00 715412 > /usr/lib/libfontconfig.so.1.0.4 > 04f46000-04f4a000 rwxp 00038000 fd:00 715412 > /usr/lib/libfontconfig.so.1.0.4 > 04f4a000-04f4b000 rwxp 04f4a000 00:00 0 > 04f4d000-04f74000 r-xp 00000000 fd:00 715414 > /usr/lib/libpangoft2-1.0.so.0.1200.0 > 04f74000-04f75000 rwxp 00027000 fd:00 715414 > /usr/lib/libpangoft2-1.0.so.0.1200.0 > 04f77000-04f91000 r-xp 00000000 fd:00 715422 > /usr/lib/libatk-1.0.so.0.1113.0 > 04f91000-04f93000 rwxp 00019000 fd:00 715422 > /usr/lib/libatk-1.0.so.0.1113.0 > 04fe9000-05025000 r-xp 00000000 fd:00 715408 > /usr/lib/libpango-1.0.so.0.1200.0 > 05025000-05027000 rwxp 0003b000 fd:00 715408 > /usr/lib/libpango-1.0.so.0.1200.0 > 05029000-05040000 r-xp 00000000 fd:00 710328 > /usr/lib/libgdk_pixbuf-2.0.so.0.800.15 > 05040000-05041000 rwxp 00016000 fd:00 710328 > /usr/lib/libgdk_pixbuf-2.0.so.0.800.15 > 05043000-05045000 r-xp 00000000 fd:00 715416 > /usr/lib/libXinerama.so.1.0.0 > 05045000-05046000 rwxp 00001000 fd:00 715416 > /usr/lib/libXinerama.so.1.0.0 > 05409000-05414000 r-xp 00000000 fd:00 328122 > /lib/libgcc_s-4.1.0-20060304.so.1 > 05414000-05415000 rwxp 0000a000 fd:00 328122 > /lib/libgcc_s-4.1.0-20060304.so.1 > 06d25000-06d2d000 r-xp 00000000 fd:00 700639 > /usr/lib/libpangocairo-1.0.so.0.1200.0 > 06d2d000-06d2e000 rwxp 00007000 fd:00 700639 > /usr/lib/libpangocairo-1.0.so.0.1200.0 > 06d30000-06db7000 r-xp 00000000 fd:00 700640 > /usr/lib/libgdk-x11-2.0.so.0.800.15 > 06db7000-06dba000 rwxp 00087000 fd:00 700640 > /usr/lib/libgdk-x11-2.0.so.0.800.15 > 06dbc000-06e0d000 r-xp 00000000 fd:00 700638 > /usr/lib/libcairo.so.2.2.4 > 06e0d000-06e0e000 rwxp 00051000 fd:00 700638 > /usr/lib/libcairo.so.2.2.4 > 08048000-0804d000 r-xp 00000000 09:00 8224890 > /home/mark/libdv/playdv/.libs/lt-playdv > 0804d000-0804e000 rw-p 00005000 09:00 8224890 > /home/mark/libdv/playdv/.libs/lt-playdv > 083a2000-083c3000 rw-p 083a2000 00:00 0 [heap] > b7e00000-b7e21000 rw-p b7e00000 00:00 0 > b7e21000-b7f00000 ---p b7e21000 00:00 0 > b7f4d000-b7f96000 rw-p b7f4d000 00:00 0 > b7fac000-b7fad000 rw-p b7fac000 00:00 0 > bfc96000-bfcac000 rw-p bfc96000 00:00 0 [stack] > Aborted |
|
From: Mark H. <ma...@mi...> - 2006-04-11 15:52:57
|
Dan Dennedy wrote: > > > That should not be the case since the bug was clearly isolated to playdv, and > I never saw it while using Kino. I guess I rarely let playdv play to the end > when I use it, which is also a rare occasstion. What gives you the impression > apps linked to libdv are affected by this? > Thank you for the bug report. > > > Details in this bug report to gstreamer http://bugzilla.gnome.org/show_bug.cgi?id=338003 Backtrace there from segfault against dvsd video seems to point to libdv. Mark |
|
From: Dan D. <da...@de...> - 2006-04-11 04:12:19
|
On Monday 10 April 2006 16:17, mark wrote: > Im getting a > > > *** glibc detected *** /home/mark/libdv/playdv/.libs/lt-playdv: double > > free or corruption (fasttop): 0x09e09620 *** > > pointer corruption on dvplay built from todays CVS. The sample clip is > dvsd raw dv from > http://www.mplayerhq.hu/MPlayer/samples/V-codecs/DVSD/pond.dv > > Likewise dvplay build on a libdc-0.104 release straight out segfaults > immediately, however, the CVS version plays most of the clip before > coughing up this backtrace below. I just committed the bugfix to CVS. The bug was that the display functions of playdv (dv_display_cleanup) were being called twice. > CVS built on FC5 gcc 4.1 on i686. Any suggestions? The same problem > occurs of course from everything downstream - gstreamer, etc. That should not be the case since the bug was clearly isolated to playdv, and I never saw it while using Kino. I guess I rarely let playdv play to the end when I use it, which is also a rare occasstion. What gives you the impression apps linked to libdv are affected by this? Thank you for the bug report. |
|
From: mark <ma...@mi...> - 2006-04-10 23:40:22
|
Im getting a > *** glibc detected *** /home/mark/libdv/playdv/.libs/lt-playdv: double > free or corruption (fasttop): 0x09e09620 *** pointer corruption on dvplay built from todays CVS. The sample clip is dvsd raw dv from http://www.mplayerhq.hu/MPlayer/samples/V-codecs/DVSD/pond.dv Likewise dvplay build on a libdc-0.104 release straight out segfaults immediately, however, the CVS version plays most of the clip before coughing up this backtrace below. CVS built on FC5 gcc 4.1 on i686. Any suggestions? The same problem occurs of course from everything downstream - gstreamer, etc. I note that ffmpeg's ffplay, which does not link in libdv, handles the clip correctly Mark > rmat 4:3 > Audio is 44.1 kHz, 16 bits quantization, 2 channels, emphasis off > Xv: NV17 Video Texture: ports 294 - 294 > Xv: grabbed port 294 > Using Xv for display > # no audio > # no audio > Processed 85 frames in 02.40 seconds (35.38 fps) > *** glibc detected *** /home/mark/libdv/playdv/.libs/lt-playdv: double > free or corruption (fasttop): 0x09e09620 *** > ======= Backtrace: ========= > /lib/libc.so.6[0xbacf18] > /lib/libc.so.6(__libc_free+0x79)[0xbb041d] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804ba49] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804baa3] > /lib/libc.so.6(exit+0xe6)[0xb73a06] > /home/mark/libdv/playdv/.libs/lt-playdv[0x804ab93] > /lib/libc.so.6(__libc_start_main+0xdc)[0xb5e7e4] > /home/mark/libdv/playdv/.libs/lt-playdv[0x8049bd1] > ======= Memory map: ======== > 00137000-00150000 r-xp 00000000 09:00 8208586 > /home/mark/libdv_CVS_041006/libdv/.libs/libdv.so.4.0.2 > 00150000-00152000 rwxp 00019000 09:00 8208586 > /home/mark/libdv_CVS_041006/libdv/.libs/libdv.so.4.0.2 > 00152000-0015e000 rwxp 00152000 00:00 0 > 00284000-0028b000 r-xp 00000000 fd:00 699134 /usr/lib/libpopt.so.0.0.0 > 0028b000-0028c000 rwxp 00006000 fd:00 699134 /usr/lib/libpopt.so.0.0.0 > 00356000-0035a000 r-xp 00000000 fd:00 715152 /usr/lib/libXv.so.1.0.0 > 0035a000-0035b000 rwxp 00003000 fd:00 715152 /usr/lib/libXv.so.1.0.0 > 00971000-00a02000 r-xp 00000000 fd:00 715392 > /usr/lib/libglib-2.0.so.0.1000.1 > 00a02000-00a03000 rwxp 00091000 fd:00 715392 > /usr/lib/libglib-2.0.so.0.1000.1 > 00a05000-00a43000 r-xp 00000000 fd:00 715393 > /usr/lib/libgobject-2.0.so.0.1000.1 > 00a43000-00a44000 rwxp 0003e000 fd:00 715393 > /usr/lib/libgobject-2.0.so.0.1000.1 > 00a46000-00a65000 r-xp 00000000 fd:00 328125 /lib/libexpat.so.0.5.0 > 00a65000-00a67000 rwxp 0001e000 fd:00 328125 /lib/libexpat.so.0.5.0 > 00a69000-00ad4000 r-xp 00000000 fd:00 715411 > /usr/lib/libfreetype.so.6.3.8 > 00ad4000-00ad7000 rwxp 0006a000 fd:00 715411 > /usr/lib/libfreetype.so.6.3.8 > 00ad9000-00b00000 r-xp 00000000 fd:00 715410 > /usr/lib/libpng12.so.0.1.2.8 > 00b00000-00b01000 rwxp 00026000 fd:00 715410 > /usr/lib/libpng12.so.0.1.2.8 > 00b03000-00b0b000 r-xp 00000000 fd:00 715409 > /usr/lib/libXrender.so.1.3.0 > 00b0b000-00b0c000 rwxp 00007000 fd:00 715409 > /usr/lib/libXrender.so.1.3.0 > 00b0e000-00b17000 r-xp 00000000 fd:00 715420 > /usr/lib/libXcursor.so.1.0.2 > 00b17000-00b18000 rwxp 00008000 fd:00 715420 > /usr/lib/libXcursor.so.1.0.2 > 00b1a000-00b21000 r-xp 00000000 fd:00 715417 /usr/lib/libXi.so.6.0.0 > 00b21000-00b22000 rwxp 00007000 fd:00 715417 /usr/lib/libXi.so.6.0.0 > 00b24000-00b28000 r-xp 00000000 fd:00 715419 > /usr/lib/libXfixes.so.3.0.0 > 00b28000-00b29000 rwxp 00003000 fd:00 715419 > /usr/lib/libXfixes.so.3.0.0 > 00b2b000-00b2c000 r-xp 00b2b000 00:00 0 [vdso] > 00b2c000-00b45000 r-xp 00000000 fd:00 328117 /lib/ld-2.4.so > 00b45000-00b46000 r-xp 00018000 fd:00 328117 /lib/ld-2.4.so > 00b46000-00b47000 rwxp 00019000 fd:00 328117 /lib/ld-2.4.so > 00b49000-00c75000 r-xp 00000000 fd:00 328118 /lib/libc-2.4.so > 00c75000-00c78000 r-xp 0012b000 fd:00 328118 /lib/libc-2.4.so > 00c78000-00c79000 rwxp 0012e000 fd:00 328118 /lib/libc-2.4.so > 00c79000-00c7c000 rwxp 00c79000 00:00 0 > 00c7e000-00ca1000 r-xp 00000000 fd:00 328121 /lib/libm-2.4.so > 00ca1000-00ca2000 r-xp 00022000 fd:00 328121 /lib/libm-2.4.so > 00ca2000-00ca3000 rwxp 00023000 fd:00 328121 /lib/libm-2.4.so > 00ca5000-00ca7000 r-xp 00000000 fd:00 328120 /lib/libdl-2.4.so > 00ca7000-00ca8000 r-xp 00001000 fd:00 328120 /lib/libdl-2.4.so > 00ca8000-00ca9000 rwxp 00002000 fd:00 328120 /lib/libdl-2.4.so > 00cab000-00cbd000 r-xp 00000000 fd:00 715396 /usr/lib/libz.so.1.2.3 > 00cbd000-00cbe000 rwxp 00011000 fd:00 715396 /usr/lib/libz.so.1.2.3 > 00cc0000-00cc2000 r-xp 00000000 fd:00 715401 /usr/lib/libXau.so.6.0.0 > 00cc2000-00cc3000 rwxp 00001000 fd:00 715401 /usr/lib/libXau.so.6.0.0 > 00cc5000-00dbe000 r-xp 00000000 fd:00 715403 /usr/lib/libX11.so.6.2.0 > 00dbe000-00dc2000 rwxp 000f9000 fd:00 715403 /usr/lib/libX11.so.6.2.0 > 00dc4000-00dc9000 r-xp 00000000 fd:00 715402 > /usr/lib/libXdmcp.so.6.0.0 > 00dc9000-00dca000 rwxp 00004000 fd:00 715402 > /usr/lib/libXdmcp.so.6.0.0 > 00dcc000-00ddb000 r-xp 00000000 fd:00 715404 /usr/lib/libXext.so.6.4.0 > 00ddb000-00ddc000 rwxp 0000e000 fd:00 715404 /usr/lib/libXext.so.6.4.0 > 00df4000-00df7000 r-xp 00000000 fd:00 715395 > /usr/lib/libgmodule-2.0.so.0.1000.1 > 00df7000-00df8000 rwxp 00002000 fd:00 715395 > /usr/lib/libgmodule-2.0.so.0.1000.1 > 00dfa000-00dfd000 r-xp 00000000 fd:00 715418 > /usr/lib/libXrandr.so.2.0.0 > 00dfd000-00dfe000 rwxp 00002000 fd:00 715418 > /usr/lib/libXrandr.so.2.0.0 > 02000000-0231d000 r-xp 00000000 fd:00 700641 > /usr/lib/libgtk-x11-2.0.so.0.800.15 > 0231d000-02325000 rwxp 0031d000 fd:00 700641 > /usr/lib/libgtk-x11-2.0.so.0.800.15 > 02325000-02328000 rwxp 02325000 00:00 0 > 04f0e000-04f46000 r-xp 00000000 fd:00 715412 > /usr/lib/libfontconfig.so.1.0.4 > 04f46000-04f4a000 rwxp 00038000 fd:00 715412 > /usr/lib/libfontconfig.so.1.0.4 > 04f4a000-04f4b000 rwxp 04f4a000 00:00 0 > 04f4d000-04f74000 r-xp 00000000 fd:00 715414 > /usr/lib/libpangoft2-1.0.so.0.1200.0 > 04f74000-04f75000 rwxp 00027000 fd:00 715414 > /usr/lib/libpangoft2-1.0.so.0.1200.0 > 04f77000-04f91000 r-xp 00000000 fd:00 715422 > /usr/lib/libatk-1.0.so.0.1113.0 > 04f91000-04f93000 rwxp 00019000 fd:00 715422 > /usr/lib/libatk-1.0.so.0.1113.0 > 04fe9000-05025000 r-xp 00000000 fd:00 715408 > /usr/lib/libpango-1.0.so.0.1200.0 > 05025000-05027000 rwxp 0003b000 fd:00 715408 > /usr/lib/libpango-1.0.so.0.1200.0 > 05029000-05040000 r-xp 00000000 fd:00 710328 > /usr/lib/libgdk_pixbuf-2.0.so.0.800.15 > 05040000-05041000 rwxp 00016000 fd:00 710328 > /usr/lib/libgdk_pixbuf-2.0.so.0.800.15 > 05043000-05045000 r-xp 00000000 fd:00 715416 > /usr/lib/libXinerama.so.1.0.0 > 05045000-05046000 rwxp 00001000 fd:00 715416 > /usr/lib/libXinerama.so.1.0.0 > 05409000-05414000 r-xp 00000000 fd:00 328122 > /lib/libgcc_s-4.1.0-20060304.so.1 > 05414000-05415000 rwxp 0000a000 fd:00 328122 > /lib/libgcc_s-4.1.0-20060304.so.1 > 06d25000-06d2d000 r-xp 00000000 fd:00 700639 > /usr/lib/libpangocairo-1.0.so.0.1200.0 > 06d2d000-06d2e000 rwxp 00007000 fd:00 700639 > /usr/lib/libpangocairo-1.0.so.0.1200.0 > 06d30000-06db7000 r-xp 00000000 fd:00 700640 > /usr/lib/libgdk-x11-2.0.so.0.800.15 > 06db7000-06dba000 rwxp 00087000 fd:00 700640 > /usr/lib/libgdk-x11-2.0.so.0.800.15 > 06dbc000-06e0d000 r-xp 00000000 fd:00 700638 > /usr/lib/libcairo.so.2.2.4 > 06e0d000-06e0e000 rwxp 00051000 fd:00 700638 > /usr/lib/libcairo.so.2.2.4 > 08048000-0804d000 r-xp 00000000 09:00 8208740 > /home/mark/libdv_CVS_041006/playdv/.libs/lt-playdv > 0804d000-0804e000 rw-p 00005000 09:00 8208740 > /home/mark/libdv_CVS_041006/playdv/.libs/lt-playdv > 09dfc000-09e1d000 rw-p 09dfc000 00:00 0 [heap] > b7d00000-b7d21000 rw-p b7d00000 00:00 0 > b7d21000-b7e00000 ---p b7d21000 00:00 0 > b7ef3000-b7f3c000 rw-p b7ef3000 00:00 0 > b7f52000-b7f53000 rw-p b7f52000 00:00 0 > bfa3c000-bfa52000 rw-p bfa3c000 00:00 0 [stack] > Aborted |
|
From: Brent C. <bca...@sg...> - 2006-04-07 16:30:42
|
On Thu, 6 Apr 2006, Stanley Tuna wrote:
> When I run my code, the program seg faults when running dv_decode_full_frame -
> am I missing something obvious?
>
> #include "transcode-0.6.14/avilib/avilib.h"
> #include <libdv/dv.h>
>
> #define READ_SIZE 120000
>
> int main(void)
> {
> int width,height;
> long frames,framesize;
> avi_t *avifile;
> char *compressor;
> unsigned char *framebuffer;
>
> int keyframe;
>
> dv_decoder_t *dvdecoder;
> unsigned char *pixels[3];
> int pitches[3];
>
> /* open the avi file and the decoder */
> avifile=AVI_open_input_file(
> "/home/tuna/f15_pavl_150_r1/te/f15_pavl_150_r1_te_beg.avi"
> ,1);
> if(!avifile)
> {
> printf("Error: Could not open avi file\n");
> }
> dvdecoder=dv_decoder_new(TRUE, FALSE, FALSE);
> if(!dvdecoder)
> {
> printf("Error: Could not initialize dv decoder\n");
> }
> framebuffer=malloc(READ_SIZE);
> pixels[0]=malloc(dvdecoder->width*dvdecoder->height*3);
> pitches[0]=dvdecoder->width*3;
I think these two lines might be where you're going wrong.
The decoder hasn't been initialized to the point of knowing the
format of the input, and thus the width and height are not
valid values.
Check out the playdv.c file in the libdv source, at or near
line 355. You'll see that they pull in an NTSC sized frame of
data (120000 bytes), and run dv_parse_header() on it. After
that has finished, *then* the width and height of the decoder
structure are known (and the size of the input frames, which
would be 144000 bytes for PAL).
>
> AVI_info(avifile);
> frames=AVI_video_frames(avifile);
> width=AVI_video_width(avifile);
> height=AVI_video_height(avifile);
> compressor=AVI_video_compressor(avifile);
> framesize=AVI_frame_size(avifile,0);
>
> /* start reading and decoding frames */
> AVI_seek_start(avifile);
> if(AVI_read_frame(avifile,framebuffer,&keyframe)<0)
> {
> printf("Error: Could not read frame from avi file\n");
> }
>
> if(dv_parse_header(dvdecoder,framebuffer)<0)
> {
> printf("Error: Failed to parse header\n");
> }
In your provided program, you should be able to just move the
malloc() of "pixels" after your call to dv_parse_header(),
and all would be well.
> printf("Decoding...\n");
> dv_decode_full_frame(dvdecoder,framebuffer,e_dv_color_rgb,pixels,pitches);
>
> AVI_close(avifile);
>
> return 0;
> }
>
> tuna@ocean /home/tuna/src $ gcc readavi.c -L/home/tuna/src/transcode-0.6.14/
> -lavi -ldv
> tuna@ocean /home/tuna/src $ ./a.out
> [avilib] V: 29.970 fps, codec=dvsd, frames=1821, width=720, height=480
> [avilib] A: 32000 Hz, format=0x01, bits=16, channels=2, bitrate=1024 kbps,
> [avilib] 1821 chunks, 7777432 bytes, CBR
> Decoding...
> Segmentation fault
> tuna@ocean /home/tuna/src $
--
Brent Casavant All music is folk music. I ain't
bca...@sg... never heard a horse sing a song.
Silicon Graphics, Inc. -- Louis Armstrong
|
|
From: Stanley T. <sea...@ho...> - 2006-04-07 01:11:52
|
Hi,
I'm doing something similar to an earlier post on Oct 2005 except I want to
extract frames from an avi file whose video data is encoded in dv format.
I've been following the sample code in that post and some code samples on
the internet for avilib. My ultimate goal is to get the frames from the avi
file into Matlab in the same way that the tool dvdec does.
When I run my code, the program seg faults when running dv_decode_full_frame
- am I missing something obvious?
Thanks for your help!
Stan
#include "transcode-0.6.14/avilib/avilib.h"
#include <libdv/dv.h>
#define READ_SIZE 120000
int main(void)
{
int width,height;
long frames,framesize;
avi_t *avifile;
char *compressor;
unsigned char *framebuffer;
int keyframe;
dv_decoder_t *dvdecoder;
unsigned char *pixels[3];
int pitches[3];
/* open the avi file and the decoder */
avifile=AVI_open_input_file(
"/home/tuna/f15_pavl_150_r1/te/f15_pavl_150_r1_te_beg.avi"
,1);
if(!avifile)
{
printf("Error: Could not open avi file\n");
}
dvdecoder=dv_decoder_new(TRUE, FALSE, FALSE);
if(!dvdecoder)
{
printf("Error: Could not initialize dv decoder\n");
}
framebuffer=malloc(READ_SIZE);
pixels[0]=malloc(dvdecoder->width*dvdecoder->height*3);
pitches[0]=dvdecoder->width*3;
AVI_info(avifile);
frames=AVI_video_frames(avifile);
width=AVI_video_width(avifile);
height=AVI_video_height(avifile);
compressor=AVI_video_compressor(avifile);
framesize=AVI_frame_size(avifile,0);
/* start reading and decoding frames */
AVI_seek_start(avifile);
if(AVI_read_frame(avifile,framebuffer,&keyframe)<0)
{
printf("Error: Could not read frame from avi file\n");
}
if(dv_parse_header(dvdecoder,framebuffer)<0)
{
printf("Error: Failed to parse header\n");
}
printf("Decoding...\n");
dv_decode_full_frame(dvdecoder,framebuffer,e_dv_color_rgb,pixels,pitches);
AVI_close(avifile);
return 0;
}
tuna@ocean /home/tuna/src $ gcc readavi.c -L/home/tuna/src/transcode-0.6.14/
-lavi -ldv
tuna@ocean /home/tuna/src $ ./a.out
[avilib] V: 29.970 fps, codec=dvsd, frames=1821, width=720, height=480
[avilib] A: 32000 Hz, format=0x01, bits=16, channels=2, bitrate=1024 kbps,
[avilib] 1821 chunks, 7777432 bytes, CBR
Decoding...
Segmentation fault
tuna@ocean /home/tuna/src $
_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar get it now!
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/
|
|
From: Charles 'B. K. <kr...@cs...> - 2006-03-08 21:48:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brent, It has been a very long time since I looked at that, but I do still have some notes. Here are some of the references I used: Using MMX[tm] Instructions in a Fast iDCT Algorithm for MPEG decoding Intel application note, 2000 A comparison of fast inverse discreet cosine transform algorithms Andy C. Hung and Terese H.-Y. Meng Multimedia Systems (1994) 2:204-217 Direct conversions between DV Format DCT and Ordinary DCT Neri Merhav HP Laboratories Israel HPL-98-140 August, 1998 As I recall, the multimedia systems paper was very helpful to me in understanding the algorithms. - -- Buck Brent Casavant wrote: >Peter and Charles, > >I noticed that the two of you have been heavily involved with the >low-level encoder/decoder routines in libdv, the DCT/IDCT code in >particular, and in Peter's case the MMX routines even more particularly. > >I would like to add support for equivalent DCT/IDCT routines using >Itanium SIMD instructions (similar to x86 MMX). However, to do so >I need a better understanding of the algorithm implemented by the >x86 MMX routines. While I can certainly inspect the MMX routines >and work from there, that is one of the least preferable methods, >as I believe a higher-level understanding may allow me to create >routines better suited for Itanium. > >Could you direct me toward whatever source material (papers, etc) >you used in writing the MMX routines? > >Thank you, >Brent Casavant > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFED1EEPrrWIMa4SMsRApR2AKDcd/Lqoyqm0tZiNGvm3fRGkAvx6gCeKW7S MsU3MlSAfdQj/YAxLY7p0WA= =sQt1 -----END PGP SIGNATURE----- |
|
From: Brent C. <bca...@sg...> - 2006-03-07 20:28:58
|
The reorder_block() zigzag behaves incorrectly in the !ARCH_X86 &&
!ARCH_X86_64 case. The current code fails to take into account the
effects of _dv_prepare_reorder_tables(), which changes the indexes
contained in the reorder_88[] and reorder_248[] arrays.
---
Restore older, known good, reorder_block() inner loop.
encode.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff -ru libdv-0.104-orig/libdv/encode.c libdv-0.104-fixed/libdv/encode.c
--- libdv-0.104-orig/libdv/encode.c 2004-11-16 21:36:30.000000000 -0600
+++ libdv-0.104-fixed/libdv/encode.c 2006-03-07 14:07:22.000000000 -0600
@@ -512,10 +512,9 @@
_dv_reorder_block_mmx_x86_64(bl->coeffs, reorder);
emms();
#else
- for (i = 0; i < 64; i++) {
- // *(unsigned short*) ((char*) zigzag + reorder[i])=bl->coeffs[i];
- zigzag[reorder[i] - 1] = bl->coeffs[i];
- }
+ for (i = 0; i < 64; i++)
+ *(unsigned short*) ((char*) zigzag + reorder[i])=bl->coeffs[i];
+
memcpy(bl->coeffs, zigzag, 64 * sizeof(dv_coeff_t));
#endif
}
|
|
From: Dan D. <da...@de...> - 2006-03-07 05:55:58
|
applied On Monday 27 February 2006 14:50, Daniel Kobras wrote: > On Mon, Feb 27, 2006 at 09:36:15PM +0000, Erik Walthinsen wrote: > > -------- 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. > > Richard Guenther from Suse passed me the following patch, which he > needed to build libdv on x86 with gcc 4.1. Most parts are also contained > in Zan's larger patch, but apparently the first change in Richard's patch > needs to be added on top of that. (Sorry, I had been sitting on this > patch for way too long and was only reminded of it by Erik's mail to the > list.) |
|
From: Dan D. <da...@de...> - 2006-03-07 05:55:30
|
applied On Monday 27 February 2006 13:36, Erik Walthinsen wrote: > -------- 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. |
|
From: Brent C. <bca...@sg...> - 2006-03-03 22:51:53
|
I seem to have found the problem, though I'm short on time and unable to look into the root cause at the moment. The issue is in reorder_block(), where the zigzag is performed. I noticed in the !ARCH_X86 && !ARCH_X86_64 code path that there were the following two lines: // *(unsigned short*) ((char*) zigzag + reorder[i])=bl->coeffs[i]; zigzag[reorder[i] - 1] = bl->coeffs[i]; When I uncomment the first and comment the second, the output is no longer corrupted. Granted, the code as-is looks more correct, but obviously it's producing incorrect results. *boggle* If I don't hear from anyone I'll look closer into this next week. Brent On Thu, 2 Mar 2006, Brent Casavant wrote: > Have any of you run the libdv encoder (via encodedv, or otherwise) on IA64? > I find that the output of the encoder is incorrect, despite correct > input. To be clear, the decoder seems to generate correct results. > > As an example, I ran a 720x480 ppm image through encodedv both on i386 > and IA64. The i386 DV file played back correctly, the IA64 DV file > was corrupted. I've managed to narrow the problem down to > dv_encode_full_frame() -- identical input on both platforms produces > different output. > > This is with pristine libdv-0.104 code, FWIW. > > Also, has there been any work done on adding SIMD instruction support > for IA64? Last fall I implemenented the brute-force idct_88() code > using IA64 SIMD, and while it was indeed much faster, it wasn't > fast enough for realtime playback. If someone could describe the > algorithm used in the x86 MMX routines, I could probably put together > an equivalent IA64 SIMD version. > > Thank you, > Brent Casavant > > -- > Brent Casavant All music is folk music. I ain't > bca...@sg... never heard a horse sing a song. > Silicon Graphics, Inc. -- Louis Armstrong > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > libdv-dev mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdv-dev > -- Brent Casavant All music is folk music. I ain't bca...@sg... never heard a horse sing a song. Silicon Graphics, Inc. -- Louis Armstrong |
|
From: Roman S. <rv...@su...> - 2006-03-02 23:01:48
|
On Thu, Mar 02, 2006 at 04:48:56PM -0600, Brent Casavant wrote: > Hello, > > Have any of you run the libdv encoder (via encodedv, or otherwise) on IA64? libdv is really getting old and hard to maintain on all the architectures people want to run it on. Dan is doing a superb job of making sure that it doesn't bitrot but I don't think he's interested in developing it. I advice you to try DV codec in FFmpeg project (which I currently maintain). It is doing pretty well nowadays and we even hope to implement DVCPRO50 and DVCPRO HD soon. It also runs on a really vast set of platforms. Thanks, Roman. |
|
From: Brent C. <bca...@sg...> - 2006-03-02 22:49:08
|
Hello, Have any of you run the libdv encoder (via encodedv, or otherwise) on IA64? I find that the output of the encoder is incorrect, despite correct input. To be clear, the decoder seems to generate correct results. As an example, I ran a 720x480 ppm image through encodedv both on i386 and IA64. The i386 DV file played back correctly, the IA64 DV file was corrupted. I've managed to narrow the problem down to dv_encode_full_frame() -- identical input on both platforms produces different output. This is with pristine libdv-0.104 code, FWIW. Also, has there been any work done on adding SIMD instruction support for IA64? Last fall I implemenented the brute-force idct_88() code using IA64 SIMD, and while it was indeed much faster, it wasn't fast enough for realtime playback. If someone could describe the algorithm used in the x86 MMX routines, I could probably put together an equivalent IA64 SIMD version. Thank you, Brent Casavant -- Brent Casavant All music is folk music. I ain't bca...@sg... never heard a horse sing a song. Silicon Graphics, Inc. -- Louis Armstrong |
|
From: Daniel K. <ko...@li...> - 2006-02-27 22:50:51
|
On Mon, Feb 27, 2006 at 09:36:15PM +0000, Erik Walthinsen wrote:
> -------- 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.
Richard Guenther from Suse passed me the following patch, which he
needed to build libdv on x86 with gcc 4.1. Most parts are also contained
in Zan's larger patch, but apparently the first change in Richard's patch
needs to be added on top of that. (Sorry, I had been sitting on this
patch for way too long and was only reminded of it by Erik's mail to the
list.)
Regards,
Daniel.
--- libdv/mmx.h.orig 2005-10-26 13:20:55.000000000 +0200
+++ libdv/mmx.h 2005-10-26 13:25:21.000000000 +0200
@@ -353,16 +353,16 @@
#define mmx_i2r(op, imm, reg) \
__asm__ __volatile__ (#op " %0, %%" #reg \
: /* nothing */ \
- : "X" (imm) )
+ : "i" (imm) )
#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
|
16 messages has been excluded from this view by a project administrator.
