Bluecherry solo6x10 driver

I have studied ISO-IEC-14496-2, Second edition, 2001-12-01, 6.2.3 "Video Object Layer".
According to this document the vol header given by the driver (in the driver it is called vid_vop_header) has some errors:

1) The last byte of vid_vop_header (0x3e) should be next_start_code(). But next_start_code()
means one 0-Bit, then marker-Bits(1) until the next byte boundary. Therefore this byte must be 0x3f,
not 0x3e.

2) fps/interval are written in the fields vop_time_increment_resolution/fixed_vop_time_increment
in the vol header. The first 4 bits vop_time_increment_resolution have not been written by the driver, resulting in an erroneous value of vop_time_increment_resolution when using PAL. The consequence was that mplayer detected wrong fps. The fix simply is: p²¹ = (p²¹ & 0xf0) | (fps >> 12);

3) It is required that vop_time_increment_resolution is in the range 16384-32767, so that fixed_vop_time_increment is represented with 15 bits. So it is desireable to keep vop_time_increment_resolution fixed to the value of 30000. This is also assumed by the Solo6010 chip,
because the chip can be configured to give vop_time_increment values of 500,600,1000,1200 only.
With vop_time_increment_resolution=30000 this gives the usual frequencies 60Hz,50Hz,30Hz,25Hz for frame/field mode in PAL/NTSC.

These changes are summarized in the following patch:

==== solo6010-v4l2-enc.c.orig - solo6010-v4l2-enc.c ====
56c56,59
< 0x1f, 0x4c, 0x58, 0x10, 0x78, 0x51, 0x18, 0x3e,
---

0x1f, 0x4c, 0x58, 0x10, 0x78, 0x51, 0x18,
// fix: 0x3f means next_start_code(),
// 0x3e is wrong because one marker bit is missing
0x3f,

415,416c418,420
< u16 fps = solo_dev->fps * 1000;
< u16 interval = solo_enc->interval * 1000;
---

const u16 factor = 30000 / solo_dev->fps;
const u16 fps = 30000;
const u16 interval = solo_enc->interval * factor;

426a431

p²¹ = (p²¹ & 0xf0) | (fps >> 12);