• Home
  • History
  • Annotate
  • only in this directory
NameDateSize

..25-Jun-20164 KiB

fw-calling.txtH A D25-Jun-20162.8 KiB

fw-decoder-api.txtH A D25-Jun-20168 KiB

fw-decoder-regs.txtH A D25-Jun-201622.8 KiB

fw-dma.txtH A D25-Jun-20163.6 KiB

fw-encoder-api.txtH A D25-Jun-201618.8 KiB

fw-memory.txtH A D25-Jun-20164.6 KiB

fw-osd-api.txtH A D25-Jun-20167.7 KiB

fw-upload.txtH A D25-Jun-20162.1 KiB

README.hm12H A D25-Jun-20164 KiB

README.vbiH A D25-Jun-20162.3 KiB

README.hm12

1The cx23416 can produce (and the cx23415 can also read) raw YUV output. The
2format of a YUV frame is specific to this chip and is called HM12. 'HM' stands
3for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would
4be more accurate.
5
6The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per
7four pixels.
8
9The data is encoded as two macroblock planes, the first containing the Y
10values, the second containing UV macroblocks.
11
12The Y plane is divided into blocks of 16x16 pixels from left to right
13and from top to bottom. Each block is transmitted in turn, line-by-line.
14
15So the first 16 bytes are the first line of the top-left block, the
16second 16 bytes are the second line of the top-left block, etc. After
17transmitting this block the first line of the block on the right to the
18first block is transmitted, etc.
19
20The UV plane is divided into blocks of 16x8 UV values going from left
21to right, top to bottom. Each block is transmitted in turn, line-by-line.
22
23So the first 16 bytes are the first line of the top-left block and
24contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the
25second line of 8 UV pairs of the top-left block, etc. After transmitting
26this block the first line of the block on the right to the first block is
27transmitted, etc.
28
29The code below is given as an example on how to convert HM12 to separate
30Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels.
31
32The width of a frame is always 720 pixels, regardless of the actual specified
33width.
34
35If the height is not a multiple of 32 lines, then the captured video is
36missing macroblocks at the end and is unusable. So the height must be a
37multiple of 32.
38
39--------------------------------------------------------------------------
40
41#include <stdio.h>
42#include <stdlib.h>
43#include <string.h>
44
45static unsigned char frame[576*720*3/2];
46static unsigned char framey[576*720];
47static unsigned char frameu[576*720 / 4];
48static unsigned char framev[576*720 / 4];
49
50static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h)
51{
52    unsigned int y, x, i;
53
54    // descramble Y plane
55    // dstride = 720 = w
56    // The Y plane is divided into blocks of 16x16 pixels
57    // Each block in transmitted in turn, line-by-line.
58    for (y = 0; y < h; y += 16) {
59	for (x = 0; x < w; x += 16) {
60	    for (i = 0; i < 16; i++) {
61		memcpy(dst + x + (y + i) * dstride, src, 16);
62		src += 16;
63	    }
64	}
65    }
66}
67
68static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h)
69{
70    unsigned int y, x, i;
71
72    // descramble U/V plane
73    // dstride = 720 / 2 = w
74    // The U/V values are interlaced (UVUV...).
75    // Again, the UV plane is divided into blocks of 16x16 UV values.
76    // Each block in transmitted in turn, line-by-line.
77    for (y = 0; y < h; y += 16) {
78	for (x = 0; x < w; x += 8) {
79	    for (i = 0; i < 16; i++) {
80		int idx = x + (y + i) * dstride;
81
82		dstu[idx+0] = src[0];  dstv[idx+0] = src[1];
83		dstu[idx+1] = src[2];  dstv[idx+1] = src[3];
84		dstu[idx+2] = src[4];  dstv[idx+2] = src[5];
85		dstu[idx+3] = src[6];  dstv[idx+3] = src[7];
86		dstu[idx+4] = src[8];  dstv[idx+4] = src[9];
87		dstu[idx+5] = src[10]; dstv[idx+5] = src[11];
88		dstu[idx+6] = src[12]; dstv[idx+6] = src[13];
89		dstu[idx+7] = src[14]; dstv[idx+7] = src[15];
90		src += 16;
91	    }
92	}
93    }
94}
95
96/*************************************************************************/
97int main(int argc, char **argv)
98{
99    FILE *fin;
100    int i;
101
102    if (argc == 1) fin = stdin;
103    else fin = fopen(argv[1], "r");
104
105    if (fin == NULL) {
106	fprintf(stderr, "cannot open input\n");
107	exit(-1);
108    }
109    while (fread(frame, sizeof(frame), 1, fin) == 1) {
110	de_macro_y(framey, frame, 720, 720, 576);
111	de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2);
112	fwrite(framey, sizeof(framey), 1, stdout);
113	fwrite(framev, sizeof(framev), 1, stdout);
114	fwrite(frameu, sizeof(frameu), 1, stdout);
115    }
116    fclose(fin);
117    return 0;
118}
119
120--------------------------------------------------------------------------
121

README.vbi

1
2Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data
3=========================================================
4
5This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data
6embedded in an MPEG-2 program stream. This format is in part dictated by some
7hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6
8chips), in particular a maximum size for the VBI data. Anything longer is cut
9off when the MPEG stream is played back through the cx23415.
10
11The advantage of this format is it is very compact and that all VBI data for
12all lines can be stored while still fitting within the maximum allowed size.
13
14The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is
154 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte
16header and a 42 bytes payload each. Anything beyond this limit is cut off by
17the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits
18for a bitmask determining which lines are captured and 4 bytes for a magic cookie,
19signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data.
20If all lines are used, then there is no longer room for the bitmask. To solve this
21two different magic numbers were introduced:
22
23'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first
24unsigned long denote which lines of the first field are captured. Bits 18-31 of
25the first unsigned long and bits 0-3 of the second unsigned long are used for the
26second field.
27
28'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly
29implies that the bitmasks are 0xffffffff and 0xf.
30
31After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the
32captured VBI lines start:
33
34For each line the least significant 4 bits of the first byte contain the data type.
35Possible values are shown in the table below. The payload is in the following 42
36bytes.
37
38Here is the list of possible data types:
39
40#define IVTV_SLICED_TYPE_TELETEXT       0x1     // Teletext (uses lines 6-22 for PAL)
41#define IVTV_SLICED_TYPE_CC             0x4     // Closed Captions (line 21 NTSC)
42#define IVTV_SLICED_TYPE_WSS            0x5     // Wide Screen Signal (line 23 PAL)
43#define IVTV_SLICED_TYPE_VPS            0x7     // Video Programming System (PAL) (line 16)
44
45Hans Verkuil <hverkuil@xs4all.nl>
46