linux1394-devel Mailing List for IEEE 1394 for Linux (Page 539)
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: Sebastien R. <Seb...@sy...> - 2000-04-14 00:45:43
|
>>>>> "Anders" == Anders Weitman <And...@no...> writes: Anders> Hi Andreas and Sebastien, I was wondering if you could give me some Anders> estimate of when to expect DMA transfer or mapping of iso data to user Anders> space? I would really want to have this for our DV decoder. I am quite busy right now with my work, so I am not actively working on this at the moment. If you look at the list archive, a Japanese guy did write a patch for it, but it has to be modified to work with the current driver, and I think I will end up rewriting part of it anyway once I have some time. I will soon need it anyway, so I might work on this again in a month or two. In the mean time, we will need to define an API to get this working with the subsystem. -- Sebastien Rougeaux RSISE, The Australian National University |
From: Mark K. <mk...@co...> - 2000-04-13 21:26:42
|
I would be interested in helping out with some of the testing in this area. I have a Sony i-Link CD/RW drive which is probably SBP-2 compatible that I would love to get working under Linux. -----Original Message----- From: Stefan Lucke [mailto:lu...@be...] Sent: Thursday, April 13, 2000 2:12 PM To: lin...@li... Subject: SBP-2 (who ?, specs?) Who is working on SBP-2 implementaion on this and are there any specs available ? -- Stefan Lucke (lu...@be...) _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Stefan L. <lu...@be...> - 2000-04-13 21:15:32
|
Who is working on SBP-2 implementaion on this and are there any specs available ? -- Stefan Lucke (lu...@be...) |
From: Bryan S. <ar...@ve...> - 2000-04-13 18:59:27
|
Ok, I tried both even though it's supposed to be ntsc. Neither worked. --ntsc did the same thing as without specifying anything. --pal had a lot of Xs when running dvgrab, which was to be expected. I didn't get a screen shot, but the movie scrolled upwards pretty quickly and I could make out any of the video. With --ntsc it was all boxy just like before, and just like before each box was always rendering the same portion of the video, just in the wrong place. Some things I've noticed though. The outputted avi shows up as being 360x240 in the properties section of media player instead of 720x480 like I though it would. Each rectangle appears to be 32x8 if it was in 720x480 mode, and I remember in some documentation that I was reading that that size is special for DV stuff. Bryan On Thu, 13 Apr 2000, Arne Schirmacher wrote: > did you use the --pal or --ntsc parameter, depending of the type of your camera? > > Arne > > -----Original Message----- > From: Bryan Stillwell > Sent: Wednesday, April 12, 2000 10:10 PM > To: Arne Schirmacher > Cc: lin...@li... > Subject: RE: dvgrab > > Nope, neither Microsoft Media Player or ULead VideoStudio worked. They > both in fact created the same screwed up picture. The movie plays, but > the picture is screwed and audio is just a hiss. > > Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture > looks like. You can definately tell that it's rendering some parts > correctly, but they're in weird places... > > It might have something to do with when I compiled everything. I ran into > a problem compiling dvgrab and had to update a few libraries. The > standard compiler in Debian now is egcs based, and for me it dies of an > internal compiler error when compiling the kernel. I was using the older > compiler, but I think dvgrab required g++ so I had to install the latest > stuff. > |
From: Bryan S. <ar...@ve...> - 2000-04-13 17:16:55
|
I didn't specify either, I thought it defaulted to ntsc which is what the camera is. I'll try again during my lunch in an hour with --ntsc and see if it helps. Hell, I'll try it with --pal as well to see what the difference is... Bryan On Thu, 13 Apr 2000, Arne Schirmacher wrote: > did you use the --pal or --ntsc parameter, depending of the type of your camera? > > Arne > > -----Original Message----- > From: Bryan Stillwell > Sent: Wednesday, April 12, 2000 10:10 PM > To: Arne Schirmacher > Cc: lin...@li... > Subject: RE: dvgrab > > Nope, neither Microsoft Media Player or ULead VideoStudio worked. They > both in fact created the same screwed up picture. The movie plays, but > the picture is screwed and audio is just a hiss. > > Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture > looks like. You can definately tell that it's rendering some parts > correctly, but they're in weird places... > > It might have something to do with when I compiled everything. I ran into > a problem compiling dvgrab and had to update a few libraries. The > standard compiler in Debian now is egcs based, and for me it dies of an > internal compiler error when compiling the kernel. I was using the older > compiler, but I think dvgrab required g++ so I had to install the latest > stuff. > |
From: Arne S. <ar...@sc...> - 2000-04-13 17:09:13
|
That would be in fact the next step, but currently there is no iso write function available in the device driver. Which is really annoying because the dumb ULead VideoStudio program can only write one single file back to the camcorder, which is limited to 4 GByte in size, which is no more than 15 minutes. Dear 1394 device driver programmers: please make a iso write function. The Linux world needs it ... :-) Cheers, Arne -----Original Message----- From: Timothy M. Shead Sent: Wednesday, April 12, 2000 11:11 PM Cc: lin...@li... Subject: Re: dvgrab I've been following dvgrab with a lot of interest, and just got it working last night. I'm thinking that, rather than putting too much time into figuring out how view an AVI, it would be more productive to: * Capture the video to disk using dvgrab --raw * Write a program that can read the raw file and write it back to the firewire interface isochronously, so it can be viewed using a camcorder. Since this would allow you to visually verify that the capture worked, without actually decoding it, I'm hoping it will be a (relatively) easy first step towards creating an actual DV decoder. Plus it would be an important component of a future open-source non-linear editor. Tim Shead ts...@k-... ----- Original Message ----- From: "Bryan Stillwell" <ar...@ve...> To: "Arne Schirmacher" <ar...@sc...> Cc: <lin...@li...> Sent: Wednesday, April 12, 2000 1:09 PM Subject: RE: dvgrab > Nope, neither Microsoft Media Player or ULead VideoStudio worked. They > both in fact created the same screwed up picture. The movie plays, but > the picture is screwed and audio is just a hiss. > > Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture > looks like. You can definately tell that it's rendering some parts > correctly, but they're in weird places... > > It might have something to do with when I compiled everything. I ran into > a problem compiling dvgrab and had to update a few libraries. The > standard compiler in Debian now is egcs based, and for me it dies of an > internal compiler error when compiling the kernel. I was using the older > compiler, but I think dvgrab required g++ so I had to install the latest > stuff. > > Thanks for any help, > Bryan > > On Wed, 12 Apr 2000, Arne Schirmacher wrote: > > > An AVI file is actually a sort of container that can contain lots of different > > file formats. It has a field that tells which decoder is required for playing > > this particular file type. If the player program does not know about the file > > type, it can't display the movie. > > > > Currently there is no AVI player for Linux that can decode the AVI DV format. > > > > You can use the Microsoft media player to play back your AVI file. In case it > > does not recognize the file format either, try installing the video editing > > software that came with your card. If you don't have software, download the > > demo version of ULead VideoStudio (the media player extensions are not time > > limited). > > > > I am not aware of any converter programs for MS Windows, but there should be > > alot. > > > > If everything fails (but I don't think so), drop me a note. > > > > Happy grabbing.... Arne > > > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Arne S. <ar...@sc...> - 2000-04-13 17:09:10
|
did you use the --pal or --ntsc parameter, depending of the type of your camera? Arne -----Original Message----- From: Bryan Stillwell Sent: Wednesday, April 12, 2000 10:10 PM To: Arne Schirmacher Cc: lin...@li... Subject: RE: dvgrab Nope, neither Microsoft Media Player or ULead VideoStudio worked. They both in fact created the same screwed up picture. The movie plays, but the picture is screwed and audio is just a hiss. Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture looks like. You can definately tell that it's rendering some parts correctly, but they're in weird places... It might have something to do with when I compiled everything. I ran into a problem compiling dvgrab and had to update a few libraries. The standard compiler in Debian now is egcs based, and for me it dies of an internal compiler error when compiling the kernel. I was using the older compiler, but I think dvgrab required g++ so I had to install the latest stuff. |
From: Alastair M. <ala...@ww...> - 2000-04-13 16:50:55
|
Timothy M. Shead wrote: > > I've been following dvgrab with a lot of interest, and just got it working > last night. I'm thinking that, rather than putting too much time into > figuring out how view an AVI, it would be more productive to: > > * Capture the video to disk using dvgrab --raw > * Write a program that can read the raw file and write it back to the > firewire interface isochronously, so it can be viewed using a camcorder. I'd been thinking along the same lines, but with an additional ulterior motive (I'll get to in a moment). Meanwhile, Windows Media Player apparently can read raw DV files (er, make that MoviePlayer). At least it recognizes the single-frame DV grabs I downloaded from somebody's web site, although being single frames it doesn't play them. It does correctly report the meta-information. (Perhaps somebody could point me too a short DV video clip for me to experiment with?) The ulterior motive is that pushing the DV data back to the camera is a necessary step for doing DV editing. (Pushing it back to a recorder, actually). It's also a necessary step for using a camcorder as a backup device (using the video frame to store arbitrary data rather than images), a project I'm getting some enthusiasm for (see http://www.ajwm.net/backfire ) (No code yet, I'm still working on getting my camcorder to talk happily to my 1394 card. Turns out I didn't have the latest (0318) patch to 2.2.14) Of course a program to play DV files directly under Linux would be nice for us DV enthusiasts, but that's another issue. -- Alastair |
From: <And...@no...> - 2000-04-13 10:24:55
|
Hi Andreas and Sebastien, I was wondering if you could give me some estimate of when to expect DMA transfer or mapping of iso data to user space? I would really want to have this for our DV decoder. Best regards, Anders Weitman PS. I'm still trying to get approval for releasing the code for the DV decoder but it's a difficult issue and the lawyers and patent people are a bit slow (: _____________________________________________________________________ Anders Weitman, M.Sc Phone : +46 (0)13 4611341 Development Engineer Fax : +46 (0)13 4611001 Nokia Home Communications Mobile : +46 (0)70 2141319 Diskettgatan 11 E-mail : and...@no... SE-583 35 Linkoping, Sweden Internet : www.nokia.com/multimedia/ |
From: Hiromasa Y. <yos...@li...> - 2000-04-13 02:43:47
|
Sebastien Rougeaux <Seb...@sy...> wrote: > I have implemented a fix that was proposed a while ago by > Robert Ficklin <rfi...@we...>. It should solve > the problem people were having with the node count staying at zero > all the time. It should also solve the bug that happen when the > card is initialized with no device connected to the bus, and then > cannot detect any device afterward. Please try it (available > from CVS at sourceforge) and tell me if you encounter any problem. I try it with Sony VAIO Laptop (CXD3222,OHCI,1394.a). When I connect VAIO, repeater and PC (TSB12LV23,OHCI), PC's node count is three, but VAIO's node count is still zero. I found VAIO's busReset Interrupt has assert correctly, but selfIDComplete Interrupt has never asserted. I wrote a few code to dump Port Status Register of PHY chip, it seems to be working normal. I'm confused. I think I need to look over 1394 OHCI specification. -- Hiromasa Yoshimoto / yos...@li... |
From: Timothy M. S. <ts...@k-...> - 2000-04-12 21:18:11
|
I've been following dvgrab with a lot of interest, and just got it working last night. I'm thinking that, rather than putting too much time into figuring out how view an AVI, it would be more productive to: * Capture the video to disk using dvgrab --raw * Write a program that can read the raw file and write it back to the firewire interface isochronously, so it can be viewed using a camcorder. Since this would allow you to visually verify that the capture worked, without actually decoding it, I'm hoping it will be a (relatively) easy first step towards creating an actual DV decoder. Plus it would be an important component of a future open-source non-linear editor. Tim Shead ts...@k-... ----- Original Message ----- From: "Bryan Stillwell" <ar...@ve...> To: "Arne Schirmacher" <ar...@sc...> Cc: <lin...@li...> Sent: Wednesday, April 12, 2000 1:09 PM Subject: RE: dvgrab > Nope, neither Microsoft Media Player or ULead VideoStudio worked. They > both in fact created the same screwed up picture. The movie plays, but > the picture is screwed and audio is just a hiss. > > Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture > looks like. You can definately tell that it's rendering some parts > correctly, but they're in weird places... > > It might have something to do with when I compiled everything. I ran into > a problem compiling dvgrab and had to update a few libraries. The > standard compiler in Debian now is egcs based, and for me it dies of an > internal compiler error when compiling the kernel. I was using the older > compiler, but I think dvgrab required g++ so I had to install the latest > stuff. > > Thanks for any help, > Bryan > > On Wed, 12 Apr 2000, Arne Schirmacher wrote: > > > An AVI file is actually a sort of container that can contain lots of different > > file formats. It has a field that tells which decoder is required for playing > > this particular file type. If the player program does not know about the file > > type, it can't display the movie. > > > > Currently there is no AVI player for Linux that can decode the AVI DV format. > > > > You can use the Microsoft media player to play back your AVI file. In case it > > does not recognize the file format either, try installing the video editing > > software that came with your card. If you don't have software, download the > > demo version of ULead VideoStudio (the media player extensions are not time > > limited). > > > > I am not aware of any converter programs for MS Windows, but there should be > > alot. > > > > If everything fails (but I don't think so), drop me a note. > > > > Happy grabbing.... Arne > > > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: Mark K. <mk...@co...> - 2000-04-12 20:28:05
|
Jeff, In general I agree with you, but it may in practice not be that simple... 1394 OHCI requires the use of a 1394a Phy. The problem is that 1394a was just approved within the last month, and while the spec has been stable for some time, there is no guarantee that everyone's 1394a Phys are truly compatible with the 1394a spec. There is usually a period of time where new hardware is getting released and the market determines, over time, what works and what doesn't. Keep in mind that much of the hardware we are looking at today may not have been placed under significant enough scrutiny to truly be deemed 'compliant'. This said, 1394a defines a new state called 'disabled'. If the Phy on your card is somehow in the disabled state, then the spec says it is not capable of detecting any signals. (Don't ask me how your Phy got into this state! I'm just suggesting that if the driver isn't careful there could be a problem here that is detectable and correctable in software that we would not be addressing today.) If this is the case, then the answer to your question is "No. There would not be a hardware reset". (At least the way I read the spec....) Keep plugging away and I'm sure you'll find the clue that helps the code guys (I'm a hardware guy) get the problem resolved. With best regards, Mark -----Original Message----- From: Jeff Mak [mailto:Jef...@ef...] Sent: Wednesday, April 12, 2000 11:07 AM To: 'Mark Knecht'; 'lin...@li...' Subject: RE: Bus Reset Mark, Thanks for the information you provided. The bus reset interrupt would be generated to the driver when the firewire detects there is a change in condition, right? In this case, I am thinking should it be controlled by hardware side (Firewire card itself) rather than checking port status register? Thanks, Jeff -----Original Message----- From: Mark Knecht [ mailto:mk...@co...] Sent: Wednesday, April 12, 2000 9:37 AM To: Jeff Mak; 'lin...@li...' Subject: RE: Bus Reset The Port Status Registers of a 1394a Phy provide the following indications: Connected - Is the cable attached to another 1394 device? Bias - Is that device providing TPBIAS? Disabled - Is this port of our Phy enabled or disabled? The use of these bits was envisioned as providing the information necessary to answer the questions you posed Jeff. I am unclear whether the Linux 1394 driver is taking advantage of these features at this time. It is possible that another thread having to do with the Sony OHCI implementation may be impacted by the state of these bits also. Cheers -----Original Message----- From: Jeff Mak [ mailto:Jef...@ef...] Sent: Tuesday, April 11, 2000 5:01 PM To: 'lin...@li...' Subject: Bus Reset For OHCI driver, whenever the target node is power off, bus reset would be generated. For IEEE1394, there are some power management i.e. the node is self-powered and this has been implemented in my target node. However, the bus reset signal is still generated causing my linux box cannot communicate with the target node anymore. My question is how to distinguish a target node from "power off" to "connection failed" i.e no bus reset would generate under "power off" connection ? Thanks, Jeff |
From: Bryan S. <ar...@ve...> - 2000-04-12 20:16:41
|
Nope, neither Microsoft Media Player or ULead VideoStudio worked. They both in fact created the same screwed up picture. The movie plays, but the picture is screwed and audio is just a hiss. Go to http://www.verinet.com/~arcane/screwedup.jpg to see what the picture looks like. You can definately tell that it's rendering some parts correctly, but they're in weird places... It might have something to do with when I compiled everything. I ran into a problem compiling dvgrab and had to update a few libraries. The standard compiler in Debian now is egcs based, and for me it dies of an internal compiler error when compiling the kernel. I was using the older compiler, but I think dvgrab required g++ so I had to install the latest stuff. Thanks for any help, Bryan On Wed, 12 Apr 2000, Arne Schirmacher wrote: > An AVI file is actually a sort of container that can contain lots of different > file formats. It has a field that tells which decoder is required for playing > this particular file type. If the player program does not know about the file > type, it can't display the movie. > > Currently there is no AVI player for Linux that can decode the AVI DV format. > > You can use the Microsoft media player to play back your AVI file. In case it > does not recognize the file format either, try installing the video editing > software that came with your card. If you don't have software, download the > demo version of ULead VideoStudio (the media player extensions are not time > limited). > > I am not aware of any converter programs for MS Windows, but there should be > alot. > > If everything fails (but I don't think so), drop me a note. > > Happy grabbing.... Arne > |
From: Jeff M. <Jef...@ef...> - 2000-04-12 18:13:48
|
Mark, Thanks for the information you provided. The bus reset interrupt would = be generated to the driver when the firewire detects there is a change in condition, right? In this case, I am thinking should it be controlled = by hardware side (Firewire card itself) rather than checking port status register? Thanks, Jeff -----Original Message----- From: Mark Knecht [mailto:mk...@co...] Sent: Wednesday, April 12, 2000 9:37 AM To: Jeff Mak; 'lin...@li...' Subject: RE: Bus Reset The Port Status Registers of a 1394a Phy provide the following = indications: =A0 Connected - Is the cable attached to another 1394 device? Bias - Is that device providing TPBIAS? Disabled - Is this port of our Phy enabled or disabled? =A0 The use of these bits was envisioned as providing the information = necessary to answer the questions you posed Jeff. =A0 I am unclear whether the Linux 1394 driver is taking advantage of these features at this time. It is possible that another thread having to do = with the Sony OHCI implementation may be impacted by the state of these bits also. =A0 Cheers -----Original Message----- From: Jeff Mak [mailto:Jef...@ef...] Sent: Tuesday, April 11, 2000 5:01 PM To: 'lin...@li...' Subject: Bus Reset For OHCI driver, whenever the target node is power off, bus reset would = be generated.=A0=A0 For IEEE1394,=A0 there are some power management i.e. = the node is self-powered and this has been implemented in my target node.=A0=A0 = However, the bus reset signal is still generated causing my linux box cannot = communicate with the target node anymore.=A0=A0=A0 My question is how to = distinguish a target node from "power off" to "connection failed" i.e no bus reset would = generate under "power off" connection ? Thanks,=20 Jeff=20 |
From: Arne S. <ar...@sc...> - 2000-04-12 17:56:08
|
An AVI file is actually a sort of container that can contain lots of different file formats. It has a field that tells which decoder is required for playing this particular file type. If the player program does not know about the file type, it can't display the movie. Currently there is no AVI player for Linux that can decode the AVI DV format. You can use the Microsoft media player to play back your AVI file. In case it does not recognize the file format either, try installing the video editing software that came with your card. If you don't have software, download the demo version of ULead VideoStudio (the media player extensions are not time limited). I am not aware of any converter programs for MS Windows, but there should be alot. If everything fails (but I don't think so), drop me a note. Happy grabbing.... Arne |
From: Mark K. <mk...@co...> - 2000-04-12 16:44:01
|
The Port Status Registers of a 1394a Phy provide the following indications: Connected - Is the cable attached to another 1394 device? Bias - Is that device providing TPBIAS? Disabled - Is this port of our Phy enabled or disabled? The use of these bits was envisioned as providing the information necessary to answer the questions you posed Jeff. I am unclear whether the Linux 1394 driver is taking advantage of these features at this time. It is possible that another thread having to do with the Sony OHCI implementation may be impacted by the state of these bits also. Cheers -----Original Message----- From: Jeff Mak [mailto:Jef...@ef...] Sent: Tuesday, April 11, 2000 5:01 PM To: 'lin...@li...' Subject: Bus Reset For OHCI driver, whenever the target node is power off, bus reset would be generated. For IEEE1394, there are some power management i.e. the node is self-powered and this has been implemented in my target node. However, the bus reset signal is still generated causing my linux box cannot communicate with the target node anymore. My question is how to distinguish a target node from "power off" to "connection failed" i.e no bus reset would generate under "power off" connection ? Thanks, Jeff |
From: Sebastien R. <Seb...@sy...> - 2000-04-12 11:35:50
|
>>>>> "Bart" == Bart Nabbe <ba...@cs...> writes: Bart> Unfortunately that version did not resolve the problem, tried with Bart> different number of nodes on the bus while initializing. Same result as Bart> ever 0 nodes and it stays in reset. Bart> I attached the /proc/ohci and kernel messages for this version. Is there Bart> some code to tweak in the reset phase that might shine some light into Bart> this matter? From what I can see, the problem is that you are not receiving the self-id packets... I don't see anything obviously wrong with your register setting, except for the fact that your node id is 1 with the valid bit set (which should be zero if no other nodes are detected on the bus). I have noticed that my ohci card doesn't receive the self-id packets the first time it is initialized after rebooting the computer... have you tried to load/unload the ieee1394 modules a couple of times ? -- Sebastien Rougeaux RSISE, The Australian National University |
From: Jeff M. <Jef...@ef...> - 2000-04-12 00:08:27
|
For OHCI driver, whenever the target node is power off, bus reset would be generated. For IEEE1394, there are some power management i.e. the node is self-powered and this has been implemented in my target node. However, the bus reset signal is still generated causing my linux box cannot communicate with the target node anymore. My question is how to distinguish a target node from "power off" to "connection failed" i.e no bus reset would generate under "power off" connection ? Thanks, Jeff |
From: Bryan S. <ar...@ve...> - 2000-04-11 19:55:08
|
On Tue, 11 Apr 2000, Timothy M. Shead wrote: > I'm curious what set of parameters you used with dvgrab ... I have a PCILynx > card, 2.3.99-pre3 kernel, and a Canon XL-1, and I haven't been able to grab > anything - I'm able to successfully control the camera through my SDPAVC > library, but not so much as a "peep" of isochronous data. I just ran it as `./dvgrab --frames 300 test`. I'll have to check out your SDPAVC library, just saw the link on the sourceforge page. :) > Also, another good solution for viewing AVIs under Windoze without a reboot > is VMWare ... it's proprietary software ($99 for non-commercial use), but > works like a charm - it allows you to run any flavor of DOS/Windows in an X > window, using a virtual filesystem (no more partitioning!). vmware is a pretty cool program, but I only rebooted once into windows to see if the avi played at all and then started looking for a linux solution. I'll try and get some screenshots of what mediaplayer is doing under windows tonight, but it does look like the data is there just jumbled up a little. (I can make out people's faces at least) > Us XL-1 guys gotta stick together ... :) No doubt! :) One thing that also might be helpful is I'm running the latest unstable version of Debian. Here's some version numbers for you: gcc --version: 2.95.2 ld --version: 2.9.5 c++ --version: 2.95.2 cpp --version: 2.95.2 Bryan |
From: Timothy M. S. <ts...@k-...> - 2000-04-11 19:26:37
|
Bryan: I'm curious what set of parameters you used with dvgrab ... I have a PCILynx card, 2.3.99-pre3 kernel, and a Canon XL-1, and I haven't been able to grab anything - I'm able to successfully control the camera through my SDPAVC library, but not so much as a "peep" of isochronous data. Also, another good solution for viewing AVIs under Windoze without a reboot is VMWare ... it's proprietary software ($99 for non-commercial use), but works like a charm - it allows you to run any flavor of DOS/Windows in an X window, using a virtual filesystem (no more partitioning!). Us XL-1 guys gotta stick together ... :) Tim Last night my friend and I went out and bought a $79 Digital Research firewire card at Best Buy. This card runs off the TI chipset which is OHCI compliant. I recompiled my kernel and got everything working, but I don`t know what to use to view/convert the outported avi file from dvgrab. I tried using gvplay, but it crashes complaining about audio not being supported yet. xanim doesn`t work either. Maybe someone knows of a converter program I can use to convert the uncompressed avi to a mpeg2 or regular mpeg? Here`s the specs of my setup: Digital Research IEEE-1394 4-port card (3ext, 1int) Canon XL1 Digital Camcorder AMD K6-3 450 128MB RAM 1GB free on this computer, but will be using a 36GB drive NFS mounted later for storage. Sound Blaster Live! Value with pretty new open source drivers. The IEEE-1394 will eventually go in a nicer computer with an 18GB SCSI-3 drive and probably dual-processors. I want to be able to use Broadcast 2000 to generate movies with eventually... If there`s any other information that might be needed such as the actual chipset model number on the IEEE-1394 card please ask. Right now I`m either thinking that the avi file was created correctly and I haven`t found any programs that can read it yet, or the XL1 isn`t fully supported yet and I can try and help you guys out with adding support. Bryan _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: fullman <fu...@mi...> - 2000-04-11 19:11:17
|
Hi~ It's a simple reason. because, there is no public DV decoder in linux. ----- Original Message ----- 보낸 사람: "Bryan Stillwell" <ar...@ve...> 받는 사람: <lin...@li...> 보낸 날짜: 2000년 4월 12일 수요일 제목: dvgrab > Last night my friend and I went out and bought a $79 Digital Research > firewire card at Best Buy. This card runs off the TI chipset which is > OHCI compliant. I recompiled my kernel and got everything working, but I > don't know what to use to view/convert the outported avi file from dvgrab. > I tried using gvplay, but it crashes complaining about audio not being > supported yet. xanim doesn't work either. Maybe someone knows of a > converter program I can use to convert the uncompressed avi to a mpeg2 or > regular mpeg? > > Here's the specs of my setup: > > Digital Research IEEE-1394 4-port card (3ext, 1int) > Canon XL1 Digital Camcorder > AMD K6-3 450 > 128MB RAM > 1GB free on this computer, but will be using a 36GB drive NFS mounted > later for storage. > Sound Blaster Live! Value with pretty new open source drivers. > > The IEEE-1394 will eventually go in a nicer computer with an 18GB SCSI-3 > drive and probably dual-processors. I want to be able to use Broadcast > 2000 to generate movies with eventually... > > If there's any other information that might be needed such as the actual > chipset model number on the IEEE-1394 card please ask. Right now I'm > either thinking that the avi file was created correctly and I haven't > found any programs that can read it yet, or the XL1 isn't fully supported > yet and I can try and help you guys out with adding support. > > Bryan > > > _______________________________________________ > mailing list lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linux1394-devel > |
From: A. M. <am...@pe...> - 2000-04-11 18:59:31
|
Bryan Stillwell wrote: ... > I tried using gvplay, but it crashes complaining about audio not being > supported yet. xanim doesn't work either. Maybe someone knows of a > converter program I can use to convert the uncompressed avi to a mpeg2 or > regular mpeg? Hey, if you got an avi file at all you're doing better than I did last night (but I need to upgrade my kernel from 2.2.13 to 2.2.14. It recognizes the card but can't get a handle on anything attached). Since you got further than I did I'm assuming the problems aren't with the 1394 stuff. I did find that xanim (didn't try gvplay) is picky about its AVI files, it wouldn't play the AVI capture I did off of xawtv either. (Didn't like 24 bits/pixel format.) It might be simplest to try transferring the file to a Windows system (or reboot if you have a dual-boot machine) and try it in Media Player. (Just for testing, of course, you wouldn't want to do that all the time.) -- Alastair |
From: Bryan S. <ar...@ve...> - 2000-04-11 17:03:17
|
Last night my friend and I went out and bought a $79 Digital Research firewire card at Best Buy. This card runs off the TI chipset which is OHCI compliant. I recompiled my kernel and got everything working, but I don't know what to use to view/convert the outported avi file from dvgrab. I tried using gvplay, but it crashes complaining about audio not being supported yet. xanim doesn't work either. Maybe someone knows of a converter program I can use to convert the uncompressed avi to a mpeg2 or regular mpeg? Here's the specs of my setup: Digital Research IEEE-1394 4-port card (3ext, 1int) Canon XL1 Digital Camcorder AMD K6-3 450 128MB RAM 1GB free on this computer, but will be using a 36GB drive NFS mounted later for storage. Sound Blaster Live! Value with pretty new open source drivers. The IEEE-1394 will eventually go in a nicer computer with an 18GB SCSI-3 drive and probably dual-processors. I want to be able to use Broadcast 2000 to generate movies with eventually... If there's any other information that might be needed such as the actual chipset model number on the IEEE-1394 card please ask. Right now I'm either thinking that the avi file was created correctly and I haven't found any programs that can read it yet, or the XL1 isn't fully supported yet and I can try and help you guys out with adding support. Bryan |
From: Manfred W. <e95...@st...> - 2000-04-11 13:42:08
|
I have the following problem concerning the reception of iso packets: I have to ways to find out the length of an iso packet in the iso handler: the length argument and the iso header which is positioned in the first quadlet of the buffer. Normally length == (data[0] >> 16) + 4. This is because the length of the buffer contains the quadlet which represents the iso header. Usually this condition is fulfilled. But sometimes I received packets where the length argument sayed that the packet length was 332 wherea the iso header (ie. data[0] >> 16) sayed 584. Since I know the size of my iso packets, I can tell you that (of course) the iso header is right and the length argument reports an incorrect length. So two questions emerge: 1) Why does the handler report an incorrect packet length? 2) Is the buffer (*data) filled correctly or are only the first 332 bytes valid and the rest (256 Bytes) lost? Manfred Weihs PS: I use a Unibrain Fireboard with the pcilynx driver, and reception of iso packets works quite find, but as mentioned above: sometimes data is lost. PPS: Just when I wanted to send this mail I observed another version of that problem: Iso header said 776 whhereas the length argument said 732. So now 48 Bytes are missing. Again the length reported by the header is correct, since valid packet sizes in my application are (without iso header) 192*k+8 (k is an integer and 8 is the length of the CIP header). But the most frequent version of that problem is 332 vs. 584. |
From: Andreas B. <and...@mu...> - 2000-04-11 00:10:10
|
On Wed, Apr 05, 2000 at 06:40:59PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > [concerning the buffers which are handed over to the iso- or fcp-handlers] > > The buffer is only overwritten on a raw1394_loop_iterate() call which > > then calls the handlers. After a handler ends, the corresponding data > > is invalid (the handler must process the data immediately or save it > > somewhere else if it really has to store plain data). Therefore there > > won't be problems with correct usage. > > Is the data really invalid, when the handler ends, or does it stay valid > until the next call of raw1394_loop_iterate()? Currently it stays valid for that time. > Imagine an application > which processes data that arrives on an isochannel; and everytime, when > its buffer is empty, it does (one or more) raw1394_loop_iterate() until > the iso_handler is executed. Does the handler really have to copy the > data to a separate buffer, or would it be sufficient to store the > address of the (internal) buffer in a (global) variable? The premise is > - of course - that raw1394_loop_iterates (on that particular raw-handle) > is only done, when we need a new iso-packet. Hm, probably. But my original idea was that the handler directly processes the data (and therefore creates processed data at another place anyway). > > In the future the address given to an iso or FCP handler might not > > even exist anymore since I intend to implement kernel-to-user memory > > mapping at some point in the future and the page containing the data > > could be unmapped immediately after use. > > I think, that has no effet to my question above, isn't it? Instead of overwriting the buffer the buffer pointed to will be either replaced with another page or unmapped entirely (giving a segfault if it is accessed). This unmapping or replacing wouldn't happen until the next iterate call, probably, saving a syscall after the handler finished. OTOH the page containing the data could be physically locked down for a long time then if the app doesn't do iterate calls often enough. I'm not yet decided, but I think it could make some sense to have data valid until the next iterate call. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |