On Mon, 2009-03-09 at 22:53 +0100, Hans Verkuil wrote:
> On Monday 09 March 2009 21:47:55 Andy Walls wrote:
> I'm almost done the spec
> > changes (see the diff inline below), but I can easily change things.
> >
> Nice documentation!
Thanks! When I'm motivated, for some mysterious reason, to do some
documentation, I try to be thorough.
The linemask[2] bitmask specifications are giving me some mild
headaches. The linemaks output by the cx18 driver code for NTSC CC
don't seem to be consistent with README.vbi:
xxd -g4 foovbi.mpg | less
0000800: 000001ba 44000c66 240101d1 d3faffff ....D..f$.......
0000810: 000001bd 00428480 07210001 0001ffff .....B...!......
0000820: 69747630 00800000 00000000 04c146ad itv0..........F.
0000830: 107f1080 10821081 10841081 10851084 ................
0000840: 10811083 10711063 10541023 10471010 .....q.c.T.#.G..
0000850: 105a1022 10781004 000001ba 44000404 .Z.".x......D...
[...]
001a850: 84e015f9 24c26e47 000001ba 44000c66 ....$.nG....D..f
001a860: 240101d1 d3faffff 000001bd 006e8480 $............n..
001a870: 07210001 0001ffff 69747630 00800000 .!......itv0....
001a880: 02000000 04808066 1082107f 1080107e .......f.......~
001a890: 107c107f 107b1081 107d1080 107f107f .|...{...}......
001a8a0: 107f1080 10801082 10831081 10831004 ................
001a8b0: 85027110 86107f10 85107e10 82107d10 ..q.......~...}.
001a8c0: 7f107f10 81107f10 83107f10 83107f10 ................
001a8d0: 84107f10 84107e10 82100000 000001ba ......~.........
[...]
00210d0: 03db2840 76591671 c3eb4ec1 000001ba ..(@vY.q..N.....
00210e0: 44000c66 240101d1 d3faffff 000001bd D..f$...........
00210f0: 006e8480 07210001 0001ffff 69747630 .n...!......itv0
0021100: 00800000 02000000 04808066 107f1076 ...........f...v
0021110: 107c107d 107f1082 10801080 10811081 .|.}............
0021120: 108f109e 1fa810db e7b610f0 10a910d8 ................
0021130: 10911004 20206a10 83108110 83107f10 .... j.........
0021140: 83107e10 81107d10 7d107c10 7c107d10 ..~...}.}.|.|.}.
0021150: 7d107f10 7d108110 7d108210 7e100000 }...}...}...~...
(Ignore the PTS of 0 in the MPEG-2 Private Stream 1 PES header, I know
about that.)
Or maybe it's that the linemasks are written to the file as little
endian, when the rest of the Program Pack and Private Stream 1 Packet
are written big-endian or bytewise.
So I guess should be reading the linemasks as 0x00008000 (line 6+15 =
21) and 0x00000002 (line 6+(32-18)+1 = 21).
Should the linemask[] values be specified as little endian in the output
stream?
MythTV has this odd input method for the linemask[] values:
void AvFormatDecoder::ProcessVBIDataPacket(
const AVStream *stream, const AVPacket *pkt)
{
(void) stream;
const uint8_t *buf = pkt->data;
uint64_t linemask = 0;
unsigned long long utc = lastccptsu;
// [i]tv0 means there is a linemask
// [I]TV0 means there is no linemask and all lines are present
if ((buf[0]=='t') && (buf[1]=='v') && (buf[2] == '0'))
{
/// TODO this is almost certainly not endian safe....
memcpy(&linemask, buf + 3, 8);
buf += 11;
}
else if ((buf[0]=='T') && (buf[1]=='V') && (buf[2] == '0'))
{
linemask = 0xffffffffffffffffLL;
buf += 3;
}
[...]
So if we say in the spec the linemask[] values must be little endian,
MythTV will continue to work on little endian machines (I think).
Regards,
Andy
> I think that when this goes in, then README.vbi can be
> removed.
>
> Regards,
>
> Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
