~ubuntu-branches/ubuntu/utopic/libav/utopic

« back to all changes in this revision

Viewing changes to libavdevice/dv1394.h

  • Committer: Bazaar Package Importer
  • Author(s): Reinhard Tartler
  • Date: 2011-03-20 12:09:31 UTC
  • Revision ID: james.westby@ubuntu.com-20110320120931-nfhi9tiok27gxhw1
Tags: upstream-0.6.2
ImportĀ upstreamĀ versionĀ 0.6.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
/*
 
2
 * 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
 *
 
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( <a raw DV file>, buf, DV1394_NTSC_FRAME_SIZE );
 
79
                  write( <the dv1394 FD>, buf, DV1394_NTSC_FRAME_SIZE );
 
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
                   <ACTIVE>
 
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
              for(int i = 0; i < status.n_clear_frames; i++) {
 
179
                  copy_DV_frame();
 
180
              }
 
181
         }
 
182
    }
 
183
   }
 
184
 
 
185
   where copy_DV_frame() reads or writes on the dv1394 file descriptor
 
186
   (read/write mode) or copies data to/from the mmap ringbuffer and
 
187
   then calls ioctl(DV1394_SUBMIT_FRAMES) to notify dv1394 that new
 
188
   frames are availble (mmap mode).
 
189
 
 
190
   reset_dv1394() is called in the event of a buffer
 
191
   underflow/overflow or a halt in the DV stream (e.g. due to a 1394
 
192
   bus reset). To guarantee recovery from the error, this function
 
193
   should close the dv1394 file descriptor (and munmap() all
 
194
   ringbuffer mappings, if you are using them), then re-open the
 
195
   dv1394 device (and re-map the ringbuffer).
 
196
 
 
197
*/
 
198
 
 
199
 
 
200
/* maximum number of frames in the ringbuffer */
 
201
#define DV1394_MAX_FRAMES 32
 
202
 
 
203
/* number of *full* isochronous packets per DV frame */
 
204
#define DV1394_NTSC_PACKETS_PER_FRAME 250
 
205
#define DV1394_PAL_PACKETS_PER_FRAME  300
 
206
 
 
207
/* size of one frame's worth of DV data, in bytes */
 
208
#define DV1394_NTSC_FRAME_SIZE (480 * DV1394_NTSC_PACKETS_PER_FRAME)
 
209
#define DV1394_PAL_FRAME_SIZE  (480 * DV1394_PAL_PACKETS_PER_FRAME)
 
210
 
 
211
 
 
212
/* ioctl() commands */
 
213
 
 
214
enum {
 
215
        /* I don't like using 0 as a valid ioctl() */
 
216
        DV1394_INVALID = 0,
 
217
 
 
218
 
 
219
        /* get the driver ready to transmit video.
 
220
           pass a struct dv1394_init* as the parameter (see below),
 
221
           or NULL to get default parameters */
 
222
        DV1394_INIT,
 
223
 
 
224
 
 
225
        /* stop transmitting video and free the ringbuffer */
 
226
        DV1394_SHUTDOWN,
 
227
 
 
228
 
 
229
        /* submit N new frames to be transmitted, where
 
230
           the index of the first new frame is first_clear_buffer,
 
231
           and the index of the last new frame is
 
232
           (first_clear_buffer + N) % n_frames */
 
233
        DV1394_SUBMIT_FRAMES,
 
234
 
 
235
 
 
236
        /* block until N buffers are clear (pass N as the parameter)
 
237
           Because we re-transmit the last frame on underrun, there
 
238
           will at most be n_frames - 1 clear frames at any time */
 
239
        DV1394_WAIT_FRAMES,
 
240
 
 
241
        /* capture new frames that have been received, where
 
242
           the index of the first new frame is first_clear_buffer,
 
243
           and the index of the last new frame is
 
244
           (first_clear_buffer + N) % n_frames */
 
245
        DV1394_RECEIVE_FRAMES,
 
246
 
 
247
 
 
248
        DV1394_START_RECEIVE,
 
249
 
 
250
 
 
251
        /* pass a struct dv1394_status* as the parameter (see below) */
 
252
        DV1394_GET_STATUS,
 
253
};
 
