Thread: we need the iso write function (was RE: dvgrab)
Brought to you by:
aeb,
bencollins
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: Andreas B. <and...@mu...> - 2000-04-14 01:40:46
|
On Thu, Apr 13, 2000 at 06:58:48PM +0200, Arne Schirmacher wrote: > 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 ... :-) A clean implementation of that needs the subsystem to do transactions without being asked to by a user process. That is also needed for collecting GUIDs from connected nodes, so it's high on my todo list. And I hopefully will finally get this done in the very near future. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-14 16:51:37
|
Arne Schirmacher wrote: > Dear 1394 device driver programmers: please make a iso write function. The > Linux world needs it ... :-) Well, I think there are many things, the linux world needs. Maybe it would be nice to create a kind of wish list. But I think, before such substantial additions are made (which of course should come soon or later), it should have a higher priority to fix the bugs in the existing fundamental operations. For example the lock operation does not work, because we do not get the response value. Therefore I cannot do a compare-swap-operation, because the return value is essential for that kind of operation. And I need this :-( Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-15 00:45:07
|
On Fri, Apr 14, 2000 at 06:43:30PM +0200, Manfred Weihs wrote: > Well, I think there are many things, the linux world needs. Maybe it > would be nice to create a kind of wish list. Would be a good idea (together with information on who does/intends to work on specific items). > But I think, before such substantial additions are made (which of course > should come soon or later), it should have a higher priority to fix the > bugs in the existing fundamental operations. For example the lock > operation does not work, because we do not get the response value. > Therefore I cannot do a compare-swap-operation, because the return value > is essential for that kind of operation. And I need this :-( Oh, you mentioned that some time ago already. Sorry, I completely forgot that. I fixed that now, the necessary changes in libraw1394 were quite small, and the lock functions now take an additional quadlet_t* pointing to a location where the response is to be stored. I also fixed the kernel side raw1394 lock, where for remote transactions a pointer was not set (could get you a nasty oops). You can get both from CVS, apart from successful compilation I haven't tested it. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-15 15:54:20
|
Andreas Bombe wrote: > You can get both from CVS, apart from successful compilation I haven't > tested it. But ieee1394 does not compile (CVS-version from Apr 15 th, 17:40 CEST). make bzImage says: ... drivers/ieee1394/ieee1394.a(pcilynx.o): In function `mem_dmaread': pcilynx.o(.text+0x10cf): undefined reference to `set_current_state' make: *** [vmlinux] Error 1 Manfred Weihs |
From: Andreas B. <and...@mu...> - 2000-04-15 19:13:45
|
On Sat, Apr 15, 2000 at 05:46:34PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > You can get both from CVS, apart from successful compilation I haven't > > tested it. > > But ieee1394 does not compile (CVS-version from Apr 15 th, 17:40 CEST). > make bzImage says: > ... > drivers/ieee1394/ieee1394.a(pcilynx.o): In function `mem_dmaread': > pcilynx.o(.text+0x10cf): undefined reference to `set_current_state' > make: *** [vmlinux] Error 1 set_current_state didn't exist in Linux 2.2. I added a compatibility macro (in CVS), it should work now. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |