Menu
▾
▴
libdv-dev
|
From: Nathan K. <nat...@ya...> - 2004-12-01 05:54:02
|
Hello,
Whenever I dump DV from my JVC camera I get continuous lines like:
asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48
...above repeated 30 times...
# audio block/sample failure for 0 blocks, 60 samples of 1280
The resulting audio stream sounds odd, with little breaks in it. (As one
might expect if 60 out of every 1280 audio samples were bad.)
Details:
--------
Camera: JVC GR-DVL28 (PAL)
OS: Mandrake 10, 2.6 kernel
Libdv: libdv 0.102 (libdv4-0.102-1mdk.rpm package)
Other libs: libraw1394_5-0.9.0-4mdk, libdc1394_0-0.9.2-1mdk,
libavc1394_0-0.4.1-4mdk
This problem occurs consistently and immediately with dvgrab 1.5/1.6 and
Cinelerra 1.2.1.
Running the command
dvgrab testvideo
immediately shows the "audio failure" output lines listed above.
I searched google and this list's archives, and the only reference to
this I could find was
https://core.fluendo.com/trac/cgi-bin/trac.cgi/ticket/67
which suggests there is a problem with JVC cameras and libdv.
So my questions: Has anyone else experienced this? Is this a known
problem? Is there any workaround/fix? Is there any more info I should
supply?
I'd be grateful for any suggestions on how to debug this further.
Thanks to the developers (Buck and Dan especially) for making this lib!
Best Regards,
-Nathan
|
|
From: Marko <mar...@hu...> - 2004-12-01 07:47:16
|
Hi Nathan, > Whenever I dump DV from my JVC camera I get continuous lines like: > > asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48 > ...above repeated 30 times... > # audio block/sample failure for 0 blocks, 60 samples of 1280 > > The resulting audio stream sounds odd, with little breaks in it. (As one > might expect if 60 out of every 1280 audio samples were bad.) > > Details: > -------- > Camera: JVC GR-DVL28 (PAL) > OS: Mandrake 10, 2.6 kernel > Libdv: libdv 0.102 (libdv4-0.102-1mdk.rpm package) > Other libs: libraw1394_5-0.9.0-4mdk, libdc1394_0-0.9.2-1mdk, > libavc1394_0-0.4.1-4mdk [..] > https://core.fluendo.com/trac/cgi-bin/trac.cgi/ticket/67 > which suggests there is a problem with JVC cameras and libdv. > > So my questions: Has anyone else experienced this? Is this a known > problem? Is there any workaround/fix? Is there any more info I should > supply? I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except for 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. On a somewhat related note, there's a DV camera based backup utility whose name escapes me right now. My camera refused to record anything created by that utility with the default settings. If I remember correctly, there was some option that generated silent audio instead of using the audio bandwidth for the payload. With that option, my camera recorded the data. However, playback didn't work reliably, even though I used the accompanying program that adds redundance and spreads each byte across several blocks. Marko |
|
From: Nathan K. <nat...@sp...> - 2004-12-02 06:00:39
|
Marko Mäkelä wrote: > Nathan Kidd wrote: > > So my questions: Has anyone else experienced this? Is this a known > > problem? Is there any workaround/fix? Is there any more info I should > > supply? > > > I have a JVC GR-DVL9600 (PAL), and audio has worked for me, except for 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. My motherboard only is supported by 2.6, so I unfortunately can't try 2.4. But it's good to know it's not a universal JVC thing. Maybe it's just my model. That would figure. :) Thanks, -Nathan |
|
From: Marko <mar...@hu...> - 2004-12-02 10:08:15
|
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 for= some > >occasional glitches, probably due to errors on the tape. I've been us= ing > >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. :) Well, the GR-DVL9600 is pretty old, apparently from early 2000. It even features a JLIP connector (RS-232) for importing still pictures. It was a display model that I bought around March 2003. When I last tried the 2.6 kernel in Debian GNU/Linux unstable, I got some trouble with the loading of modules. Maybe the support has been improved by now. I could give it a try within the next week. My IEEE-1394 interf= ace is a cheap PCI card based on VIA 6306, if I remember correctly. Marko |
|
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: Dan D. <da...@de...> - 2005-03-10 13:53:37
|
Right now, module removal of ieee1394 modules under kernel 2.6 is known to be problematic. None of the kernel messages shown are alarming except, of course, the Oops on card eject. None of the messages relate to AV/C deadlocking Kino. Can you test if transport control in dvcont or gscanbus works OK? On Thu, 2005-03-10 at 00:45 +0200, Marko M=E4kel=E4 wrote: > 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= for some > > > >occasional glitches, probably due to errors on the tape. I've bee= n 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 t= ry=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 e= ven > > features a JLIP connector (RS-232) for importing still pictures. It = was > > 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 = some > > trouble with the loading of modules. Maybe the support has been impr= oved > > by now. I could give it a try within the next week. My IEEE-1394 in= terface > > is a cheap PCI card based on VIA 6306, if I remember correctly. >=20 > I'm sorry for the delay, but I didn't get around to this immediately, a= nd > I also had to do some surgery to the camera after it dropped about 1 me= ter > to the ground. Only the case was damaged, but I had to disassemble the= whole > camera in order to fix the strap holder that broke off. While doing th= at, > I of course had to break the locking mechanism of one tiny 51-pin conne= ctor > inside the camera. >=20 > 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: >=20 > 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-1= 08007ff] 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] >=20 > Capture in Kino apparently works, but pressing the AV/C button (which w= orked > with kernel 2.4.x) hangs the whole Kino process and makes it unkillable= until > I turn the camera off. >=20 > "cardctl eject" makes the kernel try dereferencing a NULL pointer. Tha= t > was also the case for 2.6.10, but I didn't even try Kino there. Here a= re > the rest of the dmesg entries related to firewire. I guess that the fi= rst > few entries are related to turning the camera on and trying the AV/C co= ntrols > in Kino. >=20 > 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 ro= ot 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 000= 00000 > printing eip: > d0a03bdb > *pde =3D 00000000 > Oops: 0000 [#1] > PREEMPT > Modules linked in: raw1394 dv1394 joydev evdev ohci1394 ieee1394 ehci_h= cd 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 c= f231e84 > d0914df0 00000000 d0a06040 d0a06040 cf230000 d092b6bc cf231e84 d= 0915d7b > cf230000 c1377044 d08de4c8 d0914c98 c1377000 d08da3a3 c0316aca c= f231d2c > 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= d0 56 53 83 ec 04 8b 98 28 1d 00 00 8b 80 20 1d 00 00 8b 70 04 <ac> ae 7= 5 08 84 c0 75 f8 31 c0 eb 04 19 c0 0c 01 85 c0 0f 85 7e >=20 > Please let me know if you would like to have further tests. If I remem= ber > correctly, I got that "cardctl eject" failure with 2.6.10 even without > plugging in the camera. >=20 > Best regards, >=20 > Marko >=20 >=20 > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dclick > _______________________________________________ > libdv-dev mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdv-dev |
|
From: Marko <mar...@hu...> - 2005-03-18 08:12:00
|
Dan, On Thu, Mar 10, 2005 at 08:46:39AM -0500, Dan Dennedy wrote: > Right now, module removal of ieee1394 modules under kernel 2.6 is known > to be problematic. None of the kernel messages shown are alarming > except, of course, the Oops on card eject. None of the messages relate > to AV/C deadlocking Kino. Can you test if transport control in dvcont or > gscanbus works OK? gscanbus became unkillable and entered a busy loop (presumably in the kernel) either as the result of changing my camera from record mode (via power-off) to play mode, or attempting to click the mouse on the camera icon. During this test, the following was displayed on stdout or stderr: Error while reading from IEEE1394: : Resource temporarily unavailable 0/0x0000fffff000040c: read failed Error while reading from IEEE1394: : Resource temporarily unavailable 0/0x0000fffff0000410: read failed Error while reading from IEEE1394: : Resource temporarily unavailable 0/0x0000fffff0000414: read failed Error while reading from IEEE1394: : Resource temporarily unavailable 1/0x0000fffff0000400: read failed 1/0x0000fffff0000400: wrong bus info block length Error while reading from IEEE1394: : Resource temporarily unavailable Error while reading from IEEE1394: : Resource temporarily unavailable Could not read topologyMap Error while reading from IEEE1394: : Resource temporarily unavailable Error while reading from IEEE1394: : Resource temporarily unavailable Could not read topologyMap Error while reading from IEEE1394: : Resource temporarily unavailable 1/0x0000fffff0000400: read failed 1/0x0000fffff0000400: wrong bus info block length Error while reading from IEEE1394: : Invalid argument Could not read topologyMap Error while reading from IEEE1394: : Resource temporarily unavailable 0/0x0000fffff000040c: read failed After rebooting, "dvcont verbose play" displayed node 0 type = 2 and hanged (but didn't consume any noticeable amount of processing power) until I turned off the camera (it was in play mode). After that point, it printed: node 0 AVC video recorder? no node 0 AVC disk recorder? no node 0 AVC tuner? no node 0 AVC video camera? no node 0 AVC video monitor? no Could not find any AV/C devices on the 1394 bus. Before the dvcont test, the relevant dmesg output was as follows: 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! uhci_hcd 0000:00:1d.1: suspend_hc ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[11] MMIO=[10800000-108007ff] Max Packet=[2048] uhci_hcd 0000:00:1d.2: suspend_hc ieee1394: Host added: ID:BUS[0-00:1023] GUID[00004c020000002d] After turning on the camera, the following was logged: 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 atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed. Nothing further was printed when dvcont was hanging. After I turned off the camera, the following was printed: isa0060/serio0 reports too many keys pressed. ohci1394: fw-host0: AT dma reset ctx=0, aborting transmission ieee1394: Node changed: 0-01:1023 -> 0-00:1023 ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[0080880000f134e6] atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed. Do you need the lspci output, or is there anything else I could do to help debug this, such as adding some debugging output to the 2.6.11.1 kernel? This Intel Centrino based system has an Intel 82855PM chipset, Texas Instruments PCI4520 Cardbus controller and NEC Corporation IEEE 1394 Host Controller (rev 01). AV/C has worked fine under 2.4 kernels using the same hardware. Marko |
|
From: <ilu...@gm...> - 2004-12-01 22:52:27
|
Hi, saw pretty much the same problem with a JVC. Different model, though. Should still be in the list archives. We replaced the camera with a different make ;-) On Wed, 01 Dec 2004 00:58:13 -0500, Nathan Kidd <nat...@ya...> wrote: > Hello, > > Whenever I dump DV from my JVC camera I get continuous lines like: > > asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48 > ...above repeated 30 times... > # audio block/sample failure for 0 blocks, 60 samples of 1280 > > The resulting audio stream sounds odd, with little breaks in it. (As one > might expect if 60 out of every 1280 audio samples were bad.) |
|
From: Nathan K. <nat...@sp...> - 2004-12-02 06:10:30
|
Ingo Lütkebohle wrote: > saw pretty much the same problem with a JVC. Different model, though. > Should still be in the list archives. We replaced the camera with a > different make ;-) Similar in that they were audio-related, though I note the errors and problem behaviour are quite different. Buying a new camera wasn't the solution I was hoping for. ;) -Nathan > On Wed, 01 Dec 2004 00:58:13 -0500, Nathan Kidd wrote: > >>Hello, >> >>Whenever I dump DV from my JVC camera I get continuous lines like: >> >> asf 00:00:00.00 2000-00-00 00:00:00 70 b7 08 12 2/48 >> ...above repeated 30 times... >> # audio block/sample failure for 0 blocks, 60 samples of 1280 >> >>The resulting audio stream sounds odd, with little breaks in it. (As one >>might expect if 60 out of every 1280 audio samples were bad.) > > > |
