AT&C0

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.
Update Oct 2007: After finishing Tamarack and starting WWAN OpenSolaris projects, I joined the networking group and now contributing to Brussels.

1AT&C0 is the Hayes modem command that means "assume data carrier is present". I often feel that way during blogging, i.e. assuming someone is listening.
2 Do not attempt to pronounce or memorize my last name, it will hurt and I don't want to be liable.

Comments:

Hi Artem, It is hard to find firewire info and articles from Sun especially for solaris 10. Can you tell us where to find such info from Sun? Thanks.

Posted by weehing on June 13, 2005 at 10:18 PM PDT #

That depends on what type of information you are looking for: user, developer, sysadmin?

Posted by artem on June 15, 2005 at 09:45 AM PDT #

Hi. I would like to know if I can use your library to caputre HDV from a sony HDV-FX1. When I plug the camera in, the driver creates a device in /dev/av/0. How do I open the device and send raw data to a file?

Posted by Hanabal on August 11, 2005 at 11:56 AM 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:

dd if=/dev/av/0/isoch of=data.raw bs=128k

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 07:34 AM PDT #

I did that and I got a raw data file. However, the file is not completely readable. I feel that I'm getting closer to a solution. I have an mpeg capture program on linux that does the same thing, but it crashes the whole system after about 300MB of capture. I'm using a Sun Ultra 80 with Quad 450MHz Sparc II CPUs and 2GB of RAM to capture from a Sony HDR-FX1 HDV camera this using the dd command. I suppose I need to find a way to edit the raw file and add some mpeg2 parameters or something. Mplayer read MPEG1 1028x1800, but it should be MPEG2 1920x1080. Maybe I can specify that manually somehow. This is the output from the mplayer command. vaden% mplayer -fps 30 data.raw MPlayer 1.0pre5-2.95.3 (C) 2000-2004 MPlayer Team CPU: Sun Sparc Reading config file /opt/csw/etc/mplayer/mplayer.conf: No such file or directoryReading config file /home/hanabal/.mplayer/config Reading /home/hanabal/.mplayer/codecs.conf: Can't open '/home/hanabal/.mplayer/codecs.conf': No such file or directory Reading /opt/csw/etc/mplayer/codecs.conf: Can't open '/opt/csw/etc/mplayer/codecs.conf': No such file or directory Using built-in default codecs.conf. font: can't open file: /home/hanabal/.mplayer/font/font.desc Font /opt/csw/share/mplayer/font/font.desc loaded successfully! (206 chars) Using usleep() timing Can't open input config file /home/hanabal/.mplayer/input.conf: No such file or directory Can't open input config file /opt/csw/etc/mplayer/input.conf: No such file or directory Falling back on default (hardcoded) input config Playing data.raw. MPEG-PS file format detected. VIDEO: MPEG1 1028x1800 (aspect 1) 0.000 fps 6666.4 kbps (833.3 kbyte/s) ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 MP3lib: init layer2&3 finished, tables done ADecoder init failed :( ADecoder init failed :( Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders Unknown/missing audio format -> no sound ADecoder init failed :( Opening audio decoder: [libmad] libmad mpeg audio decoder Cannot sync MAD frame ADecoder init failed :( ADecoder init failed :( Cannot find codec for audio format 0x50. Read DOCS/HTML/en/codecs.html! ========================================================================== vo: X11 running at 1280x1024 with depth 24 and 32 bpp (":0.0" => local display) Disabling DPMS ========================================================================== Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough VDec: vo config request - 1028 x 1800 (preferred csp: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. VDecoder init failed :( Opening video decoder: [libmpeg2] MPEG 1/2 Video decoder libmpeg2-v0.3.1 Selected video codec: [mpeg12] vfm:libmpeg2 (MPEG 1 or 2 (libmpeg2)) ========================================================================== Audio: no sound FPS forced to be 30.000 (ftime: 0.033). Starting playback... FATAL: Could not initialize video filters (-vf) or video output (-vo). Exiting... (End of file)

Posted by Hanabal Khaing on August 15, 2005 at 01: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 01: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 05:47 AM 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 06:27 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

artem

Search

Top Tags
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today