linux1394-devel Mailing List for IEEE 1394 for Linux (Page 527)
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
(34) |
Oct
|
Nov
|
Dec
|
From: Mark W. K. <mar...@ho...> - 2000-06-04 03:20:13
|
I tried Daniel's live video program today and it seemed to work fine. I am getting about 4.5 to 5 FPS on a 750 Athlon with a GeForce DDR card. I have no idea how this compares to best of breed in the Windows world. Does anyone else? The program seemed quite friendly, which I also attribute to good underlying driver code. I was able to leave the program running, but pull the camera plug, or stop and restart the camera, and the video picked up again and started playing just fine. No core dumps or other problems I could see. I also recorded some longer clips using dvgrab-0.82 - like 5 minutes - just to see what happens, and they basically worked fine. DV2 format plays back at the right speed under NT using QuickTime and under Win98SE using WMP. Audio was working under 98SE. I didn't have the speakers plugged in at the time under NT. (Listening to Sting on my Linux box) The one 'problem' I am dealing with on this system Athlon is that it seems to drop a huge number of frames in dvgrab. I am quite surprised, as this machine is far and away the fastest of the 5 machines I'm playing around with, and it has the fastest hard disk, at least as far as specs go. It is new though, so I need to figure out if it's really configured correctly. My 433 Celeron has never dropped a frame, to the best of my knowledge. I read Arne's README that talked about disk speed, which makes sense, but this machine is supposed to be a great new chipset and certainly a fast processor. What benchmarks can I run to determine whether there is some problem with the way I've built the kernel or the system itself? Any configuration files to check? Anyway, Daniel, cool job. I need to study the code a bit now. Thanks! Mark |
From: Bernhard S. <b.s...@gm...> - 2000-06-03 18:34:24
|
Hello, today I tried to insmod and use the ieee-driver (CVS version from 28.05.00) with my camera (Sony TRV310E) connected bot not playing back a tape. Instead I had enabled the direct analog->DV function (without tape recording) so the camera is sending a DV stream without a timestamp. For insmod ohci1394 I got the message: ohci1394_0: irq_handler timeout event 0x00020000 Starting dvgrab I got no frame recorded. Now I played back a D8 tape and tried dvgrab again (without rmmod and insmod anything) and it worked with no problem. So it looks like the driver (or dvgrab?) does not transfer any data if there is no timestamp in it. Did anyone try this before either by patching the camera or by playing back a normal Hi8 tape (I don't have any). If it's really the missing timestamp in the DV data is there an easy way to fix it? Bernhard |
From: Daniel K. <dan...@st...> - 2000-06-02 22:49:53
|
Hi! As stated in my previous message, I can display live video streams on-screen using linux1394 and libdv. I'm not too happy about the implementation though. What's bothering me most is the internal buffering of iso data in the subsystem. I'd like to drop intermittent frames if my processing is too slow. However with a naive approach I get the whole backlog of frames in the buffer (and a klogd screaming badly about dropping packets). My current workaround is to start/stop iso rcv for every frame (which makes me yearn for the patch below to be applied soon...). An alternative approach would be to spawn a seperate thread that calls raw1394_loop_iterate in a tight loop, and telling the iso handler just to drop packets when processing is too slow. Both suck. mmapping /dev/ohci1394 is the proper way to go for OHCI, I think but that's not really a generic solution. Has anyone thought about this already? Maybe a 'drop' option to start_iso_rcv() (which questionable semantics)? Daniel. Index: ohci1394.c =================================================================== RCS file: /cvsroot/linux1394/ieee1394/ohci1394.c,v retrieving revision 1.31 diff -u -r1.31 ohci1394.c --- ohci1394.c 2000/05/19 16:13:54 1.31 +++ ohci1394.c 2000/06/02 22:42:16 @@ -1420,7 +1420,7 @@ #endif if (!test_and_set_bit(arg, &ohci->IR_channel_usage)) { - PRINT(KERN_INFO, ohci->id, + DBGMSG(KERN_INFO, ohci->id, "listening enabled on channel %d", arg); if (arg > 31) { @@ -1446,7 +1446,7 @@ spin_lock_irqsave(&ohci->IR_channel_lock, flags); if (test_and_clear_bit(arg, &ohci->IR_channel_usage)) { - PRINT(KERN_INFO, ohci->id, + DBGMSG(KERN_INFO, ohci->id, "listening disabled on iso channel %d", arg); if (arg > 31) { -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Bernhard S. <bs...@gm...> - 2000-06-02 22:28:26
|
Hi Simon. On Fri, 2 Jun 2000, Simon Vogl wrote: > Hi Bernhard, > > Is it possible that your AVI gets scattered around the DOS partition by the Linux > vfat code? This could cause the described effect - On the first run, the cache is > filled, but delays from long seeks cause playback problems. On the next runs, most > of it is in RAM, jand the delays go away... Well it is a dedicated video partition formatted as vfat which was nearly empty as I recorded the AVIs. The interesting thing is that the same AVI (I didn't move it on the partition) played without problems under Win98 (with the MS decompressor). So I think it's either a problem with the IDE-Driver for the Irongate chipset under w2k or a DVSoft problem or whatever else. But moving a windows recorded type-2 AVI to the vfat partition the AVI can be played back without any problems under w2k. Moving the original dvgrab AVIs to a ntfs partition the type-1 files plays without problems but the type-2 frame still looses some frames. But this meight be caused by the wrong sound settings in the header of the dvgrab-0.81 AVIs. I'll test it again with dvgrab-0.82 this weekend. Greetings Bernhard |
From: Daniel K. <dan...@st...> - 2000-06-02 22:12:47
|
On Tue, 30 May 2000, Mark Knecht wrote: > Is there a way for me to create a real-time link between these two programs > such that the output of dvgrab is fed directly into xdvplay, creating a > real-time display of the video data on screen? (Preferably without saving > the data to disk!!!) This would be good for demo-ing to my executive staff. Try the attached patch to libdv (current CVS version). cd libdv patch -p1 < /path/to/dv-diff make stream ./stream This should hopefully give you a nice little gtk window displaying live video. (Yes, I know, I should make port and channel numbers an option but I'm lazy and I only have a single IEEE1394 device... ;-) Gets me ~6 frames per second on a Dual PIII/450. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Mark K. <mk...@co...> - 2000-06-02 22:11:18
|
Arne, et. all, (I was spell checking this e-mail when yours arrived about dvgrab-0.82, so I downloaded it and tried it out. Specific comments in parens below.) Hopefully this will be my last word for awhile (yeah right!) about the subject of all of these DV files and how they run under NT. In the end, I think that James Goodwin was probably right, and probably right for the right reasons. Win 98SE, and possibly Win 2K, are more focused multi-media platforms for Microsoft and certainly have a history of more timely software updates than NT. MS based testing ought to be more focused in those areas first. I downloaded QuickTime 4.0 for Windows NT today and installed it on this system, and all of the files that have been playing slowly under WMP and RP (if they played at all under RP) played correctly under QT4W. (0.81 & 0.82 dv2 format only) If you're interested in this piece of software, find it at: http://www.apple.com/quicktime/download/ Since these files display just fine under QT4W on NT 4.0, and also display using WMP under 98SE, I really don't believe that the speed issue is a file/data problem, but really is just a Microsoft software issue. I will let someone more experienced look into this if they choose. (With 0.82 I am able to now display dv2 files under NT on Real Player, which didn't work before. Now both WMP and RP play dv2 at exactly 1/2 speed. A 33 second clip took exactly 66 seconds on my machine dropping most frames, but QT4W played it in 33 seconds and did a much better job doing it.) The issue of why dv1 formatted files don't display any details remains, but that can be fixed I'm sure. I believe that, Arne, you have reported seeing the same thing there, so I'll wait for you to resolve this. If I can be of any help with more NTSC clips or testing I will be happy to do that immediately. (This has not changed for me Arne with 0.82 - I presume this is still what you are seeing?) Therefore , with appropriate tongue in cheek, once again "I resolve to just do whatever James Goodwin tells me to do." ;-) Thanks, Mark |
From: Matt P. <ma...@ls...> - 2000-06-02 21:21:36
|
Short answer - I wouldn't waste any time on this - it doesn't affect your driver. Long answer - From a bus function standpoint there is absolutely no difference in the 4-pin vs. 6-pin implementations. The real difference would be if power management were implemented. The power supplied via the 6-pin connector is (traditionally) not under the control of the 1394 (OHCI link or PHY) electronics. Regards, Matt Sebastien Rougeaux wrote: > Daniel,Bart, > > Just a thought about the sony chipset. The laptop port has only 4 pins > I believe (no power), whereas all the other cards tested so far must > have 6 pins ports. In theory it should'nt change a thing, but it might > worth a look (could be a slight difference in the chipset initialization > maybe)... > > -- > Sebastien Rougeaux > RSISE, The Australian National University > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare Technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Matt P. <ma...@ls...> - 2000-06-02 21:17:23
|
If you're referring to a camera that adheres to the Digital Camera Spec, the best way (the only way, I think) to tell start of frame is to look at the sy bit in the isoc packet header. The driver will have to (probably optionally) pass along the sy bit to whoever is interested in capturing the frame. I think OHCI and PCILynx have the capability of starting a DMA program conditionally on the sy bit. Regards, Matt Bart Nabbe wrote: > For those of you who are using the Ohci DMA code. > > Is there a way to determine if the frame in the dma buffer is valid? The > DMA has a counter > right, so if we have the number of bytes in one frame before a frame > start we have a valid > frame. I have some chopped frames one in a while, say 1/3 of the new > frame and 2/3 the > last frame that was on that position in the dma buffer. > > Are there also ideas about how multiple cameras should be handled is > they are to be used > with different applications? > > Any suggestions how to do any of this in a nice way? > > Thanks, > > Bart > > By the way what is the recent status of the Sony Ohci chipset? > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- /*********************** Matt Pujol Product Marketing Manager 1394 and USB CoreWare technologies LSI Logic 2001 Danfield Court Fort Collins, Co 80525 970-206-5816 mat...@ls... ***********************/ |
From: Arne S. <ar...@sc...> - 2000-06-02 20:39:59
|
Hi all, thanks to significant work of several people here I could fix a few bugs. Download the latest version from: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.82.tar.gz Bug fixes: Type-1 AVIs did not play with certain players, incorrect sound properties, dvgrab crashed when writing more than 2000 frames of Type-2 AVI data. In addition, I have included the patch for writing raw DV data for the playdv program posted by Alastair Mayer a few weeks ago. I think that this version is now quite stable and useable. No sound for Type-2 AVIs yet. Arne |
From: Daniel K. <dan...@st...> - 2000-06-02 17:45:36
|
On Fri, 2 Jun 2000, Andreas Bombe wrote: > I implemented that now and put it in CVS. This time you need to > update both kernel and libraw1394. By the way - how about setting a mailing list where CVS commit logs are sent to? We do it at the GLAME project, and I tend to find it terribly convenient. Regards, Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Andreas B. <and...@mu...> - 2000-06-02 17:09:40
|
On Fri, Jun 02, 2000 at 01:16:11AM +0200, Andreas Bombe wrote: > On Mon, May 29, 2000 at 05:45:35PM -0400, Ben Collins wrote: > > > Ok, I tested this and it worked. So I took it one step further. Attached > > > are two patches. One for linux1394 CVS which defines a kptr_t just like > > > you did for libraw1394. The other is for libraw1394 to sync the raw1394.h > > > from the kernel source. > > > > Guess attaching the patches would actually help. > > Using explicit width types for everything seems like a good idea. But > we can also just forget the environment and always use __u64 types for > the pointer fields. Writing a 64 bit field in a 32 bit environment > will clear the upper 32 and write the lower 32 bits, just like your > SET_CAST_PTR macro --- just cleaner and without endianness problems > (looking at your macro I can see Sparc is run big endian). I implemented that now and put it in CVS. This time you need to update both kernel and libraw1394. The compiler warnings (cast to/from pointer from/to int of different size) however annoy me. I'll see what I can do about that... -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Mark K. <mk...@co...> - 2000-06-02 15:05:11
|
I do note that, at least on my NT machine, everything that is playing at half speed is using the DVSoft Codec, while other formats are playing at the correct speed. Could that piece of software that account for this sort of problem? Task manager says that I'm using 80-90% of my machine playing these DV clips. I did some playing around a couple of months ago with the QuickTime Player under NT using the Tomorrow Never Dies trailer, and found that on most machines if I went much above 40-50% in task manager I started to drop frames and hear a lot of audio drop out. However, the clips always played in approximately the right amount of time. Using that measurement as a bar, it would seem that a lot of this is way beyond this machine's ability to play well, but I do not understand the 2x slowdown. -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Friday, June 02, 2000 3:33 AM To: 'Mark Knecht' Cc: 'Linux1394 Developer's Reflector (E-mail)' Subject: RE: DVGRAB/XDVPLAY testing I thought resp. was an abbreviation for "or". But it seems not to. If I think about it, it is even longer than the original word. Maybe it is a german abbreviation. The beach AVIs are the known good ones, if these do not play then it is a problem with the player software or the codec. This theory does not explain though why the dvgrab created type2 AVI plays and the reference AVI fails on your NT box. On my NT 4.0 SP5 system the playback of DV AVIs is very sluggish. Actually unuseable. The hardware is a bit better (AMD 400 / 96 MByte vs. AMD 333 / 64 MByte on the Windows98SE/Linux system). I am not sure whether this is an effect of the AVI format or a general feature of Windows NT. Playback of AVIs under W98SE is flawless though. Arne -----Original Message----- From: Mark Knecht [SMTP:mk...@co...] Sent: Thursday, June 01, 2000 8:00 PM To: Arne Schirmacher Subject: RE: DVGRAB/XDVPLAY testing dvgrab --format dv1 --frames 25 type1_ resp ?? What is the resp at the end? Anyway, results of my testing under NT 4.0: WMP RP_Ver.7 type1_001.avi fails fails type 2_001.avi plays plays beach_type1.avi fails fails beach_type2.avi audio audio only only I'll try these out tonight under 98SE at home. BTW - I think that 1 second clips will make it difficult to see if things are running at the right speed. They're too short to tell if they are 1, 1.5, or 2 seconds long. Cheers, Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Thursday, June 01, 2000 2:01 AM To: 'Mark Knecht'; 'Linux1394 Developer's Reflector (E-mail)' Subject: RE: DVGRAB/XDVPLAY testing Gread idea. I have just uploaded 4 different AVI scenes: http://www.schirmacher.de/arne/samples/ in dvgrab: one Type-1 and one Type-2 AVI files, PAL, 25 fps, 25 frames (1 second) The command line was dvgrab --format dv1 --frames 25 type1_ resp. dvgrab --format dv2 --frames 25 type2_ in ulead: one Type-1 and one Type-2 AVI files, PAL, 25 fps, 25 frames (1 second) I created these files with ULead 3.0 completely on the Windows98 box, including grabbing the raw source material. No dvgrab was involved. The two files show the same scene. I would consider the ULead generated AVIs as "the reference" (I don't have any other commercial grade DV Editing program, though I would like to use some of the real expensive programs to create my reference files). I can host about 250 MByte of test data, that's my limit for the website. Should be sufficient. I doubt however that testing a huge file would give any more information than testing a short one. Could you create a NTSC version of such test files? 2 files created by dvgrab (30 frames for NTSC) and 2 files created by some Windows Application. Regarding you new compatibility list: 1. Windows 98 plays both Type-1 and Type-2 NTSC AVIs generated by dvgrab. Great. The speed is correct too? 2. Windows NT fails with Type-1 NTSC AVIs, Type-2 NTSC AVIS play at half speed. I would like to try your AVIs here on my NT system. 3. RealPlayer Windows and Linux: The Linux version certainly doesn't have the right codec. I could not get RealPlayer to display my ULead AVIs too. So maybe this is not a dvgrab problem. 4. Quicktime: I need to reactivate my old PowerMac 7500 again... Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-06-02 14:28:08
|
I haven't looked into this in awhile, but a couple of years ago it was my understanding that most of the machines that implement cardbus are doing this behind what is essentially a PCI-PCI bridge. Could this be an issue here? Some of the early designs had trouble doing DMA behind these bridges, or at least the performance they could get was marginal at that time. Hopefully things have improved. -----Original Message----- From: Ben Collins [mailto:bco...@de...] Sent: Friday, June 02, 2000 7:09 AM To: Olivier Daigle Cc: Seb...@sy...; Linux1394-devel Subject: Re: ohci laptop ? On Fri, Jun 02, 2000 at 09:54:42AM -0400, Olivier Daigle wrote: > Sebastien, > I'm currently working on a project that will have a laptop linked to > other devices (including other computers) by FireWire. We bought a Ratoc > IEEE1394 CardBus card (CBFW1 model) that is supposed to be OHCI 1.0 > compliant (compatible with built-in Winslows98 drivers). I'm waiting for > some specs about this card. I tried to load standard ohci drivers to > make it work but, as I expected, it didn't work. I think that I will > have to (at least) rewrite the probing part of the driver to make it > compatible with CardBus interface. I should begin reading on the CardBus > standard (and the programming interface of the Linux PCMCIA Card > Service) by next week. > > Stay tuned for more info. If anybody in there have any experience with > any type of CardBus devices, please raise your hand. I have the same card from Ratoc and it works[1] with the ohci1394 driver. However, you have to reload the driver whenever you insert the card so it will detect it. I have a patch to avoid this by using the PCI API of the 2.3/2.4 kernels, but it isn't very backward compatible with 2.2.x kernels, so it most likely wouldn't be put into the main source. For PCI interface for 2.3/2.4 is completey compatible with CardBus cards. One driver for all should work, with autoprobing initiated by he kernel against a PCI vendor/make masks. Thing that is critical is that it means the driver/core wont initiate the probe. That means the core needs to be reworked a bit to allow the driver to handle the probe and register single cards with the core, or the driver will have to register the core to handle it's PCI probes. Either way, the change wont allow things to work with 2.2.x (atleast not in a way that the code looks clean). Ben [1] Atleast it detected the card and raw1394 testlibraw was able to probe it for testing. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Ben C. <bco...@de...> - 2000-06-02 14:15:50
|
On Fri, Jun 02, 2000 at 09:54:42AM -0400, Olivier Daigle wrote: > Sebastien, > I'm currently working on a project that will have a laptop linked to > other devices (including other computers) by FireWire. We bought a Ratoc > IEEE1394 CardBus card (CBFW1 model) that is supposed to be OHCI 1.0 > compliant (compatible with built-in Winslows98 drivers). I'm waiting for > some specs about this card. I tried to load standard ohci drivers to > make it work but, as I expected, it didn't work. I think that I will > have to (at least) rewrite the probing part of the driver to make it > compatible with CardBus interface. I should begin reading on the CardBus > standard (and the programming interface of the Linux PCMCIA Card > Service) by next week. > > Stay tuned for more info. If anybody in there have any experience with > any type of CardBus devices, please raise your hand. I have the same card from Ratoc and it works[1] with the ohci1394 driver. However, you have to reload the driver whenever you insert the card so it will detect it. I have a patch to avoid this by using the PCI API of the 2.3/2.4 kernels, but it isn't very backward compatible with 2.2.x kernels, so it most likely wouldn't be put into the main source. For PCI interface for 2.3/2.4 is completey compatible with CardBus cards. One driver for all should work, with autoprobing initiated by he kernel against a PCI vendor/make masks. Thing that is critical is that it means the driver/core wont initiate the probe. That means the core needs to be reworked a bit to allow the driver to handle the probe and register single cards with the core, or the driver will have to register the core to handle it's PCI probes. Either way, the change wont allow things to work with 2.2.x (atleast not in a way that the code looks clean). Ben [1] Atleast it detected the card and raw1394 testlibraw was able to probe it for testing. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: Olivier D. <dai...@el...> - 2000-06-02 13:57:52
|
Sebastien, I'm currently working on a project that will have a laptop linked to other devices (including other computers) by FireWire. We bought a Ratoc IEEE1394 CardBus card (CBFW1 model) that is supposed to be OHCI 1.0 compliant (compatible with built-in Winslows98 drivers). I'm waiting for some specs about this card. I tried to load standard ohci drivers to make it work but, as I expected, it didn't work. I think that I will have to (at least) rewrite the probing part of the driver to make it compatible with CardBus interface. I should begin reading on the CardBus standard (and the programming interface of the Linux PCMCIA Card Service) by next week. Stay tuned for more info. If anybody in there have any experience with any type of CardBus devices, please raise your hand. Regards, Olivier Sebastien Rougeaux wrote: > Hi, > > Has anybody succeeded getting the ohci driver working on a laptop, > either via cardbus or the embeded chipset ? If so, could you tell > me what system you are using. > > BTW, I apologize for not responding to the many requests concerning > the ohci driver. I am away on a business trip to Europe, and I will > be back to work next week. > > Cheers, > > -- > Sebastien Rougeaux > RSISE, The Australian National University > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel -- Olivier Daigle Projet Harfang (514) 396-8800 ext.7699 |
From: Arne S. <ar...@sc...> - 2000-06-02 10:50:18
|
I thought resp. was an abbreviation for "or". But it seems not to. If I think about it, it is even longer than the original word. Maybe it is a german abbreviation. The beach AVIs are the known good ones, if these do not play then it is a problem with the player software or the codec. This theory does not explain though why the dvgrab created type2 AVI plays and the reference AVI fails on your NT box. On my NT 4.0 SP5 system the playback of DV AVIs is very sluggish. Actually unuseable. The hardware is a bit better (AMD 400 / 96 MByte vs. AMD 333 / 64 MByte on the Windows98SE/Linux system). I am not sure whether this is an effect of the AVI format or a general feature of Windows NT. Playback of AVIs under W98SE is flawless though. Arne -----Original Message----- From: Mark Knecht [SMTP:mk...@co...] Sent: Thursday, June 01, 2000 8:00 PM To: Arne Schirmacher Subject: RE: DVGRAB/XDVPLAY testing dvgrab --format dv1 --frames 25 type1_ resp ?? What is the resp at the end? Anyway, results of my testing under NT 4.0: WMP RP_Ver.7 type1_001.avi fails fails type 2_001.avi plays plays beach_type1.avi fails fails beach_type2.avi audio audio only only I'll try these out tonight under 98SE at home. BTW - I think that 1 second clips will make it difficult to see if things are running at the right speed. They're too short to tell if they are 1, 1.5, or 2 seconds long. Cheers, Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Thursday, June 01, 2000 2:01 AM To: 'Mark Knecht'; 'Linux1394 Developer's Reflector (E-mail)' Subject: RE: DVGRAB/XDVPLAY testing Gread idea. I have just uploaded 4 different AVI scenes: http://www.schirmacher.de/arne/samples/ in dvgrab: one Type-1 and one Type-2 AVI files, PAL, 25 fps, 25 frames (1 second) The command line was dvgrab --format dv1 --frames 25 type1_ resp. dvgrab --format dv2 --frames 25 type2_ in ulead: one Type-1 and one Type-2 AVI files, PAL, 25 fps, 25 frames (1 second) I created these files with ULead 3.0 completely on the Windows98 box, including grabbing the raw source material. No dvgrab was involved. The two files show the same scene. I would consider the ULead generated AVIs as "the reference" (I don't have any other commercial grade DV Editing program, though I would like to use some of the real expensive programs to create my reference files). I can host about 250 MByte of test data, that's my limit for the website. Should be sufficient. I doubt however that testing a huge file would give any more information than testing a short one. Could you create a NTSC version of such test files? 2 files created by dvgrab (30 frames for NTSC) and 2 files created by some Windows Application. Regarding you new compatibility list: 1. Windows 98 plays both Type-1 and Type-2 NTSC AVIs generated by dvgrab. Great. The speed is correct too? 2. Windows NT fails with Type-1 NTSC AVIs, Type-2 NTSC AVIS play at half speed. I would like to try your AVIs here on my NT system. 3. RealPlayer Windows and Linux: The Linux version certainly doesn't have the right codec. I could not get RealPlayer to display my ULead AVIs too. So maybe this is not a dvgrab problem. 4. Quicktime: I need to reactivate my old PowerMac 7500 again... Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Arne S. <ar...@sc...> - 2000-06-02 10:50:14
|
Hi Bernhard, thanks for the extensive test report, what was the application that you used to create the well - playing AVI files under Windows? Can you provide the URLs for the tools you mentioned? Please enter them in http://www.schirmacher.de/cgi-bin/dclinks.cgi somewhere or just send an email. I have already fixed a bug where I used 44.1 KHz in one field and 48 KHz in another. It is in fact mono (currently), because there is no advantage storing stereo silence compared to storing mono silence. Arne -----Original Message----- From: Bernhard Schwall [SMTP:bs...@gm...] Sent: Friday, June 02, 2000 1:06 AM To: lin...@li... Subject: dvgrab-0.81 testing results Hallo Arne, I've played with your new dvgrab-0.81 and tested the resulting AVI under Win98 and w2k. My system: Athlon 700, 192MB ram, Maxtor 60GB EIDE HD, ExSys 6500, Sony TRV310E (Pal) w2k: Type-1 playes with media player but it has a lot of problems playing it realtime. AVIs recorded under Windows I can play realtime without any jumps in the playback in 352x288 (or whatever resolution the CoDec really uses, but it's quarter Pal res.). The dvgrab AVI often jump within the first playback. Playing back it more times (so the short 300 frames AVI is in the cache) it plays correctly. So it looks like the format is a bit different to the "expected" format. Type-2 even plays with the media player (without sound of course) but also with some jumps in the first playback. The properties say it has a length of 13.6 but it only has 12 seconds (300 frames). And also the sound type is told to be 44.1 KHz with 16 bit and mono! The original was 48 KHz, 16 bit and stereo. Copying the Type-2 AVI with VirtualDub (with direct stream copy) the file gets shorter (43246 KB to 43327 KB) and now has the correct length (12 sec.). Sending back the files to camera using DVIO I had success with the original Type-1 AVI and the VDub-copied one. Playing the dvgrab-Type2 AVI it stops within the playback and skips some frames to get back into sync. win98SE: playing files with media player is no problem. And even playing back them to the camera is neither a problem with Type 1 nor with Type 2. So for me it looks like either a problem with my system under w2k (HD performance) or a problem with the DV codecs. I've installed the Adaptec DV-CoDec under w2k but haven't done this under win98SE. Using benchmark tools to get the HD performance I get the same results under w2k and win98 (over 9MB/s for read and write) so normally this shouldn't be a problem. And w2k tells me that it's using DMA access for the HD and the benchmark tells me that the CPU load is between 2% and 6% depending on the HD used. This is equal for w2k and win98. BTW I'm using the original ms-dv driver under w2k and win98se with the upgrade for win98se from MS (243174up.exe). w2k also has an installed ulead video studio 3 version. Greetings Bernhard _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Sebastien R. <Seb...@sy...> - 2000-06-02 10:14:15
|
Daniel,Bart, Just a thought about the sony chipset. The laptop port has only 4 pins I believe (no power), whereas all the other cards tested so far must have 6 pins ports. In theory it should'nt change a thing, but it might worth a look (could be a slight difference in the chipset initialization maybe)... -- Sebastien Rougeaux RSISE, The Australian National University |
From: Sebastien R. <Seb...@sy...> - 2000-06-02 09:08:46
|
Hi, Has anybody succeeded getting the ohci driver working on a laptop, either via cardbus or the embeded chipset ? If so, could you tell me what system you are using. BTW, I apologize for not responding to the many requests concerning the ohci driver. I am away on a business trip to Europe, and I will be back to work next week. Cheers, -- Sebastien Rougeaux RSISE, The Australian National University |
From: Daniel K. <dan...@st...> - 2000-06-02 08:43:42
|
On Thu, 1 Jun 2000, Bart Nabbe wrote: > By the way what is the recent status of the Sony Ohci chipset? I think I've been the last one so far to give that a try. But frankly, I've given up for the moment. If I hook up the Sony to an OHCI card in my desktop, the Sony shows up in gscanbus on the desktop. The upper layers in the Sony chip itself however never receive any SelfID, not even their own, and consequently the bus reset phase lasts forever. I wasn't able to find out why this is the - register dump looks good and implementations seems to be to specs. I've tried to contact Sony support for some hints but as expected no reply. Does anyone here have information that might get me further? A personal mail address of some IEEE expert with Sony maybe? Daniel. -- GNU/Linux Audio Mechanics - http://www.glame.de GPG Key ID 89BF7E2B - http://www.keyserver.net |
From: Andreas B. <and...@mu...> - 2000-06-01 23:19:35
|
On Mon, May 29, 2000 at 05:45:35PM -0400, Ben Collins wrote: > > Ok, I tested this and it worked. So I took it one step further. Attached > > are two patches. One for linux1394 CVS which defines a kptr_t just like > > you did for libraw1394. The other is for libraw1394 to sync the raw1394.h > > from the kernel source. > > Guess attaching the patches would actually help. > >-- [...] > struct raw1394_request { > - int type; > - int error; > - int misc; > - > - unsigned int generation; > - octlet_t address; > - > - unsigned long tag; > - > - size_t length; > - quadlet_t *sendb; > - quadlet_t *recvb; > + __s32 type; > + __s32 error; > + __s32 misc; > + > + __u32 generation; > + __u64 address; > + > + __u64 tag; > + > + __u32 length; > +#ifdef __KERNEL__ > + raw1394_kptr_t sendb; > + raw1394_kptr_t recvb; > +#else > +/* We use this to make it easy to pass pointers to the kernel, > + * even in mixed 32/64 bit environments */ > +#define SET_CAST_PTR(x,p) \ > +if (sizeof(void *) == sizeof(__u32)) { \ > + x.large = 0; \ > + x.small[1] = (__u32)p; \ > +} else { \ > + x.large = (__u64)p; \ > +} > + > + union { > + __u32 small[2]; > + __u64 large; > + } sendb; > + union { > + __u32 small[2]; > + __u64 large; > + } recvb; > +#endif > }; Using explicit width types for everything seems like a good idea. But we can also just forget the environment and always use __u64 types for the pointer fields. Writing a 64 bit field in a 32 bit environment will clear the upper 32 and write the lower 32 bits, just like your SET_CAST_PTR macro --- just cleaner and without endianness problems (looking at your macro I can see Sparc is run big endian). If we'd be really tightassed, we could make autoconf efforts to make those types 32 bit on fully 32 bit platforms like x86, but zeroing a few bytes really shouldn't be a performance problem. I'll try that tomorrow. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Bernhard S. <bs...@gm...> - 2000-06-01 21:08:46
|
Hallo Arne, I've played with your new dvgrab-0.81 and tested the resulting AVI under Win98 and w2k. My system: Athlon 700, 192MB ram, Maxtor 60GB EIDE HD, ExSys 6500, Sony TRV310E (Pal) w2k: Type-1 playes with media player but it has a lot of problems playing it realtime. AVIs recorded under Windows I can play realtime without any jumps in the playback in 352x288 (or whatever resolution the CoDec really uses, but it's quarter Pal res.). The dvgrab AVI often jump within the first playback. Playing back it more times (so the short 300 frames AVI is in the cache) it plays correctly. So it looks like the format is a bit different to the "expected" format. Type-2 even plays with the media player (without sound of course) but also with some jumps in the first playback. The properties say it has a length of 13.6 but it only has 12 seconds (300 frames). And also the sound type is told to be 44.1 KHz with 16 bit and mono! The original was 48 KHz, 16 bit and stereo. Copying the Type-2 AVI with VirtualDub (with direct stream copy) the file gets shorter (43246 KB to 43327 KB) and now has the correct length (12 sec.). Sending back the files to camera using DVIO I had success with the original Type-1 AVI and the VDub-copied one. Playing the dvgrab-Type2 AVI it stops within the playback and skips some frames to get back into sync. win98SE: playing files with media player is no problem. And even playing back them to the camera is neither a problem with Type 1 nor with Type 2. So for me it looks like either a problem with my system under w2k (HD performance) or a problem with the DV codecs. I've installed the Adaptec DV-CoDec under w2k but haven't done this under win98SE. Using benchmark tools to get the HD performance I get the same results under w2k and win98 (over 9MB/s for read and write) so normally this shouldn't be a problem. And w2k tells me that it's using DMA access for the HD and the benchmark tells me that the CPU load is between 2% and 6% depending on the HD used. This is equal for w2k and win98. BTW I'm using the original ms-dv driver under w2k and win98se with the upgrade for win98se from MS (243174up.exe). w2k also has an installed ulead video studio 3 version. Greetings Bernhard |
From: Ichiro S. <ic...@fn...> - 2000-06-01 21:06:17
|
Hi all, I also had the same (or similar) problem. Connecting two OHCI cards directly, Node-ID 0 is assigned to one card and 2 (instead of 1) is assigned to the other. Then, the Self-ID process fails. Sometime, I observed wrong Seld-ID, 0800FFC0 on one card. I didn't make tests in systematic way and I'm not sure if this behavior is alway same, sorry. And, I found a workaround, use non-OHCI card as a root node. When I connect these OHCI cards to a PCILynx card or an unknown chip-set card, these cards successfully finished a Self-ID process and valid Node-IDs are assigned. My configurations are; o OHCI card: D-Link DFW-500 (TI's TSB12LV23 and TSB41LV03) o PCILynx: TI TSBKPCI403 (TSB12LV21B and TSB21LV03 ?) o Unknown chip-set: On-board I/F of Compaq SP700 o Linux 2.2.14, ieee1394-2.2.14-20000318, libraw1394-0.6 Thanks, ----------------------------------------------------------------- Ichiro Suzuki ic...@fn..., http://home.fnal.gov/~ichiro/ PPD/EPP, Fermi National Accelerator Laboratory, Batavia, Illinois ----------------------------------------------------------------- |
From: Bart N. <ba...@cs...> - 2000-06-01 19:42:47
|
For those of you who are using the Ohci DMA code. Is there a way to determine if the frame in the dma buffer is valid? The DMA has a counter right, so if we have the number of bytes in one frame before a frame start we have a valid frame. I have some chopped frames one in a while, say 1/3 of the new frame and 2/3 the last frame that was on that position in the dma buffer. Are there also ideas about how multiple cameras should be handled is they are to be used with different applications? Any suggestions how to do any of this in a nice way? Thanks, Bart By the way what is the recent status of the Sony Ohci chipset? |
From: Mark W. K. <mar...@ho...> - 2000-06-01 11:46:43
|
-----Original Message----- From: lin...@li... [mailto:lin...@li...]On Behalf Of Arne Schirmacher Sent: Thursday, June 01, 2000 2:01 AM To: 'Mark Knecht'; 'Linux1394 Developer's Reflector (E-mail)' Subject: RE: DVGRAB/XDVPLAY testing <snip> Regarding you new compatibility list: 1. Windows 98 plays both Type-1 and Type-2 NTSC AVIs generated by dvgrab. Great. The speed is correct too? *** Yep - the speed seems exactly right. *** 2. Windows NT fails with Type-1 NTSC AVIs, Type-2 NTSC AVIS play at half speed. I would like to try your AVIs here on my NT system. *** I can upload the 10 second clips to the same ftp site, and then you can take them off if they take up too much spec. *** 3. RealPlayer Windows and Linux: The Linux version certainly doesn't have the right codec. I could not get RealPlayer to display my ULead AVIs too. So maybe this is not a dvgrab problem. *** I agree, although it would be good to get someone from Real, Inc. on this project also! I'm surprised we're having more problems with Real Player than the other platforms. *** 4. Quicktime: I need to reactivate my old PowerMac 7500 again... *** Again, QuickTime for Windows also... *** Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |