linux1394-devel Mailing List for IEEE 1394 for Linux (Page 528)
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-01 11:43:22
|
Arne, I'll build you the files when I get to work. 1) Shall I e-mail them to you or ftp them somewhere? Give me an address and password if I need it. 2) The samples directory should designate PAL vs. NTSC. Maybe other identifiers also when we learn more. 3) QuickTime does exist for Windows platforms also, although I think that testing for Mac compatibility is a great idea. They certainly are the standard in this stuff if you believe their TV ads. 4) Longer clips have their place also, but for now I agree, basic compatibility should be fine with short ones. Mark -----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 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-01 09:04:52
|
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 |
From: Mark W. K. <mar...@ho...> - 2000-06-01 04:09:37
|
Did some more compiling, clipping & testing... Good news - Win 98 SE works great... Bad news - many don't work yet, at least for me... using dvgrab_0.81 to get data Windows Media Player - NT & 98 Second Edition Real Player - Linux Ver_7, Win Ver_8 Quicktime - NT Ver_4 Results: Format ------------------------------------ dv1 dv2 ------------------------------------ xdvplay plays fails (1/4) ------------------------------------ WMP_NT40 fails plays (1/2) ------------------------------------ WMP_98SE plays plays ------------------------------------ RP_7_Linux fails fails ------------------------------------ RP_8_98SE fails fails ------------------------------------ RP_7_NT40 fails fails ------------------------------------ QT_4_NT40 fails plays (1/2) ------------------------------------ -----Original Message----- From: lin...@li... [mailto:lin...@li...]On Behalf Of Arne Schirmacher Sent: Wednesday, May 31, 2000 12:27 PM To: 'Mark Knecht'; 'lin...@li...' Subject: RE: dvgrab data on Windows machine Hi Mark, I have changed the Type-1 code a little. Please try it. Before the fix the Type-1 AVIs would play on my Windows-NT box, but not on a Windows-98 box. I did not try both systems. With this fix I can play all two types on both systems. http://www.schirmacher.de/arne/dvgrab/dvgrab_0.81.tar.gz xdvgrab is in fact too slow, but this is actually a libdv issue. Sooner or later the libdv developers will provide a faster version, but I am quite happy that we have some working code. And yes, it requires a MMX CPU. I could not get RealPlayer working at all with my AVIs. They don't even play with a black screen. There is probably a timing issue left in the Type-2 code. I noticed with my PAL AVIs that the speed is basically correct but the video stops at about 80% with the slider still moving on. But that's probably trivial. Xdvplay is just a very simple front end to the libdv software. Maybe I add Type-2 support but that's it. I already have made a patched version of xanim, this is probably the way to go. One program supporting all kinds of video formats. The patch is still too unstable to release it (actually it displays just one frame before core dumping). Thanks for your time that you are putting in Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-05-31 22:21:42
|
Arne, Hi. Downloaded 0.81, but unfortunately no change at all on my systems. On Linux they dv1 runs at 1/4 speed, dv2 fails (expected). On Windows NT dv1 fails both RP and WMP, dv2 play on WMP at 1/2 speed, but does not play on RP. I am NT 4.0, SP-5. BTW - I filmed the wall clock in the lab, watching the second hand move for 10 seconds, so the file really is 10 seconds of data. And the file size is about 36MB. Can you check one thing for me? When I move a dv1 format file to my NT machine, if I right-click it, go to properties, and then the details tab, I see Media Length of 10 seconds, but the audio and video formats are blank. dv2 files have information there. Would you double check that you are or are not seeing the same thing? I will try this tonight at home on both NT 4.0 and 98 SE and let you know what I see. Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Wednesday, May 31, 2000 12:27 PM To: 'Mark Knecht'; 'lin...@li...' Subject: RE: dvgrab data on Windows machine Hi Mark, I have changed the Type-1 code a little. Please try it. Before the fix the Type-1 AVIs would play on my Windows-NT box, but not on a Windows-98 box. I did not try both systems. With this fix I can play all two types on both systems. http://www.schirmacher.de/arne/dvgrab/dvgrab_0.81.tar.gz xdvgrab is in fact too slow, but this is actually a libdv issue. Sooner or later the libdv developers will provide a faster version, but I am quite happy that we have some working code. And yes, it requires a MMX CPU. I could not get RealPlayer working at all with my AVIs. They don't even play with a black screen. There is probably a timing issue left in the Type-2 code. I noticed with my PAL AVIs that the speed is basically correct but the video stops at about 80% with the slider still moving on. But that's probably trivial. Xdvplay is just a very simple front end to the libdv software. Maybe I add Type-2 support but that's it. I already have made a patched version of xanim, this is probably the way to go. One program supporting all kinds of video formats. The patch is still too unstable to release it (actually it displays just one frame before core dumping). Thanks for your time that you are putting in Arne |
From: Andreas B. <and...@mu...> - 2000-05-31 22:19:37
|
On Wed, May 31, 2000 at 07:40:20AM +0200, Olivier LAHAYE wrote: > Hello, > > Would it be possible to use a camcorder (that has dv-in) as a backup device > by encapsulating backup datas in the video sequences in a faked DV format? > > If I understand well the camcorder behaviour, in dv-in mode, it only > store the DV datas on the tape. right? From what I know, the DV data is always sent over isochronous streams, which might lose data since they are broadcast and there is no acknowledge from the receiving end. Acceptable for video data, but certainly not for your backups. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Mark K. <mk...@co...> - 2000-05-31 20:58:47
|
Arne, In a private message from James Goodwin, we were talking about Windows platforms and testing. It made me think that maybe there is a better way to do some of this. I'm thinking that it make sense to build up a small library (small in number of files, not necessarily number of MBytes) of video clips for people to try out on various platforms for test purposes? Each clip would be maybe 30-60MB. We would want to have some standard clips that have been run under Windows to test under Linux, and some that we generate under Linux that folks could test under Windows. My Windows box here at work is an NT 4.0, SP 5, 300MHz Pentium II Compaq. I don't think this platform necessarily makes much difference if it works or not. There is a lot of software that doesn't run well on NT. It's just one datapoint. James was pointing out, and I agree, that Win 2K or Win 98SE would be far more typical of the best drivers and codecs for this sort of data. Unfortunately I don't have one of those platforms here at work. One the other hand, I do have high-speed connections at both work and home, and personally wouldn't mind downloading specific clips to do some short tests. I'll bet there are others out there who could do the same thing. If we could build up a small group of folks who could cover each of the individual platforms, and a library of current video clips, then we could probably test this stuff better, faster and much more comprehensively. Additionally it would give us all access to both NTSC and PAL data which isn't easy for all of us to get. I'm talking to my IT folks to see if we could donate a GB or so of disk space for something like this, but if you or someone else has space available, we could do it there. I have suspicions that something like this must exist out on the web somewhere, but buried under the avalanche of XXX stuff I ran into today I wouldn't know how to find it. Comments? Mark |
From: Arne S. <ar...@sc...> - 2000-05-31 18:33:29
|
Hi Mark, I have changed the Type-1 code a little. Please try it. Before the fix the Type-1 AVIs would play on my Windows-NT box, but not on a Windows-98 box. I did not try both systems. With this fix I can play all two types on both systems. http://www.schirmacher.de/arne/dvgrab/dvgrab_0.81.tar.gz xdvgrab is in fact too slow, but this is actually a libdv issue. Sooner or later the libdv developers will provide a faster version, but I am quite happy that we have some working code. And yes, it requires a MMX CPU. I could not get RealPlayer working at all with my AVIs. They don't even play with a black screen. There is probably a timing issue left in the Type-2 code. I noticed with my PAL AVIs that the speed is basically correct but the video stops at about 80% with the slider still moving on. But that's probably trivial. Xdvplay is just a very simple front end to the libdv software. Maybe I add Type-2 support but that's it. I already have made a patched version of xanim, this is probably the way to go. One program supporting all kinds of video formats. The patch is still too unstable to release it (actually it displays just one frame before core dumping). Thanks for your time that you are putting in Arne |
From: Mark K. <mk...@co...> - 2000-05-31 16:27:25
|
Arne, I have a mixture of machines here, so this is all getting confusing. Possibly I should limit my reporting to only one or two machines until we get things under control... My stable of 1394 enabled machines: Work Linux boxes: a) 433 Celeron b) 200MHz Pentium c) 333 Pentium II Home Linux Box: a) 750MHz Athlon b) 500MHz Pentium III (no 1394 card - on network) Work NT Box: a) 300MHz Pentium II with Adaptec Hot Connect 8940 Your table below is essentially correct, but the two entries under xdvplay that say 'works' should also say 'plays at about 1/4 speed'. Watching the clips it looks like xdvplay is not dropping too many frames - it's just going VERY slowly. My 10 second dv1 format dvgrab clips played using xdvplay take about: 45 seconds on the Celeron 433 55 seconds on the Pentium II 333 doesn't play on the Pentium 200 (no MMX?) My 10 second dv2 format clips, when played with WMP take about 14-15 seconds. I tried them at 50%, 100% & 200% screens. All three screen sizes took the same amount of time. It is very clear that WMP is dropping most of the frames in these clips. On Real Player 7.0 Beta, they 'play', take about 14-15 seconds, but the screen is black. (No picture) I tried another simple test to look at WMP. I downloaded an mpeg clip from the Broadcast 2000 site (titanic.mpeg) and played this clip. It reports that it is 38 seconds long, and it takes 38 seconds to play in WMP. Granted, different compressors/codecs, but it worked as expected with respect to time. I wanted to download some AVI clips from the web, but a quick search yields only XXX sites and I don't want to get fired!!! I guess I'll have to deal with that problem on an after hours basis!! ;-) I am unclear what I am to expect from xdvplay. Is xdvplay expected to drop frames automatically to stay in time? (Probably necessary to sync with audio...) Or does it just cycle through the database and display the info? (45 seconds/55 seconds) almost == (333 MHz / 433 MHz) -- Coincidence? I am personally hoping that the problem on the Windows box may be small. I am particularly curious about the differences between the two file formats when I look at the file properties. The dv2 format, which plays, also provides information about the encoding of video and audio. The dv1 format, which does not play, does not provide any information about the encoding, which is consistent with the type of failure in WMP. I am hoping that the data is good, but something simply got messed up in the packaging of the file? I'm happy to provide more info as you need it. Mark -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Wednesday, May 31, 2000 9:00 AM To: 'lin...@li...' Cc: mk...@co...; 'Mark W. Knecht' Subject: RE: dvgrab data on Windows machine Hi Mark, thanks for testing the dvgrab software, I can't do any NTSC related work here. xdvplay currently does not recognize the dv2 format. I'll fix that later. The weird thing is that your windows box doesn't display AVI files created with dvgrab 0.7. I thought this version is working and stable. I would guess that you do not have DV codecs on your windows system, but then the dv2 format should not play either. Let me recollect the information from your emails, could you please verify this: | xdvplay | Windows media player | RealPlayer ---------------------------------------------------------------------------- dvgrab 0.7 (dvgrab_latest)| works | fails | fails dvgrab 0.8 --format dv1 | works | fails | fails dvgrab 0.8 --format dv2 | core dump | plays at half speed | fails Sigh. Let me get back to the code... Arne |
From: Arne S. <ar...@sc...> - 2000-05-31 15:16:56
|
Hi Mark, thanks for testing the dvgrab software, I can't do any NTSC related work here. xdvplay currently does not recognize the dv2 format. I'll fix that later. The weird thing is that your windows box doesn't display AVI files created with dvgrab 0.7. I thought this version is working and stable. I would guess that you do not have DV codecs on your windows system, but then the dv2 format should not play either. Let me recollect the information from your emails, could you please verify this: | xdvplay | Windows media player | RealPlayer ---------------------------------------------------------------------------- dvgrab 0.7 (dvgrab_latest)| works | fails | fails dvgrab 0.8 --format dv1 | works | fails | fails dvgrab 0.8 --format dv2 | core dump | plays at half speed | fails Sigh. Let me get back to the code... Arne |
From: <fra...@ya...> - 2000-05-31 14:13:10
|
Due to recent demands, I have included more english comments in my ethernet driver source code : http://www.chez.com/kayle/IEEE_1394/ether_1394_0.1.1.tgz Or http://www.chez.com/kayle/ieee_1394.htm --------- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Olivier L. <la...@cy...> - 2000-05-31 05:42:52
|
Hello, Would it be possible to use a camcorder (that has dv-in) as a backup = device by encapsulating backup datas in the video sequences in a faked DV = format? If I understand well the camcorder behaviour, in dv-in mode, it only = store the DV datas on the tape. right? That would be cool to do: tar cvf /dev/1394tape / 2Go in less than 10minurtes :-) |
From: Mark K. <mk...@co...> - 2000-05-30 22:02:59
|
Hi Arne, Downloaded and tried dvgrab-0.8 with NTSC version of Canon ZR-10 camcorder. I used: ./dvgrab --ntsc --timestamp --format dv1 FILE_NAME ./dvgrab --ntsc --timestamp --format dv2 FILE_NAME I then tried playing the files on both my Linux boxes and my Windows box. dv1 sort of works on Linux dv2 sort of works on Windows Mark Results: 1) dv1 output - play on xdvplay @ about 1/4 speed - 10 seconds of data took about 45 seconds to play 2) dv2 output - play on xdvplay - core dumped FTP'ed files to Windows NT box 3) dv1 output a) Play with Windows Media Player i) Fails to play ii) Check file properties Says 10.09 sec No audio and video formats displayed b) Play with Real Player i) Fails to play 4) dv2 output a) Play with Windows Media Player i) Plays About 1/2 speed (takes 20 seconds) ii) Check file properties Says 10.892 Sec Audio - PCM, 44.100KHz, 16-bit, Mono Video - 720x480, 24-bits, 300frames, 30.303 FPS, 3647KB/Sec, DVSoft b) i) Doesn't play correctly Screen is black Time appears to be right (10 seconds) -----Original Message----- From: Arne Schirmacher [mailto:ar...@sc...] Sent: Sunday, May 28, 2000 9:09 AM To: 'lin...@li...' Subject: nev version of dvgrab again Hi all, another version of dvgrab is out: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.8.tar.gz I have added support for both type 1 and type 2 AVI files. This means that you can now use dvgrab with the MainActor Linux video sequencer program (MainActor can currently only read type 2 AVI files). Notes: The NTSC support for dv type 2 is untested because I do not have NTSC equipment. If you can run it with a NTSC camcorder, please try it and send an email if you are successful. If it doesn't work, send an email too. There is currently no audio track available. I am working on it. A demo version of MainActor can be downloaded from http://www.mainconcept.com . It is well worth trying it. The dvgrab website pages are not yet updated, I would like you to beta test it first. Arne _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Mark K. <mk...@co...> - 2000-05-30 16:54:15
|
Hi, I've captured a few databases under Linux using ./dvgrab --ntsc --frames 300 ~/FILE_NAME and then played them under Linux using ./xdvplay ~/FILE_NAME001.avi and everything is working fine. However, when I ftp (using binary) these files to my Window box, I am unable to play them with either Real Play or Microsoft Media Player. MMP says : No combination of filters could be found to render the stream. (Error=80040218) RP just does nothing..... When I inspect the properties of the file under Windows, it says that it is 10.09 seconds worth of data, which seems correct. However, there is no information present about the Audio format or the Video format. How do I get this working under Windows? |
From: Mark K. <mk...@co...> - 2000-05-30 16:17:56
|
Having removed the *.d files from the libdv directory and rebuilt xdvplay, dvgrab & xdvplay are now working on my system. Cheers Arne!! 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. Thanks, Mark |
From: Mark K. <mk...@co...> - 2000-05-30 14:03:11
|
Hi, I attempted to run the prebuilt version of xdvplay this morning. My environment is Redhat 6.2. When I start the program I receive this error message: [root@bambi xdvplay_0.22]# ./xdvplay ./xdvplay: error in loading shared libraries: libstdc++-libc6.1-2.so.3: cannot open shared object file: No such file or directory [root@bambi xdvplay_0.22]# As best I can tell RH6.2 supplies libc6.1-1. I looked for an RPM to upgrade this but was not able to find it. I will attempt to recompile the program later today on this box to solve this problem. Should this be statically linked instead? Mark |
From: Ben C. <bco...@de...> - 2000-05-29 22:13:16
|
> 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. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: <fra...@ya...> - 2000-05-29 11:48:52
|
I have updated ether1394 drivers and now you can specify an hardware address at insmod time : insmod eth1394 hwaddr=0x12345678 Also, Virtual_VCR should now recognize unit commands. This should now working with gscanbus 0.6, but increase the size of buffer "s", near line 915 of file gscanbus.c : > char s[5000]; /* FIXME */ Both are available at : http://www.chez.com/kayle/IEEE_1394 Or http://www.chez.com/kayle/ieee_1394.htm --------- Franck Bonin ___________________________________________________________ Do You Yahoo!? Achetez, vendez! À votre prix! Sur http://encheres.yahoo.fr |
From: Arne S. <ar...@sc...> - 2000-05-29 06:03:19
|
Please try the compiled version of xdvplay which is in the tar file. This should work in all cases. To properly recompile the libdv, delete all *.d files. The Makefile will recreate them (I should not have included them in the first place, but libdv is not yet in library form despite its name, so I need to resort to this unprofessional approach...) Last time I checked (about a week ago), the latest libdv did not work with dvgrab. If this is still the case, use the version which is in the tar file. Please try playing the AVI file with the Microsoft Media Player. If it does not work, you do not have a codec for the DV AVI data format on your Windows box. The codec is usually on the CD that came with your card, so you need to install that first. You did use binary format when ftp'ing the AVI file to the Windows box? Arne -----Original Message----- From: Mark W. Knecht [SMTP:mar...@ho...] Sent: Sunday, May 28, 2000 11:39 PM To: Linux1394-Developers List Subject: Problems building xdvplay Hi, I set up 1394 on my home PC this weekend: 1) Installed ADS Pyro board 2) Installed 2.2.15 with 1394 support (CVS versions) - It sees the board. 3) Got gscanbus-0.6 working - It sees the PC and Canon ZR-10 Camera (Although clicking on camera does NOT produce the pop-up window) 4) Installed dvgrab_latest - It runs and produces an AVI file. (A few X's along the way. I'd better give it a better place to store the data.) 5) Attempted to install xdvplay. So far dvgrab seems to be recording an avi file, which I have saved on both my Linux box and ftp'ed to my Windows box. However, at this point I am running into some problems: 1) I wanted to install xdvplay. Instructions say to go to the libdv directory, run fetch_libdv, and then run make. When I run make I find that all of the ***.d files have paths to files which have 'i486-suse-linux' in them. My machines are all Redhat, so I have 'i386-redhat-linux' paths on my machine. a) Did I miss some configuration step here? b) I tried quickly changing the paths in a bunch of these files but started to get more error messages, so I quit. 2) On my Windows box I tried to play the AVI file, but Real Player bombed out and said 'A General Error has Occurred'. No more information than that. I know folks have gotten farther than this, so it's probably my mistake. Anyone know how I might fix these probs? Thanks, Mark _______________________________________________ mailing list lin...@li... http://lists.sourceforge.net/mailman/listinfo/linux1394-devel |
From: Arne S. <ar...@sc...> - 2000-05-29 05:32:54
|
Hi all, another version of dvgrab is out: http://www.schirmacher.de/arne/dvgrab/dvgrab_0.8.tar.gz I have added support for both type 1 and type 2 AVI files. This means that you can now use dvgrab with the MainActor Linux video sequencer program (MainActor can currently only read type 2 AVI files). Notes: The NTSC support for dv type 2 is untested because I do not have NTSC equipment. If you can run it with a NTSC camcorder, please try it and send an email if you are successful. If it doesn't work, send an email too. There is currently no audio track available. I am working on it. A demo version of MainActor can be downloaded from http://www.mainconcept.com . It is well worth trying it. The dvgrab website pages are not yet updated, I would like you to beta test it first. Arne |
From: Ben C. <bco...@de...> - 2000-05-29 02:24:23
|
> Update libraw1394 from CVS, run autoheader and autoconf at least (if > you have the other stuff lying around already), then > "./configure --enable-32-64", make and test it. 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. Using this, you can completely remove the --enable-32-64 configure option. It makes the pointer massaging completely transparent, and should work for other 32/64 mixed env's besides sparc/sparc64. I tested this by compiling a 32bit and 64bit binary, and both worked perfectly as expected. Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: Ben C. <bco...@de...> - 2000-05-29 00:43:32
|
> Actually, I have implemented a simple but effective fix now. Kernel > side doesn't change, libraw1394 casts pointers to kernel pointer width > if neccessary. For now configure requires --enable-32-64 on the > command line, there is no automated way to recognize a splitted > environment. This is very wrong. For example, I should be able to compile a 32bit sparc binary that runs on sun4cdm (32bit kernel arch) and sun4u (64bit kernel arch) just like any other binary does. This makes the resulting binary specific to the kernel, and this I wont have that kind of portability. This might be ok on a per user basis, but when libraw1394 hits the distributions (and it will be in Debian soon I suspect), it will play hell with packaging. ia64, ppc64 an mips64 will have the same problem. The 32bit binaries should be portable, and the "hackery" should be in the kernel so it is invisible to userspace. Take modutils for example. It is only compiled as 32bit, and the resulting binary can handle 32bit and 64bit modules. Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: Mark W. K. <mar...@ho...> - 2000-05-28 21:39:24
|
Hi, I set up 1394 on my home PC this weekend: 1) Installed ADS Pyro board 2) Installed 2.2.15 with 1394 support (CVS versions) - It sees the board. 3) Got gscanbus-0.6 working - It sees the PC and Canon ZR-10 Camera (Although clicking on camera does NOT produce the pop-up window) 4) Installed dvgrab_latest - It runs and produces an AVI file. (A few X's along the way. I'd better give it a better place to store the data.) 5) Attempted to install xdvplay. So far dvgrab seems to be recording an avi file, which I have saved on both my Linux box and ftp'ed to my Windows box. However, at this point I am running into some problems: 1) I wanted to install xdvplay. Instructions say to go to the libdv directory, run fetch_libdv, and then run make. When I run make I find that all of the ***.d files have paths to files which have 'i486-suse-linux' in them. My machines are all Redhat, so I have 'i386-redhat-linux' paths on my machine. a) Did I miss some configuration step here? b) I tried quickly changing the paths in a bunch of these files but started to get more error messages, so I quit. 2) On my Windows box I tried to play the AVI file, but Real Player bombed out and said 'A General Error has Occurred'. No more information than that. I know folks have gotten farther than this, so it's probably my mistake. Anyone know how I might fix these probs? Thanks, Mark |
From: Andreas B. <and...@mu...> - 2000-05-28 21:02:23
|
On Sat, May 27, 2000 at 01:08:08AM -0400, Ben Collins wrote: > 1) Convert to using ioctl's and have the archs that have 32/64 userspace do > translations (just as sparc64 does now in arch/sparc64/kernel/ioctl32.c) > > 2) The ATM code uses this (from include/linux/atmapi.h): > > typedef struct { unsigned char _[8]; } atm_kptr_t; > > ...to abstract the pointers. I'm not sure how it's used, but Dave pointed me > in this direction (albeit, he prefered the ioctl method). Either method > will most likely require changes in the API for /dev/raw1394, libraw1394 > internals and some special code in the kernel for the 32/64 mixed archs. > > Let me know which is prefered and I can start working to code the needed > changes if wanted. I'd rather avoid ioctls and have the pointer fields in kernel pointer size. For that, an autoconf macro needs to be written which determines if we're compiling for 32/64 environments and make those fields 64 bits wide. Setting these fields cast from quadlet_t*. I don't think there is an easy way to determine 32/64, we'd probably have to distinguish by known architecture names. [time passes...] Actually, I have implemented a simple but effective fix now. Kernel side doesn't change, libraw1394 casts pointers to kernel pointer width if neccessary. For now configure requires --enable-32-64 on the command line, there is no automated way to recognize a splitted environment. Update libraw1394 from CVS, run autoheader and autoconf at least (if you have the other stuff lying around already), then "./configure --enable-32-64", make and test it. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Ben C. <bco...@de...> - 2000-05-27 05:12:30
|
Ok, I've talked to Dave Miller about this problem to some extent since he is familiar with intermixed 32/64 environments. ia64, ppc64 and mips64 promise to offer the same problems, so it's obviously important to fix this up now. Either one of two things can be done to fix the problem with the pointers in the raw1394_request struct: 1) Convert to using ioctl's and have the archs that have 32/64 userspace do translations (just as sparc64 does now in arch/sparc64/kernel/ioctl32.c) 2) The ATM code uses this (from include/linux/atmapi.h): /* * Opaque type for kernel pointers. Note that _ is never accessed. We need * the struct in order hide the array, so that we can make simple assignments * instead of being forced to use memcpy. It also improves error reporting for * code that still assumes that we're passing unsigned longs. * * Convention: NULL pointers are passed as a field of all zeroes. */ typedef struct { unsigned char _[8]; } atm_kptr_t; ...to abstract the pointers. I'm not sure how it's used, but Dave pointed me in this direction (albeit, he prefered the ioctl method). Either method will most likely require changes in the API for /dev/raw1394, libraw1394 internals and some special code in the kernel for the 32/64 mixed archs. Let me know which is prefered and I can start working to code the needed changes if wanted. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |
From: Ben C. <bco...@de...> - 2000-05-27 02:35:34
|
Hey, This patch adds devfs support for the raw1394 device. It should work in 2.2 and 2.[34], with or without devfs. Also fixes a portability issue with the return value of dev_read and dev_write. Ben -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` bco...@de... -- bco...@op... -- bco...@li... ' `---=========------=======-------------=-=-----=-===-======-------=--=---' |