linux1394-devel Mailing List for IEEE 1394 for Linux (Page 536)
Brought to you by:
aeb,
bencollins
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
(39) |
Apr
(154) |
May
(172) |
Jun
(237) |
Jul
(127) |
Aug
(135) |
Sep
(193) |
Oct
(175) |
Nov
(173) |
Dec
(148) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(161) |
Feb
(225) |
Mar
(193) |
Apr
(158) |
May
(179) |
Jun
(292) |
Jul
(146) |
Aug
(134) |
Sep
(185) |
Oct
(190) |
Nov
(149) |
Dec
(161) |
2002 |
Jan
(186) |
Feb
(236) |
Mar
(254) |
Apr
(207) |
May
(189) |
Jun
(182) |
Jul
(202) |
Aug
(155) |
Sep
(149) |
Oct
(449) |
Nov
(191) |
Dec
(108) |
2003 |
Jan
(174) |
Feb
(242) |
Mar
(243) |
Apr
(255) |
May
(202) |
Jun
(290) |
Jul
(237) |
Aug
(178) |
Sep
(101) |
Oct
(153) |
Nov
(144) |
Dec
(95) |
2004 |
Jan
(162) |
Feb
(278) |
Mar
(282) |
Apr
(152) |
May
(127) |
Jun
(138) |
Jul
(94) |
Aug
(63) |
Sep
(64) |
Oct
(150) |
Nov
(102) |
Dec
(197) |
2005 |
Jan
(102) |
Feb
(172) |
Mar
(89) |
Apr
(158) |
May
(139) |
Jun
(160) |
Jul
(288) |
Aug
(89) |
Sep
(201) |
Oct
(92) |
Nov
(190) |
Dec
(139) |
2006 |
Jan
(121) |
Feb
(204) |
Mar
(133) |
Apr
(134) |
May
(91) |
Jun
(226) |
Jul
(122) |
Aug
(101) |
Sep
(144) |
Oct
(141) |
Nov
|
Dec
|
2023 |
Jan
(19) |
Feb
(1) |
Mar
(5) |
Apr
(5) |
May
(33) |
Jun
(17) |
Jul
|
Aug
|
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(40) |
2024 |
Jan
(26) |
Feb
(14) |
Mar
(26) |
Apr
(46) |
May
(17) |
Jun
(47) |
Jul
(23) |
Aug
(72) |
Sep
(33) |
Oct
|
Nov
|
Dec
|
From: Jun S. <jul...@ya...> - 2000-04-25 17:20:41
|
> > NOTE 1: the driver is probably not safe for SMP > machines (will do that > later). It might also not be wise to share the > device /dev/ohci1394 > between several threads/processes. > I am lost a little bit. How does this driver relate to libraw? As a separate question, can the libraw be shared by multiple processes or multiple threads? If the answer is yes, I wonder if any behavior is modified. For example, if both processes listen for the same iso channel, will they both get the data? Thanks. Jun __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com |
From: Arne S. <ar...@sc...> - 2000-04-25 16:27:11
|
Re: dropped frames on sending I mean the opposite... a buffer underrun. If Windows98 does not complain if it can't write to disk fast enough, it probably won't complain if it can't read fast enough. My point is, I don't trust Windows98 in this aspect. Re: iso receive buffer size A command line option for the buffer size is all *I* would like to have. No need for any automatism though. As long as this feature is not there, I simply edit the source and recompile, but not all Linux users are capable of doing that (which is perfectly okay, not everybody is a programmer nor wants to install the many, many MBytes of developer related files and learn how to use it). My opinion is, if we want mainstream Linux users with slow systems using the Linux 1394 system for DV, then we need a command line option for the buffer size or another way to set the size. Cheers, Arne -----Original Message----- From: Andreas Bombe [SMTP:and...@mu...] Sent: Tuesday, April 25, 2000 5:23 AM To: Arne Schirmacher Cc: lin...@li... Subject: Re: My wishlist entry Working up some old mails here... On Sat, Apr 15, 2000 at 09:28:05AM +0200, Arne Schirmacher wrote: > 1. the iso write function. > > My motivation for writing the dvgrab program was that the Windows98 grab > software available to me was too awkward to use. File size limits, no split > into smaller files, no control about dropped frames and the like. Now, after > dvgrab is useable, I discovered that the write-back-to-the-camcorder function > of my Windows98 program suffers from the same deficits too. > > In particular: It will write only one file to the camcorder, it has a file size > limit, the user is not informed about dropped frames, it will not write all > types of DV-AVI files. How can dropped frames when sending be detected? (I'm assuming isochronous sending here.) If it leaves the local computer successfully there is no telling whether it will be received and processed by the target node, since there is no target node. Iso is broadcast and therefore there are no acks. > 2. a way of controlling the device driver's buffer size > > The 1394 subsystem currently uses a buffer size of 4 MByte, which is hardcoded > in raw1394.c. I always have a problem with hardcoded limits, they are always > either too big or too small. This was just a quick hack to keep slow systems from drowning in stored iso packets. I'd like to allocate at buffer priority and free iso packets when memory is needed for real, but that seems to be hard. So the hard limit will probably stay, making it configurable won't be too hard. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Alastair M. <ala...@aj...> - 2000-04-25 15:52:45
|
Steve Sutphen wrote: > > Hello, > I hate to trouble you, but I am having problems getting dvgrab > to work. I have installed the ieee1394-2.2.14-20000318 patch in > a 2.2.14 kernel and that seems to work just fine. At > boot time I see: [snip] For some reason the OCHI driver doesn't always seem to 'take' when first loaded, particularly when devices are plugged in later. My routine now is to wait until everything has booted up, make sure my devices are plugged in/powered on, and then insmod the driver modules. Then I run testlibraw or gscanbus to make sure I'm really seeing everything. (And if not, unload/reload the modules.) > I have built your dvgrab 0.7 with the libraw1394-0.6 library. > I am trying to capture the raw DV so I can decode it with playdv > (the libDV package from OGI). > > I have a SIIG card with a TI TSB12LV23 chip on it. > > If I run your dvgrab like this: > dvgrab --ntsc --raw --frames 200 raw.dv > without a camera connected I see these messages in the log file: > ohci1394_0: Got phy packet ctx=0 ... discarded > ohci1394_0: listening enabled on channel 63 Note, the "--raw" option to dvgrab isn't very helpful for further playback: it writes *every* packet, including the short (16-byte) ones, and prepends a 4-byte length field to each one. Also, the "--frames" count in this case is really a packet count, you have to grab a lot of those to make a real video frame. I submitted a patch yesterday that adds a "--dv" option that strips short packets and extraneous header info, "playdv" understands the output from that. [snip] > > Can you start me in the right direction? Do I need to supply more > information? > I found 'testlibraw' (in the libraw package) and 'gscanbus' (downloadable from ftp://ftp.fokus.gmd.de/pub/cc/cats/usr/ami/ ) to be helpful in getting my setup running. If you can control your camera's functions (ie with the camera in VTR mode) from the gscanbus GUI then all is communicating properly async, so iso grabs with dvgrab should then be okay. Hope this helps. -- Alastair |
From: ACCARIE Jean-P. <ac...@cr...> - 2000-04-25 13:41:45
|
Hi, I have been following this mailing list since several months now and I noticed that many people were requesting iso write function. As I intend to develop some isochronous applications on top of the Linux 1394 driver in the coming weeks I will also require the iso write function (I planned to use an OHCI 1394 board although I am not very familiar with OCHI specifications). I'd like to know what is the current situation concerning iso write function: 1- I browsed the source code very quickly and didn't find anything whatever the level (ohci1394, ieee1394 or raw1394) Is this the same for pcilynx and aic5800? 2- I'd like to know if there is somebody already in charge of writing such iso writing function. If so, I'd like to know how I can contribute (coding, debugging,...) although I am very busy as everybody there;-) 3- Is there somebody here who already coded some basic implementation even if it has not been registered within CVS and that could be taken as a basis? 4- I was also wondering why this feature was missing: is there any tricky issues? Thanks Jean-Paul |
From: Sebastien R. <Seb...@sy...> - 2000-04-25 10:21:41
|
I have updated the API for the direct iso dma to user space feature that is available for the ohci driver. Previously the buffer filling was running continuously in the driver, and the user app was only waiting for irq generated for each frame. The problem was doing so you could easily create synchronization problems. Now the user app has to queue the buffers for each frame. If the user app can not keep up with the framerate, the dma context will wait until fresh buffers are queued. It is very similar to the video4linux API. The driver has been tested with 1-2 cameras on the bus, each delivering uncompressed 640x480 YUV422 30Hz video. Works well so far (at least the display is nice). NOTE 1: the driver is probably not safe for SMP machines (will do that later). It might also not be wise to share the device /dev/ohci1394 between several threads/processes. NOTE 2: you still have to enable this feature in ohci1394.h. It seems quite stable now, but I want to wait for some comment/bug reports before enabling it by default. The user app now looks like this: main() { int fd; struct video1394_mmap v; struct video1394_wait w; char *map; v.channel = 0; /* the iso channel you want to listen to */ v.sync_tag = 1; /* the tag in the iso packet for frame sync */ v.nb_buffers = 4; /* the number of buffers you want */ v.buf_size = 320*240*2; /* the size in bytes of one frame */ /* open the driver */ fd = open("/dev/ohci1394",O_RDWR); /* launch the iso context that will do the dma transfer * !!! NOTE: the field v.buf_size is modified by this call !!! * !!! it is rounded up to a multiple of PAGE_SIZE !!! */ if (ioctl(fd, VIDEO1394_LISTEN_CHANNEL, &v)<0) { perror("VIDEO1394_LISTEN_CHANNEL"); } /* map the dma buffer into user space */ if ((map = (char *) mmap(0,v.nb_buffers*v.buf_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd,0)) == (char *)-1) { perror("mmap"); return -1; } w.channel = v.channel; /* queue the buffers for frame acquisition */ for (i=0;i<v.nb_buffers;i++) { w.buffer=i; if (ioctl(fd,VIDEO1394_QUEUE_BUFFER,&w)==-1) { perror("VIDEO1394_QUEUE_BUFFER"); return -1; } /* here you do the camera initialization, start iso transmission */ ........ /* */ w.buffer=0; while(cond) { /* wait for the next frame */ ioctl(fd, VIDEO1394_WAIT_BUFFER, &w); /* put the buffer again in the queue */ ioctl(fd,VIDEO1394_QUEUE_BUFFER, &w); /* the image buffer starts at map+w.buffer*v.buf_size, * and has for length the frame size specified at the * beginning of the program. Here you do whatever you * want with it */ ....... w.buffer = (w.buffer+1)%v.nb_buffers; } /* here you stop iso transmission */ ........ /* */ /* unmap the memory */ if (map!=(char*)-1) munmap(map,v.nb_buffers*v.buf_size); /* deallocate the iso context */ if (ioctl(fd, VIDEO1394_UNLISTEN_CHANNEL, &v.channel)<0) { perror("VIDEO1394_UNLISTEN_CHANNEL"); } /* close the device */ close(fd); } |
From: Charles 'B. K. <kr...@cs...> - 2000-04-25 07:09:43
|
Hi Steve, I just got around to trying the new card. My hardware: generic 400MHz PII SIIG 1394 interface model # NN2603. Canon Elura camcorder (NTSC) I'm using the following software: linux kernel -- vanilla 2.2.14 (on RH 6.1 dist) ieee1394 -- I started with the patch, then I replaced the driver with the current CVS version libraw -- current CVS version dvgrab -- 0.7 + Alastair Mayer's patch to generate raw output for libdv libdv -- CVS version I have strange results. The first two tries produced video with odd sync problems, i.e. the picture from playdv (libdv) was vertically offset by about 2/3 of a frame. A third one produced video that seemed OK, but playdv seg faulted (I think on the last frame). The commands I use : dvgrab --ntsc --frames 300 --dv file playdv file.dv At one point, I unloaded/reloaded the ohci module. Since then, I've done about 8 clips in a row that all work correctly. Takes time to warm up? 8-| -- Buck ps Here is what I see in my syslog: Apr 24 23:55:44 c360746-a kernel: ieee1394: registered ohci1394 driver, initializing now Apr 24 23:55:44 c360746-a kernel: ohci1394: looking for Ohci1394 cards Apr 24 23:55:44 c360746-a kernel: ohci1394_0: allocated interrupt 15 Apr 24 23:55:44 c360746-a kernel: ohci1394_0: remapped memory spaces reg 0xc8854000 Apr 24 23:55:44 c360746-a kernel: ohci1394_0: soft reset finished Apr 24 23:55:44 c360746-a kernel: ohci1394_0: max packet size = 2048 bytes Apr 24 23:55:44 c360746-a kernel: ohci1394_0: 4 iso contexts available Apr 24 23:55:44 c360746-a kernel: ohci1394_0: Receive DMA ctx=0 initialized Apr 24 23:55:44 c360746-a kernel: ohci1394_0: Receive DMA ctx=1 initialized Apr 24 23:55:44 c360746-a kernel: ohci1394_0: AT dma ctx=0 initialized Apr 24 23:55:44 c360746-a kernel: ohci1394_0: AT dma ctx=1 initialized Apr 24 23:55:44 c360746-a kernel: ohci1394_0: Receive DMA ctx=2 initialized Apr 24 23:55:44 c360746-a kernel: ohci1394_0: resetting bus on request and attempting to become root Apr 24 23:55:44 c360746-a kernel: ieee1394: detected 1 ohci1394 adapter Apr 24 23:55:44 c360746-a kernel: ohci1394_0: SelfID process finished (phyid 1, root) Apr 24 23:55:44 c360746-a kernel: ohci1394_0: selfid packet 0x807f0880 rcvd Apr 24 23:55:44 c360746-a kernel: ohci1394_0: selfid packet 0x817f815e rcvd Apr 24 23:55:44 c360746-a kernel: ohci1394_0: This node self-id is 0x817f815e Apr 24 23:55:44 c360746-a kernel: ohci1394_0: calling self-id complete Apr 24 23:55:44 c360746-a kernel: ohci1394_0: Got phy packet ctx=0 ... discarded Apr 24 23:56:48 c360746-a kernel: ohci1394_0: listening enabled on channel 63 Apr 24 23:56:58 c360746-a kernel: ohci1394_0: listening disabled on iso channel 63 |
From: James G. <jamesg@Filanet.com> - 2000-04-25 05:45:15
|
Hi Sebastien, Thanks for the response! When I get a free moment, will further investigate some of these issues. Comments below. Cheers! --James >-----Original Message----- >From: Sebastien Rougeaux [mailto:Seb...@sy...] >Sent: Saturday, April 22, 2000 1:21 AM >To: jamesg@Filanet.com >Cc: lin...@li... >Subject: Re: changes to OHCI code... > >>>>>> "James" == James Goodwin <jamesg@Filanet.com> writes: > >James> // // We need to add delays after the soft reset, setting LPS, and >James> enabling our link. This fixes the self-id // reception problem if we >James> initialize with no devices attached (at least for my board). Probably >James> don't need the // delay after the soft reset, since are polling for >James> reset completion status, but the other two places need a // delay. Yes, >James> delays like these are evil, but at least they only happen at driver >James> initialization! // > >I have added delays in the initialization loop. But I am not sure about >the delay after enabling the link... Since enabling the link triggers a >bus reset, I have moved it at the end of the initialization routine, and >I think the card should be ready immediatly after that to handle the >bus reset... What do you think ? I'm not sure that enabling the link should cause a bus reset. Hopefully not... since higher levels call reset_host_bus right after init (would result in two quick bus resets). Either way, since hardware interrupts are not enabled until the very end of ohci_initialize it should be safe. =) > >James> =================== In ohci_irq_handler: > >James> // // In many cases we will receive a selfidcomplete interrupt while >James> the bus is still bouncing around a bit, // especially due to hot-plugs >James> of devices. One way to deal with this is to spin until the node id >James> becomes // valid. Not the nicest thing to do in the world, and we >James> should time-out if we never get a valid nodeid. // But, it quickly >James> deals with the case where we hot-plug a new device in and the bus >James> bounces around a // bit. // > >If you are looping in the irq_handler until the node id is valid, isn't >there any chance to miss self-id packets (or can the loop be a bit long >for an irq handler ?). I think it is a little ugly to loop in the irq_handler until the node id is valid, since it can potentially be many ms in the isr. Would probably be better to move all the self-id code, as well as the majority of the rest of the irq_handler code to a bh. But, this change to loop on node id valid has caused no problems in my testing (hot-plugging with up to eight devices attached). Also, we shouldn't worry about losing self-ids packets. If we wait until the node id is valid, we will always get the last set of self-ids (which has been dma-ed into the self-id buffer)... the last set is all we really care about anyway (who cares about sets of stale self-ids). Again, I've done a decent bit of hot-plug testing with this change... > >James> =================== In dma_rcv_bh: > >James> We need to handle write requests that are >James> received to our middle address space (posted writes). // In this case, >James> the hardware generates an ack_complete... but, if we pass the packet up >James> to ieee1394, // it will try and send a response (which it shouldn't), >James> because it assumes we returned ack_pending. > >James> // // Handle case of posted >James> writes. If we receive an ack_complete, // we should not send a >James> response. Fake out upper layers by turning the // packet into a >James> broadcast packet... we should really modify the core stack // to accept >James> an ack received argument and figure out whether to reply. >James> if (((d->spb[length/4-1]>>16)&0x1f) == 0x11) { > d-> spb[0] |= (ALL_NODES<<16); >James } > >Yes we should see that with Andreas. I also would like the subsystem to >handle the single phy packet that is received once the bus reset is >completed and that indicate the precise moment in the FIFO after which >the new bus topology is in operation. Yes, I think if we can report up to the higher level driver an "ack sent" argument, it can determine whether it needs to send a response packet. > >-- >Sebastien Rougeaux >RSISE, The Australian National University |
From: Andreas B. <and...@mu...> - 2000-04-25 03:49:52
|
There have been some problems with some PCILynx cards which I also experienced myself, namely that the chip sent out a packet as it should but then reported timeout on waiting for an ack (thus causing the subsystem to assume the transaction has failed and therefore reporting an unsolicited response later on). It turns out that for some reason the PHY chip (so it might not even be related to the Lynx) starts with 0 as its gap count. This is way too small and causes timeouts. I now added a line to pcilynx.c to explicitly set that to a safe value, which fixed the problem for me. Get it from CVS or just apply this patch: RCS file: /cvsroot/linux1394/ieee1394/pcilynx.c,v retrieving revision 1.20 diff -u -r1.20 pcilynx.c --- pcilynx.c 2000/04/15 02:48:02 1.20 +++ pcilynx.c 2000/04/25 03:08:55 @@ -338,6 +338,7 @@ i--; } + set_phy_reg(lynx, 1, 63); if (!lynx->phyic.reg_1394a) { lsid = generate_own_selfid(lynx, host); } -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Steve S. <st...@cs...> - 2000-04-25 03:48:10
|
Hello, I hate to trouble you, but I am having problems getting dvgrab to work. I have installed the ieee1394-2.2.14-20000318 patch in a 2.2.14 kernel and that seems to work just fine. At boot time I see: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394_0: allocated interrupt 10 ohci1394_0: remapped memory spaces reg 0xc8013000 ohci1394_0: soft reset finished ohci1394_0: max packet size = 2048 bytes ohci1394_0: 4 iso contexts available ohci1394_0: Receive DMA ctx=2 initialized ohci1394_0: Receive DMA ctx=0 initialized ohci1394_0: Receive DMA ctx=1 initialized ohci1394_0: AT dma ctx=0 initialized ohci1394_0: AT dma ctx=1 initialized ohci1394_0: resetting bus on request and attempting to become root ieee1394: detected 1 ohci1394 adapter ieee1394: 1 host adapter initialized I have built your dvgrab 0.7 with the libraw1394-0.6 library. I am trying to capture the raw DV so I can decode it with playdv (the libDV package from OGI). I have a SIIG card with a TI TSB12LV23 chip on it. If I run your dvgrab like this: dvgrab --ntsc --raw --frames 200 raw.dv without a camera connected I see these messages in the log file: ohci1394_0: Got phy packet ctx=0 ... discarded ohci1394_0: listening enabled on channel 63 That seems okay to me. If I hook up a camera (a Canon Optura, or a Panasonic Palmsight - I tried two different cameras) I get zillions of these messages: ieee1394: received packet during reset; ignoring There are huge numbers sent per second - causing klogd to use up 20% of my 533MHz CPU just throwing them away (I must not have the syslog.conf set to store them away, thankfully). If I unplug the DV connector from the camera the reset messages stop with one additional message: ieee1394: received packet during reset; ignoring ieee1394: received packet during reset; ignoring ohci1394_0: Got phy packet ctx=0 ... discarded The file "raw.dv" does not receive any data (i.e. it is always empty). If I terminate the dvgrab program then this message is logged: ohci1394_0: listening disabled on iso channel 63 which also makes sense to me. If I plug in the camera when the program is not running I see these log messages: ohci1394_0: Got phy packet ctx=0 ... discarded ohci1394_0: Got phy packet ctx=0 ... discarded ohci1394_0: Got phy packet ctx=0 ... discarded (there are 3 of them with a single plugging in operation, and one more when I unplug). Any idea what I am doing wrong? I am not totally unfamiliar with UNIX kernels (I have been dabbling with them since 1973), but IEEE1394 and DV are new to me (I have done some background reading, but not enough). Can you start me in the right direction? Do I need to supply more information? Thank you, it looks like a nice little package, once I get over the initial problems. st...@cs... |
From: Andreas B. <and...@mu...> - 2000-04-25 03:45:53
|
On Sun, Apr 23, 2000 at 12:10:55PM +0200, Manfred Spraul wrote: > Linus made a last minute SMP change: > > f_op->poll now runs without lock_kernel(). > > I currently try to verify all _poll functions, and don't understand > aux_poll: what's the purpose of > > md->aux_intr_last_seen++; Makes poll return POLLPRI one time for each interrupt that was received from some special channel on the PCILynx (even if the last poll lies a few interrupts in the past). It's not part of IEEE 1394 functionality, it's just some special features of the PCILynx that I need to support. > A normal "++" isn't SMP safe, so either lock_kernel() should be added, > or aux_intr_last_seen could be converted to an atomic_t variable. Thanks, will be done. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-25 03:45:37
|
Working up some old mails here... On Sat, Apr 15, 2000 at 09:28:05AM +0200, Arne Schirmacher wrote: > 1. the iso write function. > > My motivation for writing the dvgrab program was that the Windows98 grab > software available to me was too awkward to use. File size limits, no split > into smaller files, no control about dropped frames and the like. Now, after > dvgrab is useable, I discovered that the write-back-to-the-camcorder function > of my Windows98 program suffers from the same deficits too. > > In particular: It will write only one file to the camcorder, it has a file size > limit, the user is not informed about dropped frames, it will not write all > types of DV-AVI files. How can dropped frames when sending be detected? (I'm assuming isochronous sending here.) If it leaves the local computer successfully there is no telling whether it will be received and processed by the target node, since there is no target node. Iso is broadcast and therefore there are no acks. > 2. a way of controlling the device driver's buffer size > > The 1394 subsystem currently uses a buffer size of 4 MByte, which is hardcoded > in raw1394.c. I always have a problem with hardcoded limits, they are always > either too big or too small. This was just a quick hack to keep slow systems from drowning in stored iso packets. I'd like to allocate at buffer priority and free iso packets when memory is needed for real, but that seems to be hard. So the hard limit will probably stay, making it configurable won't be too hard. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Andreas B. <and...@mu...> - 2000-04-25 03:07:05
|
On Tue, Apr 18, 2000 at 12:54:57PM +0200, Manfred Weihs wrote: > > > On Sat, 15 Apr 2000, Andreas Bombe wrote: > > I didn't know how to size the FIFOs so I gave all of them (general > > receive, async transmit, iso transmit) the same size. Try the current > > version of pcilynx.c from CVS which has the iso length check already > > included and configures the receive FIFO larger. > > I am not sure, if that was a real solution to the problem. I still get > those errors, and I think, they come as frequently as before. It made it better for me. I guess it does help, but just not enough for you. It seems to be a symptom of interrupts not being served fast enough. Do you probably have some drivers running that take a lot of irq time (e.g. vesa fb)? Otherwise the data copying might really overload your system. Another possibility is that it runs out of iso buffers while it is receiving (because the bottom half isn't executed often enough to get clean buffers), but I don't really think that happens since in that case it just stops receiving iso. You can try to raise the NUM_ISORCV_PCL number in pcilynx.h anyway and see if that helps in any way. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Arne S. <ar...@sc...> - 2000-04-24 17:30:22
|
Alastair Mayer wrote: > > Hi, > > I modified dvgrab a bit (added an option) so that it can output files > in a format that 'playdv' (part of libdv) will recognize directly. The > patches are appended below, basically it adds a "--dv" option, i.e. > dvgrab --ntsc --dv --frames 150 foo > would write 150 frames to foo.dv, and then > playdv foo.dv > would display it. Great, I will merge it in the next release. The "correct" way to do it (imho) however is modifying the playdv program so that it can use a common file format for DV. But it is good to have an intermediate solution available. Arne |
From: Charles 'B. K. <kr...@cs...> - 2000-04-24 16:58:53
|
Alastair Mayer <ala...@aj...> writes: > Hi, > I modified dvgrab a bit (added an option) so that it can output files > in a format that 'playdv' (part of libdv) will recognize directly. The > patches are appended below, basically it adds a "--dv" option, i.e. > dvgrab --ntsc --dv --frames 150 foo > would write 150 frames to foo.dv, and then > playdv foo.dv > would display it. Very nice. > The performance of playdv has room for improvement: I get about 2 to > 3 frames/second on my machine (a 233MHz winchip -- which supports > MMX and 3DNow but otherwise has only about 156 bogoMips performance), > this with the first release of libdv (I think there've been some > improvements since). Yes, our first priority has been to achieve correct playout. Synchronizing with sound is an exception, since video performance has to be better than real-time for normal playout. > On other note -- the "pond.dv" file from the libdv folks seems to be > recorded in progressive-scan mode, not interlaced. Yep. A nice feature to have in a camcorder. :) > The interlaced data from my Sony TRV-103 that I've been testing with > has a lot of motion (the camera was panning) so playdv spends about > 40% of its time doing the 2-4-8 idct (and another 40% doing > ycrcb->rgb conversion). You observations are very astute. Videos with motion and lots of 2-4-8 dcts suffer a major penalty in the current version of libdv. The 2-4-8 idct in libdv is pathologically slow. I have a C version of 2-4-8 idct based on the AAN algorithm, the same one that the Intel 8-8 MMX'd idct is based on, nearly complete. MMX'ing that will follow. Once that gets integrated, presence of 2-4-8's will have no impact on performance. The ycrcb->rgb code has a similar story. Actually, we consider everything after macroblock placement to be the "final video mile", which isn't really properly part of libdv. Playdv.c does it out of necessity, in probably the dumbest way possible, for the purpose of testing. Eventually, that "final video mile" is better handled by format independent components. This is where the current soup that are Xv, DGA, SDL, DRI, Hermes, gstreamer, etc. will hopefully come together. > To make the image look nicer at the low frame rate I added code to > playdv to deinterlace the image just prior to display (basically > just copy every second scan line to the previous one, effectively > doubling the pixel height and halving the vertical resolution). Sounds like a sensible interim approach. > I'm working on adding sound decoding now. Great! -- Buck > --- here's the patch for dvgrab to output playdv-friendly files --- [ snip ] |
From: Alastair M. <ala...@aj...> - 2000-04-24 16:22:06
|
Hi, I modified dvgrab a bit (added an option) so that it can output files in a format that 'playdv' (part of libdv) will recognize directly. The patches are appended below, basically it adds a "--dv" option, i.e. dvgrab --ntsc --dv --frames 150 foo would write 150 frames to foo.dv, and then playdv foo.dv would display it. The performance of playdv has room for improvement: I get about 2 to 3 frames/second on my machine (a 233MHz winchip -- which supports MMX and 3DNow but otherwise has only about 156 bogoMips performance), this with the first release of libdv (I think there've been some improvements since). On other note -- the "pond.dv" file from the libdv folks seems to be recorded in progressive-scan mode, not interlaced. The interlaced data from my Sony TRV-103 that I've been testing with has a lot of motion (the camera was panning) so playdv spends about 40% of its time doing the 2-4-8 idct (and another 40% doing ycrcb->rgb conversion). To make the image look nicer at the low frame rate I added code to playdv to deinterlace the image just prior to display (basically just copy every second scan line to the previous one, effectively doubling the pixel height and halving the vertical resolution). I'm working on adding sound decoding now. --- here's the patch for dvgrab to output playdv-friendly files --- *** dvgrab.cc Tue Apr 18 12:28:24 2000 --- new/dvgrab.cc Fri Apr 21 23:43:22 2000 *************** *** 35,39 **** #define RAW_BUF_SIZE (10240) ! enum { PAL_FORMAT, NTSC_FORMAT, AVI_FORMAT, RAW_FORMAT, TEST_FORMAT, UNDEFINED }; int g_alldone; --- 35,39 ---- #define RAW_BUF_SIZE (10240) ! enum { PAL_FORMAT, NTSC_FORMAT, AVI_FORMAT, RAW_FORMAT, TEST_FORMAT, DV_FORMAT, UNDEFINED }; int g_alldone; *************** *** 129,133 **** } - int raw_iso_handler(raw1394handle_t handle, int channel, size_t length, quadlet_t *data) --- 129,132 ---- *************** *** 254,257 **** --- 253,258 ---- } else if (strcmp("--test", argv[i]) == 0) { g_file_format = TEST_FORMAT; + } else if (strcmp("--dv", argv[i]) == 0) { + g_file_format = DV_FORMAT; } else if (strcmp("--pal", argv[i]) == 0) { g_dv_format = PAL_FORMAT; *************** *** 567,575 **** frames_read = 0; while ((!g_alldone) && (frames_read < g_frame_count)) { raw1394_loop_iterate(handle); length = *(int*)g_frame; ! write(dst_fd, g_frame, length + 4); ! frames_read++; } close_1394_driver(handle); --- 568,631 ---- frames_read = 0; + + while ((!g_alldone) && (frames_read < g_frame_count)) { + raw1394_loop_iterate(handle); + length = *(int*)g_frame; + write(dst_fd, g_frame, length + 4); + frames_read++; + } + close_1394_driver(handle); + free(g_frame); + close(dst_fd); + + return 0; + } + + /* capture in a format suitable for playdv (part of libdv) */ + + int capture_dv() + { + int frames_read; + int length; + int dst_fd; + raw1394handle_t handle; + bool found_first_frame; + int skipped = 0; + + char filename[256]; + sprintf(filename, "%s.dv", g_dst_file_name); + if ((dst_fd = open(filename, O_WRONLY | O_CREAT, 00644)) < 0) { + perror("problem with output file"); + usage(); + exit(1); + } + + fail_null(g_frame = (unsigned char*)malloc(RAW_BUF_SIZE)); + + handle = open_1394_driver(g_channel, raw_iso_handler); + + frames_read = 0; + found_first_frame = false; + while ((!g_alldone) && (frames_read < g_frame_count)) { raw1394_loop_iterate(handle); length = *(int*)g_frame; ! if (length == 496) { ! if (!found_first_frame) { ! if (g_frame[16] == 0x1f && ! g_frame[17] == 0x07) ! found_first_frame = true; ! else skipped++; ! } ! if (skipped > 500) { ! printf("skipped too many without finding frame\n"); ! break; ! } ! if (found_first_frame) { ! write(dst_fd, (g_frame+16), length-16); ! if (g_frame[16] == 0x1f && g_frame[17] == 0x07) ! frames_read++; ! } ! } } close_1394_driver(handle); *************** *** 612,615 **** --- 668,675 ---- capture_avi(); break; + + case DV_FORMAT: + capture_dv(); + break; default: |
From: <Ale...@ne...> - 2000-04-24 13:12:07
|
Well, I guess my understanting of the driver isn't complete yet. I am new to the 1394 businesss and I have to set up some extensive multimedia activity here, so I'm playing with the driver ans some test applications a bit before I start off. BTW - this also means that I will be needing the iso transmit very badly in the near future. Any news on this? Alex. Sebastien Rougeaux <Seb...@sy...> on 04/22/2000 03:59:05 AM Please respond to Seb...@sy... Sent by: Sebastien Rougeaux <Seb...@sy...> To: Ale...@ne... cc: lin...@li... (Alexander Carmeli/US/3Com) Subject: Re: More on dual card box >>>>> "Alexander" == Alexander Carmeli <Ale...@ne...> writes: Alexander> If anyone's interested: I finally managed to put my dual card box Alexander> to work. No changes to the driver was needed and everything is Alexander> detected automatically. What was wrong then ? -- Sebastien Rougeaux RSISE, The Australian National University _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Manfred S. <man...@co...> - 2000-04-23 10:17:35
|
Linus made a last minute SMP change: f_op->poll now runs without lock_kernel(). I currently try to verify all _poll functions, and don't understand aux_poll: what's the purpose of md->aux_intr_last_seen++; A normal "++" isn't SMP safe, so either lock_kernel() should be added, or aux_intr_last_seen could be converted to an atomic_t variable. -- Manfred |
From: Sebastien R. <Seb...@sy...> - 2000-04-22 08:29:27
|
Here is a mail I have received from James Goodwin that can be of interest for the list, especially for people who still have problem with the reception of self-id packets. Most of the suggestion will be implemented in CVS soon. Sebastien Rougeaux ------- Start of forwarded message ------- From: James Goodwin <jamesg@Filanet.com> To: Seb...@sy... Subject: changes to OHCI code... Date: Fri, 21 Apr 2000 14:25:40 -0700 Content-Type: text/plain; charset="iso-8859-1" Hi Sebastien, I've been playing around with the 1394 stack a bit and your OHCI driver, and had a couple changes to the OHCI driver that you might be interested in checking out (have been running some sbp2 support on top of your driver). I can provide you a patch if you'd like, but figured that it would be better to explain the changes I made, and you could incorporate them as you see fit... or argue with me about the changes (my comments are noted by //)... ;-) One general issue I have for you (which I have no good fix for yet) is the bh handling of received async packets. Sometimes packets are missed on receive (the bh is not run). I think we need to loop in our bh to handle all async packets received, instead of only trying to handle one received packet in each bh run. My temp hack workaround for my sbp2 stuff right now is to run the dma_rcv_bh directly from the interrupt handler (but this is bad!). Cheers, - --James p.s. I'm a bit behind on synching up with the latest stack, so please excuse any duplicate fixes... =) =================== In ohci_initialize: // // We need to add delays after the soft reset, setting LPS, and enabling our link. This fixes the self-id // reception problem if we initialize with no devices attached (at least for my board). Probably don't need the // delay after the soft reset, since are polling for reset completion status, but the other two places need a // delay. Yes, delays like these are evil, but at least they only happen at driver initialization! // /* Soft reset */ if ((retval=ohci_soft_reset(ohci))<0) return retval; // // Delay aftger soft reset to make sure everything has settled down (sanity) // mdelay(100); /* Set Link Power Status (LPS) */ reg_write(ohci, OHCI1394_HCControlSet, 0x00080000); // // Delay after setting LPS in order to make sure link/phy communication is established // mdelay(100); /* Set the bus number */ reg_write(ohci, OHCI1394_NodeID, 0x0000ffc0); ... /* Enable link */ reg_write(ohci, OHCI1394_HCControlSet, 0x00020000); // // Delay after enabling the link to give the link some time // mdelay(100); =================== In ohci_irq_handler: // // In many cases we will receive a selfidcomplete interrupt while the bus is still bouncing around a bit, // especially due to hot-plugs of devices. One way to deal with this is to spin until the node id becomes // valid. Not the nicest thing to do in the world, and we should time-out if we never get a valid nodeid. // But, it quickly deals with the case where we hot-plug a new device in and the bus bounces around a // bit. // if (event & OHCI1394_selfIDComplete) { if (host->in_bus_reset) { // // Wait for our nodeid to become valid (could still be invalid if the bus is bouncing around // because of a hot-plug). TODO. Add a timeout in this loop. All of this code should really // be run from a bh, instead of from our ISR. // while (1) { node_id = reg_read(ohci, OHCI1394_NodeID); if (node_id & 0x80000000) { break; } } node_id = reg_read(ohci, OHCI1394_NodeID); =================== In handle_selfid: // // In many cases with current OHCI hardware, we get the selfIDError bit set on hot-plugs of devices. Quick fix // for this is to generate another bus reset in response to seeing this (which clears things up). This is what // Microsoft's OHCI implementation does as well. // /* Check status of self-id reception */ if ((self_id_count&0x80000000) || ((self_id_count&0x00FF0000) != (q[0]&0x00FF0000))) { PRINT(KERN_ERR, ohci->id, "Error in reception of self-id packets" "Self-id count: %08x q[0]: %08x", self_id_count, q[0]); // // We had an error, generate another bus reset in response. TODO. Actually read // the current value in the phy before generating a bus reset (read modify write). This way // we don't stomp any current gap count settings, etc. Also should keep a count of // number of times we do this error recovery bus reset, so that there is no chance of us // getting into an endless loop of bus resets. // reg_write(ohci, OHCI1394_PhyControl, 0x000041ff); return -1; } =================== In alloc_dma_rcv_ctx and alloc_dma_trm_ctx: spin_lock_init(&d->lock); /* initialize bottom handler */ d->task.sync = 0; // Need to make sure and initialize sync and next, in case the memory was not d->task.next = NULL; // zeroed when you allocated it... d->task.routine = dma_rcv_bh; d->task.data = (void*)d; =================== In ohci_irq_handler: /* Accept Physical requests from all nodes. */ reg_write(ohci,OHCI1394_AsReqFilterHiSet, 0xffffffff); reg_write(ohci,OHCI1394_AsReqFilterLoSet, 0xffffffff); // // Turn on phys dma reception. We should probably manage the filtering somehow, instead // of blindly turning it on. // reg_write(ohci,OHCI1394_PhyReqFilterHiSet, 0xffffffff); reg_write(ohci,OHCI1394_PhyReqFilterLoSet, 0xffffffff); reg_write(ohci,OHCI1394_PhyUpperBound, 0xffff0000); =================== In dma_rcv_bh: // // We need to handle write requests that are received to our middle address space (posted writes). // In this case, the hardware generates an ack_complete... but, if we pass the packet up to ieee1394, // it will try and send a response (which it shouldn't), because it assumes we returned ack_pending. // if (tcode != 0xE) { DBGMSG(ohci->id, "Split packet received from" " node %d ack=0x%02X spd=%d tcode=0x%X" " length=%d data=0x%08x ctx=%d", (d->spb[1]>>16)&0x3f, (d->spb[length/4-1]>>16)&0x1f, (d->spb[length/4-1]>>21)&0x3, tcode, length, d->spb[3], d->ctx); // // Handle case of posted writes. If we receive an ack_complete, // we should not send a response. Fake out upper layers by turning the // packet into a broadcast packet... we should really modify the core stack // to accept an ack received argument and figure out whether to reply. // if (((d->spb[length/4-1]>>16)&0x1f) == 0x11) { d->spb[0] |= (ALL_NODES<<16); } hpsb_packet_received(ohci->host, d->spb, length); } ... if (tcode != 0xE) { DBGMSG(ohci->id, "Packet received from node" " %d ack=0x%02X spd=%d tcode=0x%X" " length=%d data=0x%08x ctx=%d", (buf_ptr[1]>>16)&0x3f, (buf_ptr[length/4-1]>>16)&0x1f, (buf_ptr[length/4-1]>>21)&0x3, tcode, length, buf_ptr[3], d->ctx); // // Handle case of posted writes. If we receive an ack_complete, // we should not send a response. Fake out upper layers by turning the // packet into a broadcast packet... we should really modify the core stack // to accept an ack received argument and figure out whether to reply. // if (((buf_ptr[length/4-1]>>16)&0x1f) == 0x11) { buf_ptr[0] |= (ALL_NODES<<16); } hpsb_packet_received(ohci->host, buf_ptr, length); } ------- End of forwarded message ------- |
From: Sebastien R. <Seb...@sy...> - 2000-04-22 08:27:34
|
Hi James, Thanks a lot for your remarks and patches. You should really cross-post to the linux1394-devel list as well, some people might be interested. I comment your comments below: >>>>> "James" == James Goodwin <jamesg@Filanet.com> writes: James> One general issue I have for you (which I have no good fix for yet) is James> the bh handling of received async packets. Sometimes packets are missed James> on receive (the bh is not run). I think we need to loop in our bh to James> handle all async packets received, instead of only trying to handle one James> received packet in each bh run. My temp hack workaround for my sbp2 James> stuff right now is to run the dma_rcv_bh directly from the interrupt James> handler (but this is bad!). I have also noticed that sometimes the bottom halves are queued and not executed... for the moment I am in the dark. As for looping in the bh, it does that already... basically it reads the buffer until it is empty. Yes calling the bh directly can be a temporary fix... I could do that, but I am afraid it could be bad for some slow computer... James> // // We need to add delays after the soft reset, setting LPS, and James> enabling our link. This fixes the self-id // reception problem if we James> initialize with no devices attached (at least for my board). Probably James> don't need the // delay after the soft reset, since are polling for James> reset completion status, but the other two places need a // delay. Yes, James> delays like these are evil, but at least they only happen at driver James> initialization! // I have added delays in the initialization loop. But I am not sure about the delay after enabling the link... Since enabling the link triggers a bus reset, I have moved it at the end of the initialization routine, and I think the card should be ready immediatly after that to handle the bus reset... What do you think ? James> =================== In ohci_irq_handler: James> // // In many cases we will receive a selfidcomplete interrupt while James> the bus is still bouncing around a bit, // especially due to hot-plugs James> of devices. One way to deal with this is to spin until the node id James> becomes // valid. Not the nicest thing to do in the world, and we James> should time-out if we never get a valid nodeid. // But, it quickly James> deals with the case where we hot-plug a new device in and the bus James> bounces around a // bit. // If you are looping in the irq_handler until the node id is valid, isn't there any chance to miss self-id packets (or can the loop be a bit long for an irq handler ?). James> =================== In handle_selfid: James> // // In many cases with current OHCI hardware, we get the selfIDError James> bit set on hot-plugs of devices. Quick fix // for this is to generate James> another bus reset in response to seeing this (which clears things James> up). This is what // Microsoft's OHCI implementation does as well. // Ok. I have added the fix with a timeout counter. James> =================== In alloc_dma_rcv_ctx and alloc_dma_trm_ctx: d-> task.sync = 0; d-> task.next = NULL; It is always good to initialize all the fields... James> =================== In ohci_irq_handler: James> // Turn on phys dma reception. We James> should probably manage the filtering somehow, instead // of blindly James> turning it on. James> reg_write(ohci,OHCI1394_PhyReqFilterHiSet, 0xffffffff); James> reg_write(ohci,OHCI1394_PhyReqFilterLoSet, 0xffffffff); James> reg_write(ohci,OHCI1394_PhyUpperBound, 0xffff0000); Ok. Fix included. James> =================== In dma_rcv_bh: James> We need to handle write requests that are James> received to our middle address space (posted writes). // In this case, James> the hardware generates an ack_complete... but, if we pass the packet up James> to ieee1394, // it will try and send a response (which it shouldn't), James> because it assumes we returned ack_pending. James> // // Handle case of posted James> writes. If we receive an ack_complete, // we should not send a James> response. Fake out upper layers by turning the // packet into a James> broadcast packet... we should really modify the core stack // to accept James> an ack received argument and figure out whether to reply. James> if (((d->spb[length/4-1]>>16)&0x1f) == 0x11) { d-> spb[0] |= (ALL_NODES<<16); James } Yes we should see that with Andreas. I also would like the subsystem to handle the single phy packet that is received once the bus reset is completed and that indicate the precise moment in the FIFO after which the new bus topology is in operation. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-22 08:05:35
|
>>>>> "Alexander" == Alexander Carmeli <Ale...@ne...> writes: Alexander> If anyone's interested: I finally managed to put my dual card box Alexander> to work. No changes to the driver was needed and everything is Alexander> detected automatically. What was wrong then ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: <Ale...@ne...> - 2000-04-21 13:18:27
|
All, If anyone's interested: I finally managed to put my dual card box to work. No changes to the driver was needed and everything is detected automatically. Alex, |
From: Sebastien R. <Seb...@sy...> - 2000-04-21 08:34:39
|
I have corrected a bug which was preventing the direct iso dma to user space to work properly when using several cameras simultaneously on the bus (see my previous mail for the announcement and the explanation on how to use it). I have now dual acquisition of 640x480 YUV422 uncompressed frames at 30 Hz, with a CPU load so small it doesn't even appear in the 'top' command ;-) On the down side, I have sometimes some kernel oops when trying to stop the user app using Ctrl-C... so be warned if you want to use this feature (it is very stable while running though). Any comment or bug report on the ohci driver is always welcome. Cheers, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-04-20 11:24:14
|
I am please to announce the availibility of direct iso dma to user space for the ohci module. The driver supports multi-buffering and user configurable frame sizes. It is now included in the sourceforge CVS repository. To achieve that, I have temporarily created a /dev/ohci1394 entry. If you want to test this feature, you have to add it manually: 'mknod /dev/ohci1394 c 172 0' and set the permission accordingly. If the MAJOR number is already taken on your system, change it in ohci1394.h I have also added a file called video1394.h that has to be included in the source code of the user application. Note that the API is just temporary, I have to see with Andreas what would be the best way to include that in the subsystem. If you want to enable the direct DMA to user space feature, you will have to set it at the beginning of ohci1394.h. Please be aware that this feature has not been tested extensively (it works from me on linux-2.2.14)... USE AT YOUR OWN RISK ! The user app works like this. It is loosely based on the video4linux API: main() { int fd; struct video1394_mmap v; struct video1394_wait w; char *map; v.channel = 4; /* the iso channel you want to listen to */ v.sync_tag = 1; /* the tag in the iso packet for frame sync */ v.nb_buffers = 2; /* the number of buffers you want */ v.buf_size = 320*240*2; /* the size in bytes of one frame */ /* open the driver */ fd = open("/dev/ohci1394",O_RDWR); /* launch the iso context that will do the dma transfer */ /* !!! NOTE: the field v.buf_size is modified by this call !!! */ if (ioctl(fd, VIDEO1394_LISTEN_CHANNEL, &v)<0) { perror("VIDEO1394_LISTEN_CHANNEL"); } /* map the dma buffer into user space */ if ((map = (char *) mmap(0,v.nb_buffers*v.buf_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd,0)) == (char *)-1) { perror("mmap"); return -1; } /* here you do the camera initialization, start iso transmission */ ........ /* */ w.channel = 4; /* the channel you are listening */ w.buffer = 0; /* the buffer number that has been loaded */ while(cond) { /* wait for the next frame */ ioctl(fd, VIDEO1394_WAIT_CHANNEL, &w); /* the image buffer starts at map+w.buffer*v.buf_size, * and has for length the frame size specified at the * beginning of the program. */ } /* here you do the camera stop, stop iso transmission */ ........ /* */ /* unmap the memory */ if (map!=(char*)-1) munmap(map,v.nb_buffers*v.buf_size); /* deallocate the iso context */ if (ioctl(fd, VIDEO1394_UNLISTEN_CHANNEL, &v.channel)<0) { perror("VIDEO1394_UNLISTEN_CHANNEL"); } /* close the device */ close(fd); } Enjoy ! -- Sebastien Rougeaux RSISE, The Australian National University |
From: Simon V. <si...@tk...> - 2000-04-20 06:31:40
|
> neither runs or compiles on my system :-( it is just too old. > > I hope I'll get that SuSE 6.4 DVD real soon now > Could you give me the output of the make run? I haven't attempted using autoconf stuff yet, but it seems about time :) Simon |
From: Alastair M. <ala...@aj...> - 2000-04-19 20:11:29
|
Arne Schirmacher wrote: > To display an AVI file generated by dvgrab using playdv: > > dd bs=1 skip=65032 if=test001.avi > test001.raw > > playdv test001.raw It looks to me (after a very cursory glance) that playdv wants a raw input stream that looks like the "--raw" output from dvgrab minus the short packets and length data, which is a simple enough change to do. (I was playing with just that a couple of days ago.) Alas I don't have access to the system I have all that loaded on right now (it's at home, I'm at work), it's something I'll play with tonight. And maybe have raw output go to stdout so one could try something like dvgrab --raw | playdv This is cool, the DV stuff is all starting to come together. Now if we could only write it back... -- Alastair So much unwritten code, so little time... |