[gst-devel] 1394(firewire) source added

[Erik Walthinsen]

On Mon, 23 Apr 2001, Dan Dennedy wrote:

> Please consider adding the letters dv to this name somewhere because there
> is another 1394 camera format that is extremely popular called Digital
> Camera that sends uncompressed video. If you want to toy around with one,
> Orange Micro and ADS Technologies make some for ~110. Perhaps call them
> dv1394src and dc1394src.
Good point, I'll do that.  And I ordered an Orange Micro iBOT on Saturday,
it should arrive home Wednesday, except I'll be in Boise all this week <g>
I'll get someone to plug it in and I can work on it from there ;-)

> When my new drivers are done, I'll port your plugins to use them. They
> provide better performance through DMA transfers into userspace memory. This
> is not possible using the libraw1394 interface you are using. We use this
> approach alot with the 1394 uncompressed Digital Cameras, and it helps
> performance quite a bit esp. in conjunction with XvShm.
Good.  The issue I ran into is a rather hard one, and hopefully it can be
avoided in video1394:

The call stack is something like:

	[dv]1394src_chain
		raw1394_loop_iterate
			[dv]1394src_iso_receive(size,data)
				buf = new_buffer(size,data);
				gst_pad_push(buf);
					(cothread switch to other element)
					(cothread switch back from element
				<
			<
		<
	<

The problem is that the buffer constructed in [dv]1394src_iso_receive is
built around the pointer on the iso_receive arg list.  This pointer is
only valid until the end of the handler, afaict.  This means that if the
peer element doesn't finish with that buffer right then and there (i.e.
wants to hold onto it for some short period of time in order to, say, go
through N of them in one go), the pointer becomes invalid.

Basically, I need to make sure that I can have arbitrary amounts of 1394
data stored in RAM, as placed there directly by the subsystem, rather than
forcing me to copy it myself into 'non-volatile RAM'.  If I understand the
concept correctly, and it's implemented correctly, this is exactly what
user-space DMA is all about.

That said, do you see any possibility for raw1394 have this capability any
time soon?  Since raw1394 is the lowest level access you can get from
userspace, and there won't be random protocol driver modules in the kernel
for a long time, it makes sense for raw1394 to have the same performance
for dc1394 and sbp-2 (yes, I know that's done in kernel...) and other
things like mLAN as a custom coded module.  I can't see any fundamental
reason in the raw1394 and driver code why that can't be done, but I didn't
spend long looking.

TIA,
   Omega

      Erik Walthinsen <omega at temple-baptist.com> - System Administrator
        __
       /  \                GStreamer - The only way to stream!
      |    | M E G A        ***** http://gstreamer.net/ *****
      _\  /_