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: Marko <mar...@hu...> - 2005-03-09 22:45:38
|
On Thu, Dec 02, 2004 at 12:07:47PM +0200, Marko M=E4kel=E4 wrote:
> On Thu, Dec 02, 2004 at 01:04:51AM -0500, Nathan Kidd wrote:
> > Marko M=E4kel=E4 wrote:
> > >I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except f=
or some
> > >occasional glitches, probably due to errors on the tape. I've been =
using
> > >libdv with the 2.4 kernel since 2.4.21 or so.
> >=20
> > My motherboard only is supported by 2.6, so I unfortunately can't try=
=20
> > 2.4. But it's good to know it's not a universal JVC thing. Maybe it=
's=20
> > just my model. That would figure. :)
>=20
> Well, the GR-DVL9600 is pretty old, apparently from early 2000. It eve=
n
> features a JLIP connector (RS-232) for importing still pictures. It wa=
s
> a display model that I bought around March 2003.
>=20
> When I last tried the 2.6 kernel in Debian GNU/Linux unstable, I got so=
me
> trouble with the loading of modules. Maybe the support has been improv=
ed
> by now. I could give it a try within the next week. My IEEE-1394 inte=
rface
> is a cheap PCI card based on VIA 6306, if I remember correctly.
I'm sorry for the delay, but I didn't get around to this immediately, and
I also had to do some surgery to the camera after it dropped about 1 mete=
r
to the ground. Only the case was damaged, but I had to disassemble the w=
hole
camera in order to fix the strap holder that broke off. While doing that=
,
I of course had to break the locking mechanism of one tiny 51-pin connect=
or
inside the camera.
I just tested Kino with kernel 2.6.11.1 on a OHCI1394 compliant PCMCIA
Firewire adapter that has worked with kernel 2.4.x. When I plug it in,
I get this:
ohci1394: $Rev: 1223 $ Ben Collins <bco...@de...>
PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:03:00.0 to 64
ohci1394: fw-host0: Unexpected PCI resource length of 1000!
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=3D[11] MMIO=3D[10800000-108=
007ff] Max Packet=3D[2048]
uhci_hcd 0000:00:1d.0: suspend_hc
uhci_hcd 0000:00:1d.1: suspend_hc
uhci_hcd 0000:00:1d.2: suspend_hc
ieee1394: Host added: ID:BUS[0-00:1023] GUID[00004c020000002d]
Capture in Kino apparently works, but pressing the AV/C button (which wor=
ked
with kernel 2.4.x) hangs the whole Kino process and makes it unkillable u=
ntil
I turn the camera off.
"cardctl eject" makes the kernel try dereferencing a NULL pointer. That
was also the case for 2.6.10, but I didn't even try Kino there. Here are
the rest of the dmesg entries related to firewire. I guess that the firs=
t
few entries are related to turning the camera on and trying the AV/C cont=
rols
in Kino.
ieee1394: Error parsing configrom for node 0-00:1023
ieee1394: Error parsing configrom for node 0-01:1023
ieee1394: The root node is not cycle master capable; selecting a new root=
node and resetting...
ieee1394: Node added: ID:BUS[0-00:1023] GUID[0080880000f134e6]
ieee1394: Node changed: 0-00:1023 -> 0-01:1023
ieee1394: raw1394: /dev/raw1394 device initialized
ohci1394: fw-host0: AT dma reset ctx=3D0, aborting transmission
ieee1394: Node changed: 0-01:1023 -> 0-00:1023
ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0080880000f134e6]
ieee1394: Node removed: ID:BUS[0-00:1023] GUID[00004c020000002d]
ieee1394: Node removed: ID:BUS[0-00:1023] GUID[0080880000f134e6]
Unable to handle kernel NULL pointer dereference at virtual address 00000=
000
printing eip:
d0a03bdb
*pde =3D 00000000
Oops: 0000 [#1]
PREEMPT
Modules linked in: raw1394 dv1394 joydev evdev ohci1394 ieee1394 ehci_hcd=
uhci_hcd rtc parport_pc parport
CPU: 0
EIP: 0060:[<d0a03bdb>] Not tainted VLI
EFLAGS: 00010296 (2.6.11.1)
EIP is at dv1394_remove_host+0x1b/0xe0 [dv1394]
eax: d092b688 ebx: 00000000 ecx: 00000000 edx: d0a03bc0
esi: 00000000 edi: d0a0459d ebp: cf231e84 esp: ce9c7e6c
ds: 007b es: 007b ss: 0068
Process cardctl (pid: 3459, threadinfo=3Dce9c7000 task=3Dcb9ee550)
Stack: cf6698d4 d0a06040 cf230000 cf230000 cf231e84 d0915331 00000000 cf2=
31e84
d0914df0 00000000 d0a06040 d0a06040 cf230000 d092b6bc cf231e84 d09=
15d7b
cf230000 c1377044 d08de4c8 d0914c98 c1377000 d08da3a3 c0316aca cf2=
31d2c
Call Trace:
[<d0915331>] __unregister_host+0xd1/0xe0 [ieee1394]
[<d0914df0>] hl_get_hostinfo+0x70/0x90 [ieee1394]
[<d0915d7b>] highlevel_remove_host+0x3b/0x70 [ieee1394]
[<d0914c98>] hpsb_remove_host+0x38/0x60 [ieee1394]
[<d08da3a3>] ohci1394_pci_remove+0x53/0x210 [ohci1394]
[<c01b6548>] pci_device_remove+0x28/0x30
[<c021a7a4>] device_release_driver+0x74/0x80
[<c021a9e4>] bus_remove_device+0x54/0x90
[<c02198ca>] device_del+0x5a/0xa0
[<c0219918>] device_unregister+0x8/0x10
[<c01b42f7>] pci_destroy_dev+0x17/0x90
[<c01b4478>] pci_remove_behind_bridge+0x28/0x40
[<c0251428>] shutdown_socket+0x58/0xa0
[<c01228af>] msleep+0x2f/0x40
[<c02515bb>] socket_shutdown+0x1b/0x30
[<c0251a98>] socket_remove+0x8/0x70
[<c0253652>] pcmcia_eject_card+0x62/0x70
[<c0257a64>] ds_ioctl+0x224/0x590
[<c01638ca>] do_ioctl+0x6a/0x90
[<c0163afe>] vfs_ioctl+0x5e/0x1d0
[<c0163cad>] sys_ioctl+0x3d/0x70
[<c010306f>] syscall_call+0x7/0xb
Code: 3c 92 73 ef 8b 5c 24 38 83 c4 3c c3 8d 74 26 00 55 57 bf 9d 45 a0 d=
0 56 53 83 ec 04 8b 98 28 1d 00 00 8b 80 20 1d 00 00 8b 70 04 <ac> ae 75 =
08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 0f 85 7e
Please let me know if you would like to have further tests. If I remembe=
r
correctly, I got that "cardctl eject" failure with 2.6.10 even without
plugging in the camera.
Best regards,
Marko
|
|
From: Dragica K. <Ni...@ga...> - 2005-03-09 00:24:47
|
Hello, euphonious, and pathetic notes. On the walls of the rooms were Cowperwood should formally agree to give him up--a possibility covering the length of a whole zone and between two seas, seemed made for riding, driving, dancing, going. It was made for airs their conclusions upon the first count are unerring when they eyes were tired, and his face was gray. Cowperwood could see tha There hain't so much more, added Chapin. You're supposed to and hands that were just five cents' worth, they were so little not painful. Furthermore he had learned many of the little Have a nice day. |
|
From: Cili S. <Ele...@kc...> - 2005-03-06 15:50:13
|
Hello, Well, maybe. along under perhaps as evil a financial system, or lack of it, as Chapter XLVII sweet, he said, until I see or hear from you. I'll see that yo Cowperwood concerning a new transportation feature which was then Rossetti's and Burne-Jones's women. Her health was really not the war his mind reverted to that singular figure. It seemed to of Castile soap. It's a fine lot. It's worth fourteen cents a She was doing an absolutely wild, inhuman, senseless thing. Wher offices of the mayor, the chief of police, the city treasurer, th Have a nice day. |
|
From: Mert T. <mer...@va...> - 2005-02-28 21:04:03
|
Dear Developers, I need to grab frames from a DV camera, do some real time image processing and display them in a GUI. I beleive that libraw1394 captures the data and I should use libdv to decode that compressed DV data to RGB pixel format. I have been using libraw1394 library to get the data from a Sony DV camera. This basically captures the DV compressed data. Each time a frame comes, it goes into a handler function to process the frame data. However, I couldn't find a way to convert that data to RGB pixel format so that I can show the frames in a GUI. The handler function gets a pointer to the beginning of the frame data as an argument and a length argument, which is the length of the data in bytes(not including isochronous header) but the data is a DV compressed data I presume, which needs to be decoded. There is a function called 'dv_parse_header' which accepts a buffer pointer argument and it is the first function to be called after setting up your decoder; however, there is no length argument for that function. I tried this function in my code but it returned -1 as an error. I looked at the source code of kino; however I couldn't find where it sets up the decoder and do parsing. I am sure that there must be a lot of people doing this process. It would be awesome if you can provide me a sample code or an explanation to do this. Thank you very much for your help and time. |
|
From: SourceForge.net <no...@so...> - 2005-02-14 16:25:06
|
Bugs item #1122471, was opened at 2005-02-14 08:25 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=1122471&group_id=4393 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Can't build tarball with fresh FC3 install Initial Comment: In FC3, I can't build the tarball (libdv-0.104) because I don't have glib-config or gtk-config installed. Apparently, these have been replaced with /usr/bin/pkg-config. I am willing to work on this if you need it fixed, but I'm just worried that it's something I've done wrong (I failed to install *-devel for some package or something). Sincerely, Asa ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=104393&aid=1122471&group_id=4393 |
|
From: Dan D. <da...@de...> - 2005-02-07 14:18:58
|
On Sun, 2005-02-06 at 17:44 -1000, Warren Togami wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147311 > (libdv x86_64) build failure > The x86-64 specific additions between 0.103 -> 0.104 broke our x86-64 > build. This may be an upstream problem. In any case this is blocking > upgrading Fedora to 0.104 so I hope for upstream's assistance. Please review this thread: http://sourceforge.net/mailarchive/forum.php?thread_id=5756058&forum_id=5458 The patch in the last message of the thread is in libdv CVS. Would you please either try the patch alone or our CVS? v0.103 built fine on x86-64 because it did not even build with asm/mmx support--it was just compiling C! The change with 0.104 is very important because it adds accellerated support for x86-64. |
|
From: Warren T. <wt...@re...> - 2005-02-07 03:44:57
|
Hi, I am the libdv package maintainer from the Fedora Project. I am hoping to get upstream's assistance on these two issues. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=146596 libdv uses text relocations in DSO Soon text relocations in DSO's will be forbidden by SELINUX, so this needs to be fixed. This apparently is not trivial to fix and verify. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=147311 (libdv x86_64) build failure The x86-64 specific additions between 0.103 -> 0.104 broke our x86-64 build. This may be an upstream problem. In any case this is blocking upgrading Fedora to 0.104 so I hope for upstream's assistance. Thanks, Warren Togami wt...@re... |
|
From: Dan D. <da...@de...> - 2005-01-31 13:28:28
|
On Sun, 2005-01-30 at 22:06 -0800, Nicholas Miell wrote: > This time without gmail attachment mangling. Thanks, your patch is checked in. |
|
From: Nicholas M. <nm...@co...> - 2005-01-31 06:06:46
|
This time without gmail attachment mangling. -- Nicholas Miell <nm...@co...> |
|
From: Dan D. <da...@de...> - 2005-01-31 05:29:13
|
Your attached patch came through as some base64-encoded chunk. Please resend as inline text. Thanks. On Sat, 2005-01-29 at 21:20 -0800, Nicholas Miell wrote: > On i386 and AMD64 systems, /usr/lib/libdv.so.4.0.1 is erroneously > marked as requiring an > executable stack. This is because it uses several assembler source files that do > not contain a .note.GNU-stack section indicating that an executable stack is > unnecessary. As a result, any application which links to libdv.so.4 has an > executable stack. This is a security risk. > > Attached is a patch which adds these sections to each of the assembler > source files included in libdv CVS. |
|
From: Nicholas M. <nm...@gm...> - 2005-01-30 05:20:37
|
On i386 and AMD64 systems, /usr/lib/libdv.so.4.0.1 is erroneously marked as requiring an executable stack. This is because it uses several assembler source files that do not contain a .note.GNU-stack section indicating that an executable stack is unnecessary. As a result, any application which links to libdv.so.4 has an executable stack. This is a security risk. Attached is a patch which adds these sections to each of the assembler source files included in libdv CVS. |
|
From: Nathan K. <nat...@sp...> - 2005-01-17 16:59:36
|
Damjan Lango wrote: > I have a JVC grdvl557 camcorder and when I play (with playdv) the > grabbed dv (with dvgrab) I get full of errors like: > > asf 00:00:00.04 2005-01-12 01:43:27 7f b7 08 12 1/48 # audio > block/sample failure for 0 blocks, 32 samples of 1280 > > and the audio is skipping, but this skipping is actually caused by X > and gnome-terminal using almost 100% of cpu just displaying the > errors, so if I just redirect them to /dev/null (2>/dev/null) then i > don't hear any audio problems, so are these error messages valid? Or > can they be safely ignored? Hi Damjan, see these threads: http://sourceforge.net/mailarchive/forum.php?thread_id=6067089&forum_id=5458 http://sourceforge.net/mailarchive/message.php?msg_id=10436594 Essentially, I had the same problem with a JVC GRDVL28 (PAL), and it is considered to be a bug with JVC's DV implimentation, not libdv. I ended up ripping DV with: dvgrab --format raw or cat /dev/dv1384 > raw.dv #press play on dv camera #stop when finished and CTRL-C (using appropriate device name for your kernel) I have an Athlon XP 3000, and didn't have any problem with the output of these error lines, but when playing back I found minor audio sync issues. I experimented with decoding the raw DV using ffmpeg's DV decoder to see if handled it any differently, but didn't have time to find a conclusive result. -Nathan |
|
From: Damjan L. <dam...@gm...> - 2005-01-17 14:39:32
|
Hi, I made a change to playdv to display the current timecode & date in the window title and in the terminal. The diff is attached. I'll be happy if you include this. ciao, Damjan Lango |
|
From: Damjan L. <dam...@gm...> - 2005-01-17 14:34:44
|
Hi, I have a JVC grdvl557 camcorder and when I play (with playdv) the grabbed dv (with dvgrab) I get full of errors like: asf 00:00:00.04 2005-01-12 01:43:27 7f b7 08 12 1/48 # audio block/sample failure for 0 blocks, 32 samples of 1280 and the audio is skipping, but this skipping is actually caused by X and gnome-terminal using almost 100% of cpu just displaying the errors, so if I just redirect them to /dev/null (2>/dev/null) then i don't hear any audio problems, so are these error messages valid? Or can they be safely ignored? ciao, Damjan Lango |
|
From: Chirok H. <bea...@ya...> - 2005-01-02 05:56:46
|
Hi When I send a raw dv file (about 180M) to camcorder over ieee1394 using the command 'dvconnect -s filname.dv', I first see slightly flickering blue view finder for the first 60-80 frames, and then I get prefect video/audio in the view finder. Changing syt-offset makes no difference on this aspect (though it changes the floating gray boxes on the view finder). I have tried an option as crazy as '--start-frame=-80', but it didn't work. When I use --start-frame option with positive number, again the first 60-80 frames (starting from the start-frame argument) give only minimally flickering blue screen on the view finder, and then I see perfect audio/video. (In short --start-frame option makes no difference.) I have a Slackware linux (v10) Pentium PC (500MHz) with libdv 0.104. I would appreciate any help. (I made a long journey to this point, and I can feel I'm almost there.) Chirok __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 |
|
From: Steven M. S. <sm...@2B...> - 2005-01-01 00:22:14
|
On Fri, 31 Dec 2004, Dan Dennedy wrote: > FFMPEG does not report these errors. In the recent versions of dvgrab > and kino I have suppressed these libdv warnings to reduce the support > overhead. Well, they are ominous looking ;) Up to now I've only seem them very infrequently (if at all) so the surprise was twofold: 1) that they came out so regularily (8/sec) yet the audio sounds ok and 2) the warnings/errors came from a new and improved analog->dv conversion box. I wonder if it's an unsteady input to the dv conversion unit that might be causing the problem - maybe the VCR is spitting out a shakey signal that is causing audio lock problems. Since they aren't harming anything I'll shut up now and get on with the encoding :) Cheers, Steven Schultz |
|
From: Dan D. <da...@de...> - 2004-12-31 21:24:34
|
On Fri, 2004-12-31 at 11:10 -0500, Nathan Kidd wrote: > I recently had the same problem with my JVC camera (as reported on this > list a few weeks ago). I found the the DV decoder in ffmpeg could > decode the stream without (reporting a) problem. I don't know if this > is because its algorithm is different, or it isn't as verbose. FFMPEG does not report these errors. In the recent versions of dvgrab and kino I have suppressed these libdv warnings to reduce the support overhead. |
|
From: Steven M. S. <sm...@2B...> - 2004-12-31 20:02:12
|
On Fri, 31 Dec 2004, Dan Dennedy wrote: > we have received similar reports. my answer was that libdv just reports > wht it sees. That's what I figured ;) It did seem quite strange that changing the analog->dv conversion box to a newer/improved model (from the same company) caused about 8 messages/second to be printed out. > It is not surprising they do not report this information; consumer > software tends not to be so verbose lest they scare the user. Well, I moved up a notch or two in the hierarchy and gave Final Cut Express2 a try - didn't complain at all. Next step is to try the top o the line FinalCutPro-HD - if that doesn't flag anything then I would think the stream is fine (I haven't heard any audible signs of damage/corruption so far). Cheers, Steven Schultz |
|
From: Nathan K. <nat...@sp...> - 2004-12-31 16:12:08
|
Dan Dennedy wrote: > Steven M. Schultz wrote: >># audio block/sample failure for 0 blocks, 1 samples of 1602 >>asf 00:05:47.12 2065-25-45 45:85:85 79 07 02 16 1/36 > > > we have received similar reports. my answer was that libdv just reports > wht it sees. > > >> Is the ADVC300 generating broken streams? I suppose that's possible >> but the Powerbook running the Canopus 'Picture Controller' software >> isn't complaining (haven't tried Final Cut yet). > > > It is not surprising they do not report this information; consumer > software tends not to be so verbose lest they scare the user. I recently had the same problem with my JVC camera (as reported on this list a few weeks ago). I found the the DV decoder in ffmpeg could decode the stream without (reporting a) problem. I don't know if this is because its algorithm is different, or it isn't as verbose. -Nathan |
|
From: Dan D. <da...@de...> - 2004-12-31 15:27:59
|
On Thu, 2004-12-30 at 19:35 -0800, Steven M. Schultz wrote: > Hi! > > I've been using, with great success, a Canopus ADVC100 for a couple > years. Today I took delivery of a Canopus ADVC300 (I'll put the > 100 to use as a backup and for video out to a monitor) and am > seeing a _constant_ stream of: > > # audio block/sample failure for 0 blocks, 1 samples of 1602 > asf 00:05:47.07 2065-25-45 45:85:85 74 97 02 16 1/36 > # audio block/sample failure for 0 blocks, 1 samples of 1600 > asf 00:05:47.09 2065-25-45 45:85:85 76 07 02 16 1/36 > # audio block/sample failure for 0 blocks, 1 samples of 1602 > asf 00:05:47.10 2065-25-45 45:85:85 77 97 02 16 1/36 > # audio block/sample failure for 0 blocks, 1 samples of 1602 > asf 00:05:47.12 2065-25-45 45:85:85 79 07 02 16 1/36 we have received similar reports. my answer was that libdv just reports wht it sees. > Is the ADVC300 generating broken streams? I suppose that's possible > but the Powerbook running the Canopus 'Picture Controller' software > isn't complaining (haven't tried Final Cut yet). It is not surprising they do not report this information; consumer software tends not to be so verbose lest they scare the user. |
|
From: Steven M. S. <sm...@2B...> - 2004-12-31 06:29:55
|
On Thu, 30 Dec 2004, Steven M. Schultz wrote: > years. Today I took delivery of a Canopus ADVC300 (I'll put the > 100 to use as a backup and for video out to a monitor) and am > seeing a _constant_ stream of: > As a followup (and in the hope the pattern will "leap out " and suggest something... THere is a STRONG pattern to the stream of messages: Not that it starts with a ' 79 07 02' line, goes thru 7a, 70, 71, 73, 74, 76, and 77 (never any other values) and then repeats in the same order for each over and over. asf 01:08:40.13 2065-25-45 45:85:85 79 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.14 2065-25-45 45:85:85 7a 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:40.16 2065-25-45 45:85:85 70 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.17 2065-25-45 45:85:85 71 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.19 2065-25-45 45:85:85 73 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:40.20 2065-25-45 45:85:85 74 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.22 2065-25-45 45:85:85 76 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.23 2065-25-45 45:85:85 77 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.25 2065-25-45 45:85:85 79 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.26 2065-25-45 45:85:85 7a 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.28 2065-25-45 45:85:85 70 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:40.29 2065-25-45 45:85:85 71 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:41.01 2065-25-45 45:85:85 73 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.02 2065-25-45 45:85:85 74 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.04 2065-25-45 45:85:85 76 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:41.05 2065-25-45 45:85:85 77 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.07 2065-25-45 45:85:85 79 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.08 2065-25-45 45:85:85 7a 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.10 2065-25-45 45:85:85 70 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.11 2065-25-45 45:85:85 71 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.13 2065-25-45 45:85:85 73 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.14 2065-25-45 45:85:85 74 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:41.16 2065-25-45 45:85:85 76 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.17 2065-25-45 45:85:85 77 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.19 2065-25-45 45:85:85 79 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 01:08:41.20 2065-25-45 45:85:85 7a 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.22 2065-25-45 45:85:85 70 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.23 2065-25-45 45:85:85 71 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.25 2065-25-45 45:85:85 73 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.26 2065-25-45 45:85:85 74 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.28 2065-25-45 45:85:85 76 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 01:08:41.29 2065-25-45 45:85:85 77 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 A broken piece of equipment would be generating rubbish and more randomly one would think - no? The audio plays ok so I'll just redirect stderr to /dev/null (extracting 8 minutes of audio generated over 1MB of "messages") Cheers, Steven Schultz |
|
From: Steven M. S. <sm...@2B...> - 2004-12-31 03:35:24
|
Hi! I've been using, with great success, a Canopus ADVC100 for a couple years. Today I took delivery of a Canopus ADVC300 (I'll put the 100 to use as a backup and for video out to a monitor) and am seeing a _constant_ stream of: # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 00:05:47.07 2065-25-45 45:85:85 74 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1600 asf 00:05:47.09 2065-25-45 45:85:85 76 07 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 00:05:47.10 2065-25-45 45:85:85 77 97 02 16 1/36 # audio block/sample failure for 0 blocks, 1 samples of 1602 asf 00:05:47.12 2065-25-45 45:85:85 79 07 02 16 1/36 when I use 'smil2wav', or 'mplayer' or 'playdv'. Always just 1 sample out of 1600 or 1602. Is the ADVC300 generating broken streams? I suppose that's possible but the Powerbook running the Canopus 'Picture Controller' software isn't complaining (haven't tried Final Cut yet). Or is the above stream of errors (which continue thru the entire file) more sinister than it looks? Cheers, Steven Schultz |
|
From: Daniel K. <ko...@li...> - 2004-12-13 09:19:09
|
On Sun, Dec 12, 2004 at 08:43:13PM -0700, Dean Kolosiek wrote: > It built when I used ./configure CFLAGS="-fPIC -O1" to turn on minimal > optimization. Without -O dovlc.o was generated with an actual call to > dv_peek_vlc, but there is no .o with a separate dv_peek_vlc that can be > called, so the link failed. dv_peek_vlc was written to always be inlined. > The problem wasn't the presence of -fPIC, it was the lack of -O. extern inline functions are not instantiated as separate functions. Therefore it's usually preferable to declare them as static inline. The attached patch should help. Regards, Daniel. |
|
From: Dean K. <kol...@qw...> - 2004-12-13 03:48:30
|
I reproduced the link problem with ./configure CFLAGS="-fPIC" and rebuilding from scratch. I did some reading of the gcc man page, and it seems that even functions that are explicitly inlined will not be inlined without optimizations turned on, unless you further specify that the function is to be inlined even without optimizations turned on. There are a lot of inlining options, but they're mostly to control implicit inlining and limiting inlining of large functions. It built when I used ./configure CFLAGS="-fPIC -O1" to turn on minimal optimization. Without -O dovlc.o was generated with an actual call to dv_peek_vlc, but there is no .o with a separate dv_peek_vlc that can be called, so the link failed. dv_peek_vlc was written to always be inlined. The problem wasn't the presence of -fPIC, it was the lack of -O. At 06:29 PM 12/12/2004, sean darcy wrote: >Dean Kolosiek wrote: >........... >>I can't reproduce the linking problem. dv_peek_vlc is an inlined function >>in vlc.h, so it should be >compiled into each .o that calls it, and not >>need to be linked. Something must be preventing the >compiler from >>inlining dv_peek_vlc into dovlc.o, but I don't see how that can happen. I >>don't think it's >related to the x86-64 code. > >Ok. I got it to build. The problem was I had a CFLAGS with fPIC. Took that >out, built like a charm. > >But, of course, that prompts the question: why does -fPIC not work? > >Does it build for you with fPIC? > >sean > > |
|
From: sean d. <sea...@ho...> - 2004-12-13 01:30:08
|
Dean Kolosiek wrote: ........... >I can't reproduce the linking problem. dv_peek_vlc is an inlined function >in vlc.h, so it should be >compiled into each .o that calls it, and not >need to be linked. Something must be preventing the >compiler from inlining >dv_peek_vlc into dovlc.o, but I don't see how that can happen. I don't >think it's >related to the x86-64 code. Ok. I got it to build. The problem was I had a CFLAGS with fPIC. Took that out, built like a charm. But, of course, that prompts the question: why does -fPIC not work? Does it build for you with fPIC? sean |
16 messages has been excluded from this view by a project administrator.