254
 
 
255
 
 
256
 
 
257
enum pal_or_ntsc {
 
258
        DV1394_NTSC = 0,
 
259
        DV1394_PAL
 
260
};
 
261
 
 
262
 
 
263
 
 
264
 
 
265
/* this is the argument to DV1394_INIT */
 
266
struct dv1394_init {
 
267
        /* DV1394_API_VERSION */
 
268
        unsigned int api_version;
 
269
 
 
270
        /* isochronous transmission channel to use */
 
271
        unsigned int channel;
 
272
 
 
273
        /* number of frames in the ringbuffer. Must be at least 2
 
274
           and at most DV1394_MAX_FRAMES. */
 
275
        unsigned int n_frames;
 
276
 
 
277
        /* send/receive PAL or NTSC video format */
 
278
        enum pal_or_ntsc format;
 
279
 
 
280
        /* the following are used only for transmission */
 
281
 
 
282
        /* set these to zero unless you want a
 
283
           non-default empty packet rate (see below) */
 
284
        unsigned long cip_n;
 
285
        unsigned long cip_d;
 
286
 
 
287
        /* set this to zero unless you want a
 
288
           non-default SYT cycle offset (default = 3 cycles) */
 
289
        unsigned int syt_offset;
 
290
};
 
291
 
 
292
/* NOTE: you may only allocate the DV frame ringbuffer once each time
 
293
   you open the dv1394 device. DV1394_INIT will fail if you call it a
 
294
   second time with different 'n_frames' or 'format' arguments (which
 
295
   would imply a different size for the ringbuffer). If you need a
 
296
   different buffer size, simply close and re-open the device, then
 
297
   initialize it with your new settings. */
 
298
 
 
299
/* Q: What are cip_n and cip_d? */
 
300
 
 
301
/*
 
302
  A: DV video streams do not utilize 100% of the potential bandwidth offered
 
303
  by IEEE 1394 (FireWire). To achieve the correct rate of data transmission,
 
304
  DV devices must periodically insert empty packets into the 1394 data stream.
 
305
  Typically there is one empty packet per 14-16 data-carrying packets.
 
306
 
 
307
  Some DV devices will accept a wide range of empty packet rates, while others
 
308
  require a precise rate. If the dv1394 driver produces empty packets at
 
309
  a rate that your device does not accept, you may see ugly patterns on the
 
310
  DV output, or even no output at all.
 
311
 
 
312
  The default empty packet insertion rate seems to work for many people; if
 
313
  your DV output is stable, you can simply ignore this discussion. However,
 
314
  we have exposed the empty packet rate as a parameter to support devices that
 
315
  do not work with the default rate.
 
316
 
 
317
  The decision to insert an empty packet is made with a numerator/denominator
 
318
  algorithm. Empty packets are produced at an average rate of CIP_N / CIP_D.
 
319
  You can alter the empty packet rate by passing non-zero values for cip_n
 
320
  and cip_d to the INIT ioctl.
 
321
 
 
322
 */
 
323
 
 
324
 
 
325
 
 
326
struct dv1394_status {
 
327
        /* this embedded init struct returns the current dv1394
 
328
           parameters in use */
 
329
        struct dv1394_init init;
 
330
 
 
331
        /* the ringbuffer frame that is currently being
 
332
           displayed. (-1 if the device is not transmitting anything) */
 
333
        int active_frame;
 
334
 
 
335
        /* index of the first buffer (ahead of active_frame) that
 
336
           is ready to be filled with data */
 
337
        unsigned int first_clear_frame;
 
338
 
 
339
        /* how many buffers, including first_clear_buffer, are
 
340
           ready to be filled with data */
 
341
        unsigned int n_clear_frames;
 
342
 
 
343
        /* how many times the DV stream has underflowed, overflowed,
 
344
           or otherwise encountered an error, since the previous call
 
345
           to DV1394_GET_STATUS */
 
346
        unsigned int dropped_frames;
 
347
 
 
348
        /* N.B. The dropped_frames counter is only a lower bound on the actual
 
349
           number of dropped frames, with the special case that if dropped_frames
 
350
           is zero, then it is guaranteed that NO frames have been dropped
 
351
           since the last call to DV1394_GET_STATUS.
 
352
        */
 
353
};
 
354
 
 
355
 
 
356
#endif /* AVDEVICE_DV1394_H */