Mercurial > libavformat.hg
annotate dv1394.h @ 1491:89f88d324eea libavformat
rename cropTbl -> ff_cropTbl
author | mru |
---|---|
date | Sun, 12 Nov 2006 20:08:09 +0000 |
parents | 0899bfe4105c |
children | 06083249909c |
rev | line source |
---|---|
27 | 1 /* |
2 * dv1394.h - DV input/output over IEEE 1394 on OHCI chips | |
3 * Copyright (C)2001 Daniel Maas <dmaas@dcine.com> | |
4 * receive, proc_fs 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 * | |
1358
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
11 * This file is part of FFmpeg. |
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
12 * |
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
13 * FFmpeg is free software; you can redistribute it and/or |
1288
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
14 * modify it under the terms of the GNU Lesser General Public |
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
15 * License as published by the Free Software Foundation; either |
1358
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
16 * version 2.1 of the License, or (at your option) any later version. |
27 | 17 * |
1358
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
18 * FFmpeg is distributed in the hope that it will be useful, |
27 | 19 * but WITHOUT ANY WARRANTY; without even the implied warranty of |
1288
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
20 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU |
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
21 * Lesser General Public License for more details. |
27 | 22 * |
1288
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
23 * You should have received a copy of the GNU Lesser General Public |
1358
0899bfe4105c
Change license headers to say 'FFmpeg' instead of 'this program/this library'
diego
parents:
1288
diff
changeset
|
24 * License along with FFmpeg; if not, write to the Free Software |
1288
2c9aa272e75d
Switch license from GPL to LGPL, this file originates from libdv, which
diego
parents:
896
diff
changeset
|
25 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA |
896
edbe5c3717f9
Update licensing information: The FSF changed postal address.
diego
parents:
887
diff
changeset
|
26 * |
27 | 27 */ |
28 | |
29 #ifndef _DV_1394_H | |
30 #define _DV_1394_H | |
31 | |
185
d98ed04d62a6
patch for DV capturing by Dan Dennedy <dan at dennedy dot org>
romansh
parents:
156
diff
changeset
|
32 #define DV1394_DEFAULT_CHANNEL 63 |
27 | 33 #define DV1394_DEFAULT_CARD 0 |
34 #define DV1394_RING_FRAMES 20 | |
35 | |
36 #define DV1394_WIDTH 720 | |
156 | 37 #define DV1394_NTSC_HEIGHT 480 |
38 #define DV1394_PAL_HEIGHT 576 | |
27 | 39 |
40 /* This is the public user-space interface. Try not to break it. */ | |
41 | |
42 #define DV1394_API_VERSION 0x20011127 | |
43 | |
44 /* ******************** | |
45 ** ** | |
46 ** DV1394 API ** | |
47 ** ** | |
48 ******************** | |
49 | |
50 There are two methods of operating the DV1394 DV output device. | |
51 | |
52 1) | |
53 | |
54 The simplest is an interface based on write(): simply write | |
55 full DV frames of data to the device, and they will be transmitted | |
56 as quickly as possible. The FD may be set for non-blocking I/O, | |
57 in which case you can use select() or poll() to wait for output | |
58 buffer space. | |
59 | |
60 To set the DV output parameters (e.g. whether you want NTSC or PAL | |
61 video), use the DV1394_INIT ioctl, passing in the parameters you | |
62 want in a struct dv1394_init. | |
885 | 63 |
27 | 64 Example 1: |
65 To play a raw .DV file: cat foo.DV > /dev/dv1394 | |
887 | 66 (cat will use write() internally) |
27 | 67 |
68 Example 2: | |
69 static struct dv1394_init init = { | |
887 | 70 0x63, (broadcast channel) |
27 | 71 4, (four-frame ringbuffer) |
887 | 72 DV1394_NTSC, (send NTSC video) |
73 0, 0 (default empty packet rate) | |
27 | 74 } |
75 | |
887 | 76 ioctl(fd, DV1394_INIT, &init); |
27 | 77 |
887 | 78 while(1) { |
79 read( <a raw DV file>, buf, DV1394_NTSC_FRAME_SIZE ); | |
80 write( <the dv1394 FD>, buf, DV1394_NTSC_FRAME_SIZE ); | |
27 | 81 } |
82 | |
83 2) | |
84 | |
85 For more control over buffering, and to avoid unnecessary copies | |
885 | 86 of the DV data, you can use the more sophisticated the mmap() interface. |
87 First, call the DV1394_INIT ioctl to specify your parameters, | |
88 including the number of frames in the ringbuffer. Then, calling mmap() | |
27 | 89 on the dv1394 device will give you direct access to the ringbuffer |
90 from which the DV card reads your frame data. | |
91 | |
92 The ringbuffer is simply one large, contiguous region of memory | |
93 containing two or more frames of packed DV data. Each frame of DV data | |
94 is 120000 bytes (NTSC) or 144000 bytes (PAL). | |
95 | |
96 Fill one or more frames in the ringbuffer, then use the DV1394_SUBMIT_FRAMES | |
97 ioctl to begin I/O. You can use either the DV1394_WAIT_FRAMES ioctl | |
98 or select()/poll() to wait until the frames are transmitted. Next, you'll | |
99 need to call the DV1394_GET_STATUS ioctl to determine which ringbuffer | |
100 frames are clear (ready to be filled with new DV data). Finally, use | |
101 DV1394_SUBMIT_FRAMES again to send the new data to the DV output. | |
102 | |
103 | |
104 Example: here is what a four-frame ringbuffer might look like | |
105 during DV transmission: | |
106 | |
107 | |
108 frame 0 frame 1 frame 2 frame 3 | |
109 | |
887 | 110 *--------------------------------------* |
27 | 111 | CLEAR | DV data | DV data | CLEAR | |
112 *--------------------------------------* | |
885 | 113 <ACTIVE> |
27 | 114 |
887 | 115 transmission goes in this direction --->>> |
27 | 116 |
117 | |
118 The DV hardware is currently transmitting the data in frame 1. | |
119 Once frame 1 is finished, it will automatically transmit frame 2. | |
120 (if frame 2 finishes before frame 3 is submitted, the device | |
121 will continue to transmit frame 2, and will increase the dropped_frames | |
122 counter each time it repeats the transmission). | |
123 | |
885 | 124 |
27 | 125 If you called DV1394_GET_STATUS at this instant, you would |
126 receive the following values: | |
885 | 127 |
27 | 128 n_frames = 4 |
887 | 129 active_frame = 1 |
130 first_clear_frame = 3 | |
131 n_clear_frames = 2 | |
27 | 132 |
133 At this point, you should write new DV data into frame 3 and optionally | |
134 frame 0. Then call DV1394_SUBMIT_FRAMES to inform the device that | |
135 it may transmit the new frames. | |
136 | |
137 ERROR HANDLING | |
138 | |
139 An error (buffer underflow/overflow or a break in the DV stream due | |
140 to a 1394 bus reset) can be detected by checking the dropped_frames | |
141 field of struct dv1394_status (obtained through the | |
142 DV1394_GET_STATUS ioctl). | |
143 | |
144 The best way to recover from such an error is to re-initialize | |
145 dv1394, either by using the DV1394_INIT ioctl call, or closing the | |
146 file descriptor and opening it again. (note that you must unmap all | |
147 ringbuffer mappings when closing the file descriptor, or else | |
148 dv1394 will still be considered 'in use'). | |
149 | |
150 MAIN LOOP | |
151 | |
152 For maximum efficiency and robustness against bus errors, you are | |
153 advised to model the main loop of your application after the | |
154 following pseudo-code example: | |
155 | |
156 (checks of system call return values omitted for brevity; always | |
157 check return values in your code!) | |
885 | 158 |
27 | 159 while( frames left ) { |
885 | 160 |
27 | 161 struct pollfd *pfd = ...; |
162 | |
163 pfd->fd = dv1394_fd; | |
164 pfd->revents = 0; | |
165 pfd->events = POLLOUT | POLLIN; (OUT for transmit, IN for receive) | |
166 | |
167 (add other sources of I/O here) | |
885 | 168 |
27 | 169 poll(pfd, 1, -1); (or select(); add a timeout if you want) |
170 | |
171 if(pfd->revents) { | |
172 struct dv1394_status status; | |
885 | 173 |
27 | 174 ioctl(dv1394_fd, DV1394_GET_STATUS, &status); |
175 | |
887 | 176 if(status.dropped_frames > 0) { |
177 reset_dv1394(); | |
27 | 178 } else { |
179 for(int i = 0; i < status.n_clear_frames; i++) { | |
887 | 180 copy_DV_frame(); |
27 | 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 availble (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). | |
885 | 197 |
27 | 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 */ | |
185
d98ed04d62a6
patch for DV capturing by Dan Dennedy <dan at dennedy dot org>
romansh
parents:
156
diff
changeset
|
205 #define DV1394_NTSC_PACKETS_PER_FRAME 250 |
d98ed04d62a6
patch for DV capturing by Dan Dennedy <dan at dennedy dot org>
romansh
parents:
156
diff
changeset
|
206 #define DV1394_PAL_PACKETS_PER_FRAME 300 |
27 | 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) | |
185
d98ed04d62a6
patch for DV capturing by Dan Dennedy <dan at dennedy dot org>
romansh
parents:
156
diff
changeset
|
210 #define DV1394_PAL_FRAME_SIZE (480 * DV1394_PAL_PACKETS_PER_FRAME) |
27 | 211 |
212 | |
213 /* ioctl() commands */ | |
214 | |
215 enum { | |
887 | 216 /* I don't like using 0 as a valid ioctl() */ |
217 DV1394_INVALID = 0, | |
27 | 218 |
219 | |
887 | 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, | |
27 | 224 |
225 | |
887 | 226 /* stop transmitting video and free the ringbuffer */ |
227 DV1394_SHUTDOWN, | |
27 | 228 |
229 | |
887 | 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, | |
27 | 235 |
236 | |
887 | 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, | |
27 | 241 |
887 | 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, | |
27 | 247 |
248 | |
887 | 249 DV1394_START_RECEIVE, |
27 | 250 |
251 | |
887 | 252 /* pass a struct dv1394_status* as the parameter (see below) */ |
253 DV1394_GET_STATUS, | |
27 | 254 }; |
255 | |
256 | |
257 | |
258 enum pal_or_ntsc { | |
887 | 259 DV1394_NTSC = 0, |
260 DV1394_PAL | |
27 | 261 }; |
262 | |
263 | |
264 | |
265 | |
266 /* this is the argument to DV1394_INIT */ | |
267 struct dv1394_init { | |
887 | 268 /* DV1394_API_VERSION */ |
269 unsigned int api_version; | |
885 | 270 |
887 | 271 /* isochronous transmission channel to use */ |
272 unsigned int channel; | |
27 | 273 |
887 | 274 /* number of frames in the ringbuffer. Must be at least 2 |
275 and at most DV1394_MAX_FRAMES. */ | |
276 unsigned int n_frames; | |
27 | 277 |
887 | 278 /* send/receive PAL or NTSC video format */ |
279 enum pal_or_ntsc format; | |
27 | 280 |
887 | 281 /* the following are used only for transmission */ |
885 | 282 |
887 | 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; | |
27 | 287 |
887 | 288 /* set this to zero unless you want a |
289 non-default SYT cycle offset (default = 3 cycles) */ | |
290 unsigned int syt_offset; | |
27 | 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. */ | |
885 | 299 |
27 | 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 | |
885 | 316 do not work with the default rate. |
27 | 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. | |
885 | 322 |
27 | 323 */ |
324 | |
325 | |
326 | |
327 struct dv1394_status { | |
887 | 328 /* this embedded init struct returns the current dv1394 |
329 parameters in use */ | |
330 struct dv1394_init init; | |
27 | 331 |
887 | 332 /* the ringbuffer frame that is currently being |
333 displayed. (-1 if the device is not transmitting anything) */ | |
334 int active_frame; | |
27 | 335 |
887 | 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; | |
27 | 339 |
887 | 340 /* how many buffers, including first_clear_buffer, are |
341 ready to be filled with data */ | |
342 unsigned int n_clear_frames; | |
27 | 343 |
887 | 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; | |
27 | 348 |
887 | 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 */ | |
27 | 354 }; |
355 | |
356 | |
357 #endif /* _DV_1394_H */ |