~ubuntu-branches/ubuntu/trusty/libdv/trusty

« back to all changes in this revision

Viewing changes to libdv/dv1394.h

  • Committer: Bazaar Package Importer
  • Author(s): Daniel Kobras
  • Date: 2004-07-19 12:19:44 UTC
  • mfrom: (1.2.1 upstream) (2.1.1 warty)
  • Revision ID: james.westby@ubuntu.com-20040719121944-17vuryc01yeyx8hf
Tags: 0.103-2
* debian/rules: Provide separate doc directory for libdv4-dev.
* debian/libdv4-dev.links: No longer symlink doc dir to the one
  from libdv4.
* debian/NEWS: Only install into libdv4-dev. Closes: #259694

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
 
 *
11
 
 * This program is free software; you can redistribute it and/or modify
12
 
 * it under the terms of the GNU General Public License as published by
13
 
 * the Free Software Foundation; either version 2 of the License, or
14
 
 * (at your option) any later version.
15
 
 *
16
 
 * This program is distributed in the hope that it will be useful,
17
 
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
18
 
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
19
 
 * GNU General Public License for more details.
20
 
 *
21
 
 * You should have received a copy of the GNU General Public License
22
 
 * along with this program; if not, write to the Free Software Foundation,
23
 
 * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
24
 
 */
25
 
 
26
 
#ifndef _DV_1394_H
27
 
#define _DV_1394_H
28
 
 
29
 
/* This is the public user-space interface. Try not to break it. */
30
 
 
31
 
#define DV1394_API_VERSION 0x20011127
32
 
 
33
 
/* ********************
34
 
   **                **
35
 
   **   DV1394 API   **
36
 
   **                **
37
 
   ********************
38
 
 
39
 
   There are two methods of operating the DV1394 DV output device.
40
 
 
41
 
   1)
42
 
 
43
 
   The simplest is an interface based on write(): simply write
44
 
   full DV frames of data to the device, and they will be transmitted
45
 
   as quickly as possible. The FD may be set for non-blocking I/O,
46
 
   in which case you can use select() or poll() to wait for output
47
 
   buffer space.
48
 
 
49
 
   To set the DV output parameters (e.g. whether you want NTSC or PAL
50
 
   video), use the DV1394_INIT ioctl, passing in the parameters you
51
 
   want in a struct dv1394_init.
52
 
 
53
 
   Example 1:
54
 
         To play a raw .DV file:   cat foo.DV > /dev/dv1394
55
 
         (cat will use write() internally)
56
 
 
57
 
   Example 2:
58
 
           static struct dv1394_init init = {
59
 
              0x63,        (broadcast channel)
60
 
              4,           (four-frame ringbuffer)
61
 
              DV1394_NTSC, (send NTSC video)
62
 
              0, 0         (default empty packet rate)
63
 
           }
64
 
 
65
 
           ioctl(fd, DV1394_INIT, &init);
66
 
 
67
 
           while(1) {
68
 
                  read( <a raw DV file>, buf, DV1394_NTSC_FRAME_SIZE );
69
 
                  write( <the dv1394 FD>, buf, DV1394_NTSC_FRAME_SIZE );
70
 
           }
71
 
 
72
 
   2)
73
 
 
74
 
   For more control over buffering, and to avoid unnecessary copies
75
 
   of the DV data, you can use the more sophisticated the mmap() interface. 
76
 
   First, call the DV1394_INIT ioctl to specify your parameters, 
77
 
   including the number of frames in the ringbuffer. Then, calling mmap() 
78
 
   on the dv1394 device will give you direct access to the ringbuffer
79
 
   from which the DV card reads your frame data.
80
 
 
81
 
   The ringbuffer is simply one large, contiguous region of memory
82
 
   containing two or more frames of packed DV data. Each frame of DV data
83
 
   is 120000 bytes (NTSC) or 144000 bytes (PAL).
84
 
 
85
 
   Fill one or more frames in the ringbuffer, then use the DV1394_SUBMIT_FRAMES
86
 
   ioctl to begin I/O. You can use either the DV1394_WAIT_FRAMES ioctl
87
 
   or select()/poll() to wait until the frames are transmitted. Next, you'll
88
 
   need to call the DV1394_GET_STATUS ioctl to determine which ringbuffer
89
 
   frames are clear (ready to be filled with new DV data). Finally, use
90
 
   DV1394_SUBMIT_FRAMES again to send the new data to the DV output.
91
 
 
92
 
 
93
 
   Example: here is what a four-frame ringbuffer might look like
94
 
            during DV transmission:
95
 
 
96
 
 
97
 
         frame 0   frame 1   frame 2   frame 3
98
 
 
99
 
        *--------------------------------------*
100
 
        | CLEAR   | DV data | DV data | CLEAR  |
101
 
        *--------------------------------------*
102
 
                   <ACTIVE> 
103
 
 
104
 
        transmission goes in this direction --->>>
105
 
 
106
 
 
107
 
   The DV hardware is currently transmitting the data in frame 1.
108
 
   Once frame 1 is finished, it will automatically transmit frame 2.
109
 
   (if frame 2 finishes before frame 3 is submitted, the device
110
 
   will continue to transmit frame 2, and will increase the dropped_frames
111
 
   counter each time it repeats the transmission).
112
 
 
113
 
 
114
 
   If you called DV1394_GET_STATUS at this instant, you would
115
 
   receive the following values:
116
 
   
117
 
                  n_frames          = 4
118
 
                  active_frame      = 1
119
 
                  first_clear_frame = 3
120
 
                  n_clear_frames    = 2
121
 
 
122
 
   At this point, you should write new DV data into frame 3 and optionally
123
 
   frame 0. Then call DV1394_SUBMIT_FRAMES to inform the device that
124
 
   it may transmit the new frames.
125
 
 
126
 
*/
127
 
 
128
 
 
129
 
