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