Monday June 13, 2005 | Artem's Weblog |
|
My name is Artem Kachitchkine2, I'm an engineer in the Operating Platforms Group. Since I joined Sun a few years ago (virtually straight out of college) I've been working on a number of I/O related projects. I started by fixing bugs in Solaris serial and parallel port drivers, then participated in the bringup of the Sun Blade workstation series. After that, I moved into the USB land and later took ownership of the 1394 (FireWire) framework in Solaris, during which I wrote av1394(7D) and scsa1394(7D) drivers and introduced framework extensions to support new drivers. I was also part of the team that ported Solaris Fibre Channel stack aka Leadville to x64 platforms. Lately I've been busy working on various aspects of mass storage and removable media management in Solaris.
Trackback URL: http://blogs.sun.com/artem/entry/at_c0
Post a Comment: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Posted by weehing on June 14, 2005 at 05:18 AM PDT #
Posted by artem on June 15, 2005 at 04:45 PM PDT #
Posted by Hanabal on August 11, 2005 at 06:56 PM PDT #
av1394 provides two transfer methods: generic read(2)/write(2) and using special ioctls (see iec61883.h for details, but keep in mind that this API is not stable yet). In the read(2) mode av1394 currently auto-senses DV NTSC and PAL formats, so capturing raw DV can be as simple as:
where 'bs' is any sufficiently large block size.
Unfortunately, there is a bug that breaks av1394 isochronous on x86, so right now av1394 is only usable on sparc (if 'usable' is the right word in absense of NLE apps for Solaris). Also, I haven't seen the HDV standard, so I can't say whether the driver will work with this format.
Posted by artem on August 12, 2005 at 02:34 PM PDT #
Posted by Hanabal Khaing on August 15, 2005 at 08:02 AM PDT #
Raw data returned by av1394 has the original packets sandwiched between CIP header and padding. That's how packets travel on the 1394 bus. Most codecs won't recognize CIP packets. The exact method of converting raw data into a video stream depends on the format, but it basically comes down to stripping headers and padding.
For instance, for DV, you would read the raw file in 512-byte blocks and only take 480 bytes at offset 8. You would also need to ignore packets that have first 6 bytes zeroed - they don't carry any information, they are only used to adjust transfer rate. Now if you save this stream of 480-byte packets into a file, you'll get something that should be understood by NLE's, at least I was able to play it in Quicktime (files in this format usually have .dv extension).
For HDV, the coversion method is different, as far as I can tell.
Posted by artem on August 16, 2005 at 08:38 AM PDT #
I want to write a driver and/or library to access my MOTU 828 mkII (FireWire-audio) device. Any tips on where to start is appreciated.
Posted by David on July 24, 2008 at 12:47 PM PDT #
I would start with the existing av1394 driver. It already supports basic IEC 61883, and specifically the DV framing/timestamping. I would expand it to support MPEG TS framing/timestamping, which essentially what FireWire audio streaming is, IIRC.
Posted by artem on July 24, 2008 at 01:27 PM PDT #