/* maximum number of frames in the ringbuffer */
130
 
#define DV1394_MAX_FRAMES 32
131
 
 
132
 
/* number of *full* isochronous packets per DV frame */
133
 
#define DV1394_NTSC_PACKETS_PER_FRAME 250
134
 
#define DV1394_PAL_PACKETS_PER_FRAME  300
135
 
 
136
 
/* size of one frame's worth of DV data, in bytes */
137
 
#define DV1394_NTSC_FRAME_SIZE (480 * DV1394_NTSC_PACKETS_PER_FRAME)
138
 
#define DV1394_PAL_FRAME_SIZE  (480 * DV1394_PAL_PACKETS_PER_FRAME)
139
 
 
140
 
 
141
 
/* ioctl() commands */
142
 
 
143
 
enum {
144
 
        /* I don't like using 0 as a valid ioctl() */
145
 
        DV1394_INVALID = 0,
146
 
 
147
 
 
148
 
        /* get the driver ready to transmit video.
149
 
           pass a struct dv1394_init* as the parameter (see below),
150
 
           or NULL to get default parameters */
151
 
        DV1394_INIT,
152
 
 
153
 
 
154
 
        /* stop transmitting video and free the ringbuffer */
155
 
        DV1394_SHUTDOWN,
156
 
 
157
 
 
158
 
        /* submit N new frames to be transmitted, where
159
 
           the index of the first new frame is first_clear_buffer,
160
 
           and the index of the last new frame is
161
 
           (first_clear_buffer + N) % n_frames */
162
 
        DV1394_SUBMIT_FRAMES,
163
 
 
164
 
 
165
 
        /* block until N buffers are clear (pass N as the parameter)
166
 
           Because we re-transmit the last frame on underrun, there
167
 
           will at most be n_frames - 1 clear frames at any time */
168
 
        DV1394_WAIT_FRAMES,
169
 
 
170
 
        /* capture new frames that have been received, where
171
 
           the index of the first new frame is first_clear_buffer,
172
 
           and the index of the last new frame is
173
 
           (first_clear_buffer + N) % n_frames */
174
 
        DV1394_RECEIVE_FRAMES,
175
 
 
176
 
 
177
 
