annotate ffmpeg/libavdevice/dv1394.h @ 13:844d341cf643 tip

Back up before ISMIR
author Yading Song <yading.song@eecs.qmul.ac.uk>
date Thu, 31 Oct 2013 13:17:06 +0000
parents 6840f77b83aa
children
rev   line source
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 */