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