        DV1394_START_RECEIVE,
178
 
 
179
 
 
180
 
        /* pass a struct dv1394_status* as the parameter (see below) */
181
 
        DV1394_GET_STATUS,
182
 
};
183
 
 
184
 
 
185
 
 
186
 
enum pal_or_ntsc {
187
 
        DV1394_NTSC = 0,
188
 
        DV1394_PAL
189
 
};
190
 
 
191
 
 
192
 
 
193
 
 
194
 
/* this is the argument to DV1394_INIT */
195
 
struct dv1394_init {
196
 
        /* DV1394_API_VERSION */
197
 
        unsigned int api_version;
198
 
        
199
 
        /* isochronous transmission channel to use */
200
 
        unsigned int channel;
201
 
 
202
 
        /* number of frames in the ringbuffer. Must be at least 2
203
 
           and at most DV1394_MAX_FRAMES. */
204
 
        unsigned int n_frames;
205
 
 
206
 
        /* send/receive PAL or NTSC video format */
207
 
        enum pal_or_ntsc format;
208
 
 
209
 
        /* the following are used only for transmission */
210
 
 
211
 
        /* set these to zero unless you want a
212
 
           non-default empty packet rate (see below) */
213
 
        unsigned long cip_n;
214
 
        unsigned long cip_d;
215
 
 
216
 
        /* set this to zero unless you want a
217
 
           non-default SYT cycle offset (default = 3 cycles) */
218
 
        unsigned int syt_offset;
219
 
};
220
 
 
221
 
/* Q: What are cip_n and cip_d? */
222
 
 
223
 
/*
224
 
  A: DV video streams do not utilize 100% of the potential bandwidth offered
225
 
  by IEEE 1394 (FireWire). To achieve the correct rate of data transmission,
226
 
  DV devices must periodically insert empty packets into the 1394 data stream.
227
 
  Typically there is one empty packet per 14-16 data-carrying packets.
228
 
 
229
 
  Some DV devices will accept a wide range of empty packet rates, while others
230
 
  require a precise rate. If the dv1394 driver produces empty packets at
231
 
  a rate that your device does not accept, you may see ugly patterns on the
232
 
  DV output, or even no output at all.
233
 
 
234
 
  The default empty packet insertion rate seems to work for many people; if
235
 
  your DV output is stable, you can simply ignore this discussion. However,
236
 
  we have exposed the empty packet rate as a parameter to support devices that
237
 
  do not work with the default rate. 
238
 
 
239
 
  The decision to insert an empty packet is made with a numerator/denominator
240
 
  algorithm. Empty packets are produced at an average rate of CIP_N / CIP_D.
241
 
  You can alter the empty packet rate by passing non-zero values for cip_n
242
 
  and cip_d to the INIT ioctl.
243
 
  
244
 
 */
245
 
 
246
 
 
247
 
 
248
 
struct dv1394_status {
249
 
        /* this embedded init struct returns the current dv1394
250
 
           parameters in use */
251
 
        struct dv1394_init init;
252
 
 
253
 
        /* the ringbuffer frame that is currently being
254
 
           displayed. (-1 if the device is not transmitting anything) */
255
 
        int active_frame;
256
 
 
257
 
        /* index of the first buffer (ahead of active_frame) that
258
 
           is ready to be filled with data */
259
 
        unsigned int first_clear_frame;
260
 
 
261
 
        /* how many buffers, including first_clear_buffer, are
262
 
           ready to be filled with data */
263
 
        unsigned int n_clear_frames;
264
 
 
265
 
        /* how many times the DV output has underflowed
266
 
           since the last call to DV1394_GET_STATUS */
267
 
        unsigned int dropped_frames;
268
 
 
269
 
        /* N.B. The dropped_frames counter is only a lower bound on the actual
270
 
           number of dropped frames, with the special case that if dropped_frames
271
 
           is zero, then it is guaranteed that NO frames have been dropped
272
 
           since the last call to DV1394_GET_STATUS.
273
 
        */
274
 
};
275
 
 
276
 
 
277
 
#endif /* _DV_1394_H */