Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | /* |
2 | * dv1394.h - DV input/output over IEEE 1394 on OHCI chips | |
3 | * Copyright (C)2001 Daniel Maas <dmaas@dcine.com> | |
4 | * receive by Dan Dennedy <dan@dennedy.org> | |
5 | * | |
6 | * based on: | |
7 | * video1394.h - driver for OHCI 1394 boards | |
8 | * Copyright (C)1999,2000 Sebastien Rougeaux <sebastien.rougeaux@anu.edu.au> | |
9 | * Peter Schlaile <udbz@rz.uni-karlsruhe.de> | |
10 | * | |
11 | * This program is free software; you can redistribute it and/or modify | |
12 | * it under the terms of the GNU General Public License as published by | |
13 | * the Free Software Foundation; either version 2 of the License, or | |
14 | * (at your option) any later version. | |
15 | * | |
16 | * This program is distributed in the hope that it will be useful, | |
17 | * but WITHOUT ANY WARRANTY; without even the implied warranty of | |
18 | * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | |
19 | * GNU General Public License for more details. | |
20 | * | |
21 | * You should have received a copy of the GNU General Public License | |
22 | * along with this program; if not, write to the Free Software Foundation, | |
23 | * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. | |
24 | */ | |
25 | ||
26 | #ifndef _DV_1394_H | |
27 | #define _DV_1394_H | |
28 | ||
29 | /* This is the public user-space interface. Try not to break it. */ | |
30 | ||
31 | #define DV1394_API_VERSION 0x20011127 | |
32 | ||
33 | /* ******************** | |
34 | ** ** | |
35 | ** DV1394 API ** | |
36 | ** ** | |
37 | ******************** | |
38 | ||
39 | There are two methods of operating the DV1394 DV output device. | |
40 | ||
41 | 1) | |
42 | ||
43 | The simplest is an interface based on write(): simply write | |
44 | full DV frames of data to the device, and they will be transmitted | |
45 | as quickly as possible. The FD may be set for non-blocking I/O, | |
46 | in which case you can use select() or poll() to wait for output | |
47 | buffer space. | |
48 | ||
49 | To set the DV output parameters (e.g. whether you want NTSC or PAL | |
50 | video), use the DV1394_INIT ioctl, passing in the parameters you | |
51 | want in a struct dv1394_init. | |
52 | ||
53 | Example 1: | |
54 | To play a raw .DV file: cat foo.DV > /dev/dv1394 | |
55 | (cat will use write() internally) | |
56 | ||
57 | Example 2: | |
58 | static struct dv1394_init init = { | |
59 | 0x63, (broadcast channel) | |
60 | 4, (four-frame ringbuffer) | |
61 | DV1394_NTSC, (send NTSC video) | |
62 | 0, 0 (default empty packet rate) | |
63 | } | |
64 | ||
65 | ioctl(fd, DV1394_INIT, &init); | |
66 | ||
67 | while (1) { | |
68 | read( <a raw DV file>, buf, DV1394_NTSC_FRAME_SIZE ); | |
69 | write( <the dv1394 FD>, buf, DV1394_NTSC_FRAME_SIZE ); | |
70 | } | |
71 | ||
72 | 2) | |
73 | ||
74 | For more control over buffering, and to avoid unnecessary copies | |
75 | of the DV data, you can use the more sophisticated the mmap() interface. | |
76 | First, call the DV1394_INIT ioctl to specify your parameters, | |
77 | including the number of frames in the ringbuffer. Then, calling mmap() | |
78 | on the dv1394 device will give you direct access to the ringbuffer | |
79 | from which the DV card reads your frame data. | |
80 | ||
81 | The ringbuffer is simply one large, contiguous region of memory | |
82 | containing two or more frames of packed DV data. Each frame of DV data | |
83 | is 120000 bytes (NTSC) or 144000 bytes (PAL). | |
84 | ||
85 | Fill one or more frames in the ringbuffer, then use the DV1394_SUBMIT_FRAMES | |
86 | ioctl to begin I/O. You can use either the DV1394_WAIT_FRAMES ioctl | |
87 | or select()/poll() to wait until the frames are transmitted. Next, you'll | |
88 | need to call the DV1394_GET_STATUS ioctl to determine which ringbuffer | |
89 | frames are clear (ready to be filled with new DV data). Finally, use | |
90 | DV1394_SUBMIT_FRAMES again to send the new data to the DV output. | |
91 | ||
92 | ||
93 | Example: here is what a four-frame ringbuffer might look like | |
94 | during DV transmission: | |
95 | ||
96 | ||
97 | frame 0 frame 1 frame 2 frame 3 | |
98 | ||
99 | *--------------------------------------* | |
100 | | CLEAR | DV data | DV data | CLEAR | | |
101 | *--------------------------------------* | |
102 | <ACTIVE> | |
103 | ||
104 | transmission goes in this direction --->>> | |
105 | ||
106 | ||
107 | The DV hardware is currently transmitting the data in frame 1. | |
108 | Once frame 1 is finished, it will automatically transmit frame 2. | |
109 | (if frame 2 finishes before frame 3 is submitted, the device | |
110 | will continue to transmit frame 2, and will increase the dropped_frames | |
111 | counter each time it repeats the transmission). | |
112 | ||
113 | ||
114 | If you called DV1394_GET_STATUS at this instant, you would | |
115 | receive the following values: | |
116 | ||
117 | n_frames = 4 | |
118 | active_frame = 1 | |
119 | first_clear_frame = 3 | |
120 | n_clear_frames = 2 | |
121 | ||
122 | At this point, you should write new DV data into frame 3 and optionally | |
123 | frame 0. Then call DV1394_SUBMIT_FRAMES to inform the device that | |
124 | it may transmit the new frames. | |
125 | ||
126 | ERROR HANDLING | |
127 | ||
128 | An error (buffer underflow/overflow or a break in the DV stream due | |
129 | to a 1394 bus reset) can be detected by checking the dropped_frames | |
130 | field of struct dv1394_status (obtained through the | |
131 | DV1394_GET_STATUS ioctl). | |
132 | ||
133 | The best way to recover from such an error is to re-initialize | |
134 | dv1394, either by using the DV1394_INIT ioctl call, or closing the | |
135 | file descriptor and opening it again. (note that you must unmap all | |
136 | ringbuffer mappings when closing the file descriptor, or else | |
137 | dv1394 will still be considered 'in use'). | |
138 | ||
139 | MAIN LOOP | |
140 | ||
141 | For maximum efficiency and robustness against bus errors, you are | |
142 | advised to model the main loop of your application after the | |
143 | following pseudo-code example: | |
144 | ||
145 | (checks of system call return values omitted for brevity; always | |
146 | check return values in your code!) | |
147 | ||
148 | while ( frames left ) { | |
149 | ||
150 | struct pollfd *pfd = ...; | |
151 | ||
152 | pfd->fd = dv1394_fd; | |
153 | pfd->revents = 0; | |
154 | pfd->events = POLLOUT | POLLIN; (OUT for transmit, IN for receive) | |
155 | ||
156 | (add other sources of I/O here) | |
157 | ||
158 | poll(pfd, 1, -1); (or select(); add a timeout if you want) | |
159 | ||
160 | if (pfd->revents) { | |
161 | struct dv1394_status status; | |
162 | ||
163 | ioctl(dv1394_fd, DV1394_GET_STATUS, &status); | |
164 | ||
165 | if (status.dropped_frames > 0) { | |
166 | reset_dv1394(); | |
167 | } else { | |
168 | for (int i = 0; i < status.n_clear_frames; i++) { | |
169 | copy_DV_frame(); | |
170 | } | |
171 | } | |
172 | } | |
173 | } | |
174 | ||
175 | where copy_DV_frame() reads or writes on the dv1394 file descriptor | |
176 | (read/write mode) or copies data to/from the mmap ringbuffer and | |
177 | then calls ioctl(DV1394_SUBMIT_FRAMES) to notify dv1394 that new | |
178 | frames are availble (mmap mode). | |
179 | ||
180 | reset_dv1394() is called in the event of a buffer | |
181 | underflow/overflow or a halt in the DV stream (e.g. due to a 1394 | |
182 | bus reset). To guarantee recovery from the error, this function | |
183 | should close the dv1394 file descriptor (and munmap() all | |
184 | ringbuffer mappings, if you are using them), then re-open the | |
185 | dv1394 device (and re-map the ringbuffer). | |
186 | ||
187 | */ | |
188 | ||
189 | ||
190 | /* maximum number of frames in the ringbuffer */ | |
191 | #define DV1394_MAX_FRAMES 32 | |
192 | ||
193 | /* number of *full* isochronous packets per DV frame */ | |
194 | #define DV1394_NTSC_PACKETS_PER_FRAME 250 | |
195 | #define DV1394_PAL_PACKETS_PER_FRAME 300 | |
196 | ||
197 | /* size of one frame's worth of DV data, in bytes */ | |
198 | #define DV1394_NTSC_FRAME_SIZE (480 * DV1394_NTSC_PACKETS_PER_FRAME) | |
199 | #define DV1394_PAL_FRAME_SIZE (480 * DV1394_PAL_PACKETS_PER_FRAME) | |
200 | ||
201 | ||
202 | /* ioctl() commands */ | |
203 | #include "ieee1394-ioctl.h" | |
204 | ||
205 | ||
206 | enum pal_or_ntsc { | |
207 | DV1394_NTSC = 0, | |
208 | DV1394_PAL | |
209 | }; | |
210 | ||
211 | ||
212 | ||
213 | ||
214 | /* this is the argument to DV1394_INIT */ | |
215 | struct dv1394_init { | |
216 | /* DV1394_API_VERSION */ | |
217 | unsigned int api_version; | |
218 | ||
219 | /* isochronous transmission channel to use */ | |
220 | unsigned int channel; | |
221 | ||
222 | /* number of frames in the ringbuffer. Must be at least 2 | |
223 | and at most DV1394_MAX_FRAMES. */ | |
224 | unsigned int n_frames; | |
225 | ||
226 | /* send/receive PAL or NTSC video format */ | |
227 | enum pal_or_ntsc format; | |
228 | ||
229 | /* the following are used only for transmission */ | |
230 | ||
231 | /* set these to zero unless you want a | |
232 | non-default empty packet rate (see below) */ | |
233 | unsigned long cip_n; | |
234 | unsigned long cip_d; | |
235 | ||
236 | /* set this to zero unless you want a | |
237 | non-default SYT cycle offset (default = 3 cycles) */ | |
238 | unsigned int syt_offset; | |
239 | }; | |
240 | ||
241 | /* NOTE: you may only allocate the DV frame ringbuffer once each time | |
242 | you open the dv1394 device. DV1394_INIT will fail if you call it a | |
243 | second time with different 'n_frames' or 'format' arguments (which | |
244 | would imply a different size for the ringbuffer). If you need a | |
245 | different buffer size, simply close and re-open the device, then | |
246 | initialize it with your new settings. */ | |
247 | ||
248 | /* Q: What are cip_n and cip_d? */ | |
249 | ||
250 | /* | |
251 | A: DV video streams do not utilize 100% of the potential bandwidth offered | |
252 | by IEEE 1394 (FireWire). To achieve the correct rate of data transmission, | |
253 | DV devices must periodically insert empty packets into the 1394 data stream. | |
254 | Typically there is one empty packet per 14-16 data-carrying packets. | |
255 | ||
256 | Some DV devices will accept a wide range of empty packet rates, while others | |
257 | require a precise rate. If the dv1394 driver produces empty packets at | |
258 | a rate that your device does not accept, you may see ugly patterns on the | |
259 | DV output, or even no output at all. | |
260 | ||
261 | The default empty packet insertion rate seems to work for many people; if | |
262 | your DV output is stable, you can simply ignore this discussion. However, | |
263 | we have exposed the empty packet rate as a parameter to support devices that | |
264 | do not work with the default rate. | |
265 | ||
266 | The decision to insert an empty packet is made with a numerator/denominator | |
267 | algorithm. Empty packets are produced at an average rate of CIP_N / CIP_D. | |
268 | You can alter the empty packet rate by passing non-zero values for cip_n | |
269 | and cip_d to the INIT ioctl. | |
270 | ||
271 | */ | |
272 | ||
273 | ||
274 | ||
275 | struct dv1394_status { | |
276 | /* this embedded init struct returns the current dv1394 | |
277 | parameters in use */ | |
278 | struct dv1394_init init; | |
279 | ||
280 | /* the ringbuffer frame that is currently being | |
281 | displayed. (-1 if the device is not transmitting anything) */ | |
282 | int active_frame; | |
283 | ||
284 | /* index of the first buffer (ahead of active_frame) that | |
285 | is ready to be filled with data */ | |
286 | unsigned int first_clear_frame; | |
287 | ||
288 | /* how many buffers, including first_clear_buffer, are | |
289 | ready to be filled with data */ | |
290 | unsigned int n_clear_frames; | |
291 | ||
292 | /* how many times the DV stream has underflowed, overflowed, | |
293 | or otherwise encountered an error, since the previous call | |
294 | to DV1394_GET_STATUS */ | |
295 | unsigned int dropped_frames; | |
296 | ||
297 | /* N.B. The dropped_frames counter is only a lower bound on the actual | |
298 | number of dropped frames, with the special case that if dropped_frames | |
299 | is zero, then it is guaranteed that NO frames have been dropped | |
300 | since the last call to DV1394_GET_STATUS. | |
301 | */ | |
302 | }; | |
303 | ||
304 | ||
305 | #endif /* _DV_1394_H */ |