|  | /* | 
|  | * dv1394.h - DV input/output over IEEE 1394 on OHCI chips | 
|  | *   Copyright (C)2001 Daniel Maas <[email protected]> | 
|  | *     receive by Dan Dennedy <[email protected]> | 
|  | * | 
|  | * based on: | 
|  | *   video1394.h - driver for OHCI 1394 boards | 
|  | *   Copyright (C)1999,2000 Sebastien Rougeaux <[email protected]> | 
|  | *                          Peter Schlaile <[email protected]> | 
|  | * | 
|  | * This program is free software; you can redistribute it and/or modify | 
|  | * it under the terms of the GNU General Public License as published by | 
|  | * the Free Software Foundation; either version 2 of the License, or | 
|  | * (at your option) any later version. | 
|  | * | 
|  | * This program is distributed in the hope that it will be useful, | 
|  | * but WITHOUT ANY WARRANTY; without even the implied warranty of | 
|  | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the | 
|  | * GNU General Public License for more details. | 
|  | * | 
|  | * You should have received a copy of the GNU General Public License | 
|  | * along with this program; if not, write to the Free Software Foundation, | 
|  | * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | 
|  | */ | 
|  |  | 
|  | #ifndef _DV_1394_H | 
|  | #define _DV_1394_H | 
|  |  | 
|  | /* This is the public user-space interface. Try not to break it. */ | 
|  |  | 
|  | #define DV1394_API_VERSION 0x20011127 | 
|  |  | 
|  | /* ******************** | 
|  | **                ** | 
|  | **   DV1394 API   ** | 
|  | **                ** | 
|  | ******************** | 
|  |  | 
|  | There are two methods of operating the DV1394 DV output device. | 
|  |  | 
|  | 1) | 
|  |  | 
|  | The simplest is an interface based on write(): simply write | 
|  | full DV frames of data to the device, and they will be transmitted | 
|  | as quickly as possible. The FD may be set for non-blocking I/O, | 
|  | in which case you can use select() or poll() to wait for output | 
|  | buffer space. | 
|  |  | 
|  | To set the DV output parameters (e.g. whether you want NTSC or PAL | 
|  | video), use the DV1394_INIT ioctl, passing in the parameters you | 
|  | want in a struct dv1394_init. | 
|  |  | 
|  | Example 1: | 
|  | To play a raw .DV file:   cat foo.DV > /dev/dv1394 | 
|  | (cat will use write() internally) | 
|  |  | 
|  | Example 2: | 
|  | static struct dv1394_init init = { | 
|  | 0x63,        (broadcast channel) | 
|  | 4,           (four-frame ringbuffer) | 
|  | DV1394_NTSC, (send NTSC video) | 
|  | 0, 0         (default empty packet rate) | 
|  | } | 
|  |  | 
|  | ioctl(fd, DV1394_INIT, &init); | 
|  |  | 
|  | while (1) { | 
|  | read( <a raw DV file>, buf, DV1394_NTSC_FRAME_SIZE ); | 
|  | write( <the dv1394 FD>, buf, DV1394_NTSC_FRAME_SIZE ); | 
|  | } | 
|  |  | 
|  | 2) | 
|  |  | 
|  | For more control over buffering, and to avoid unnecessary copies | 
|  | of the DV data, you can use the more sophisticated the mmap() interface. | 
|  | First, call the DV1394_INIT ioctl to specify your parameters, | 
|  | including the number of frames in the ringbuffer. Then, calling mmap() | 
|  | on the dv1394 device will give you direct access to the ringbuffer | 
|  | from which the DV card reads your frame data. | 
|  |  | 
|  | The ringbuffer is simply one large, contiguous region of memory | 
|  | containing two or more frames of packed DV data. Each frame of DV data | 
|  | is 120000 bytes (NTSC) or 144000 bytes (PAL). | 
|  |  | 
|  | Fill one or more frames in the ringbuffer, then use the DV1394_SUBMIT_FRAMES | 
|  | ioctl to begin I/O. You can use either the DV1394_WAIT_FRAMES ioctl | 
|  | or select()/poll() to wait until the frames are transmitted. Next, you'll | 
|  | need to call the DV1394_GET_STATUS ioctl to determine which ringbuffer | 
|  | frames are clear (ready to be filled with new DV data). Finally, use | 
|  | DV1394_SUBMIT_FRAMES again to send the new data to the DV output. | 
|  |  | 
|  |  | 
|  | Example: here is what a four-frame ringbuffer might look like | 
|  | during DV transmission: | 
|  |  | 
|  |  | 
|  | frame 0   frame 1   frame 2   frame 3 | 
|  |  | 
|  | *--------------------------------------* | 
|  | | CLEAR   | DV data | DV data | CLEAR  | | 
|  | *--------------------------------------* | 
|  | <ACTIVE> | 
|  |  | 
|  | transmission goes in this direction --->>> | 
|  |  | 
|  |  | 
|  | The DV hardware is currently transmitting the data in frame 1. | 
|  | Once frame 1 is finished, it will automatically transmit frame 2. | 
|  | (if frame 2 finishes before frame 3 is submitted, the device | 
|  | will continue to transmit frame 2, and will increase the dropped_frames | 
|  | counter each time it repeats the transmission). | 
|  |  | 
|  |  | 
|  | If you called DV1394_GET_STATUS at this instant, you would | 
|  | receive the following values: | 
|  |  | 
|  | n_frames          = 4 | 
|  | active_frame      = 1 | 
|  | first_clear_frame = 3 | 
|  | n_clear_frames    = 2 | 
|  |  | 
|  | At this point, you should write new DV data into frame 3 and optionally | 
|  | frame 0. Then call DV1394_SUBMIT_FRAMES to inform the device that | 
|  | it may transmit the new frames. | 
|  |  | 
|  | ERROR HANDLING | 
|  |  | 
|  | An error (buffer underflow/overflow or a break in the DV stream due | 
|  | to a 1394 bus reset) can be detected by checking the dropped_frames | 
|  | field of struct dv1394_status (obtained through the | 
|  | DV1394_GET_STATUS ioctl). | 
|  |  | 
|  | The best way to recover from such an error is to re-initialize | 
|  | dv1394, either by using the DV1394_INIT ioctl call, or closing the | 
|  | file descriptor and opening it again. (note that you must unmap all | 
|  | ringbuffer mappings when closing the file descriptor, or else | 
|  | dv1394 will still be considered 'in use'). | 
|  |  | 
|  | MAIN LOOP | 
|  |  | 
|  | For maximum efficiency and robustness against bus errors, you are | 
|  | advised to model the main loop of your application after the | 
|  | following pseudo-code example: | 
|  |  | 
|  | (checks of system call return values omitted for brevity; always | 
|  | check return values in your code!) | 
|  |  | 
|  | while ( frames left ) { | 
|  |  | 
|  | struct pollfd *pfd = ...; | 
|  |  | 
|  | pfd->fd = dv1394_fd; | 
|  | pfd->revents = 0; | 
|  | pfd->events = POLLOUT | POLLIN; (OUT for transmit, IN for receive) | 
|  |  | 
|  | (add other sources of I/O here) | 
|  |  | 
|  | poll(pfd, 1, -1); (or select(); add a timeout if you want) | 
|  |  | 
|  | if (pfd->revents) { | 
|  | struct dv1394_status status; | 
|  |  | 
|  | ioctl(dv1394_fd, DV1394_GET_STATUS, &status); | 
|  |  | 
|  | if (status.dropped_frames > 0) { | 
|  | reset_dv1394(); | 
|  | } else { | 
|  | for (int i = 0; i < status.n_clear_frames; i++) { | 
|  | copy_DV_frame(); | 
|  | } | 
|  | } | 
|  | } | 
|  | } | 
|  |  | 
|  | where copy_DV_frame() reads or writes on the dv1394 file descriptor | 
|  | (read/write mode) or copies data to/from the mmap ringbuffer and | 
|  | then calls ioctl(DV1394_SUBMIT_FRAMES) to notify dv1394 that new | 
|  | frames are availble (mmap mode). | 
|  |  | 
|  | reset_dv1394() is called in the event of a buffer | 
|  | underflow/overflow or a halt in the DV stream (e.g. due to a 1394 | 
|  | bus reset). To guarantee recovery from the error, this function | 
|  | should close the dv1394 file descriptor (and munmap() all | 
|  | ringbuffer mappings, if you are using them), then re-open the | 
|  | dv1394 device (and re-map the ringbuffer). | 
|  |  | 
|  | */ | 
|  |  | 
|  |  | 
|  | /* maximum number of frames in the ringbuffer */ | 
|  | #define DV1394_MAX_FRAMES 32 | 
|  |  | 
|  | /* number of *full* isochronous packets per DV frame */ | 
|  | #define DV1394_NTSC_PACKETS_PER_FRAME 250 | 
|  | #define DV1394_PAL_PACKETS_PER_FRAME  300 | 
|  |  | 
|  | /* size of one frame's worth of DV data, in bytes */ | 
|  | #define DV1394_NTSC_FRAME_SIZE (480 * DV1394_NTSC_PACKETS_PER_FRAME) | 
|  | #define DV1394_PAL_FRAME_SIZE  (480 * DV1394_PAL_PACKETS_PER_FRAME) | 
|  |  | 
|  |  | 
|  | /* ioctl() commands */ | 
|  | #include "ieee1394-ioctl.h" | 
|  |  | 
|  |  | 
|  | enum pal_or_ntsc { | 
|  | DV1394_NTSC = 0, | 
|  | DV1394_PAL | 
|  | }; | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | /* this is the argument to DV1394_INIT */ | 
|  | struct dv1394_init { | 
|  | /* DV1394_API_VERSION */ | 
|  | unsigned int api_version; | 
|  |  | 
|  | /* isochronous transmission channel to use */ | 
|  | unsigned int channel; | 
|  |  | 
|  | /* number of frames in the ringbuffer. Must be at least 2 | 
|  | and at most DV1394_MAX_FRAMES. */ | 
|  | unsigned int n_frames; | 
|  |  | 
|  | /* send/receive PAL or NTSC video format */ | 
|  | enum pal_or_ntsc format; | 
|  |  | 
|  | /* the following are used only for transmission */ | 
|  |  | 
|  | /* set these to zero unless you want a | 
|  | non-default empty packet rate (see below) */ | 
|  | unsigned long cip_n; | 
|  | unsigned long cip_d; | 
|  |  | 
|  | /* set this to zero unless you want a | 
|  | non-default SYT cycle offset (default = 3 cycles) */ | 
|  | unsigned int syt_offset; | 
|  | }; | 
|  |  | 
|  | /* NOTE: you may only allocate the DV frame ringbuffer once each time | 
|  | you open the dv1394 device. DV1394_INIT will fail if you call it a | 
|  | second time with different 'n_frames' or 'format' arguments (which | 
|  | would imply a different size for the ringbuffer). If you need a | 
|  | different buffer size, simply close and re-open the device, then | 
|  | initialize it with your new settings. */ | 
|  |  | 
|  | /* Q: What are cip_n and cip_d? */ | 
|  |  | 
|  | /* | 
|  | A: DV video streams do not utilize 100% of the potential bandwidth offered | 
|  | by IEEE 1394 (FireWire). To achieve the correct rate of data transmission, | 
|  | DV devices must periodically insert empty packets into the 1394 data stream. | 
|  | Typically there is one empty packet per 14-16 data-carrying packets. | 
|  |  | 
|  | Some DV devices will accept a wide range of empty packet rates, while others | 
|  | require a precise rate. If the dv1394 driver produces empty packets at | 
|  | a rate that your device does not accept, you may see ugly patterns on the | 
|  | DV output, or even no output at all. | 
|  |  | 
|  | The default empty packet insertion rate seems to work for many people; if | 
|  | your DV output is stable, you can simply ignore this discussion. However, | 
|  | we have exposed the empty packet rate as a parameter to support devices that | 
|  | do not work with the default rate. | 
|  |  | 
|  | The decision to insert an empty packet is made with a numerator/denominator | 
|  | algorithm. Empty packets are produced at an average rate of CIP_N / CIP_D. | 
|  | You can alter the empty packet rate by passing non-zero values for cip_n | 
|  | and cip_d to the INIT ioctl. | 
|  |  | 
|  | */ | 
|  |  | 
|  |  | 
|  |  | 
|  | struct dv1394_status { | 
|  | /* this embedded init struct returns the current dv1394 | 
|  | parameters in use */ | 
|  | struct dv1394_init init; | 
|  |  | 
|  | /* the ringbuffer frame that is currently being | 
|  | displayed. (-1 if the device is not transmitting anything) */ | 
|  | int active_frame; | 
|  |  | 
|  | /* index of the first buffer (ahead of active_frame) that | 
|  | is ready to be filled with data */ | 
|  | unsigned int first_clear_frame; | 
|  |  | 
|  | /* how many buffers, including first_clear_buffer, are | 
|  | ready to be filled with data */ | 
|  | unsigned int n_clear_frames; | 
|  |  | 
|  | /* how many times the DV stream has underflowed, overflowed, | 
|  | or otherwise encountered an error, since the previous call | 
|  | to DV1394_GET_STATUS */ | 
|  | unsigned int dropped_frames; | 
|  |  | 
|  | /* N.B. The dropped_frames counter is only a lower bound on the actual | 
|  | number of dropped frames, with the special case that if dropped_frames | 
|  | is zero, then it is guaranteed that NO frames have been dropped | 
|  | since the last call to DV1394_GET_STATUS. | 
|  | */ | 
|  | }; | 
|  |  | 
|  |  | 
|  | #endif /* _DV_1394_H */ |