[pvrusb2] initialization of video_gop_size

[Hans Verkuil]

On Monday 23 June 2008 04:40:28 Mike Isely wrote:
> On Sun, 22 Jun 2008, Hans Verkuil wrote:
> > The ivtv and cx18 drivers set it during driver initialization
> > (after cx2341x_fill_defaults() is called):
> >
> >   itv->params.video_gop_size = itv->is_60hz ? 15 : 12;
> >
> > But I notice that none of the other drivers using cx2341x do so.
> > I've CCed the cx88-blackbird and cx23885-417 maintainers as well so
> > that they can update their drivers, or at the very least are aware
> > of this.
> >
> > The use of a GOP size of 12 is (as I understand it) legal but
> > non-standard. A GOP size of 15 gives you two I-frames per second,
> > similar to the GOP size of 12 for 25 fps formats.
> >
> > An additional problem I discovered is that the gop_size isn't
> > updated after you change from e.g. PAL to NTSC or vice versa. I'm
> > thinking that it might be better to have it set to a default of 0,
> > meaning 'use the current TV standard to decide on the appropriate
> > GOP size'. But this requires a minor API change.
>
> Without having looked at the cx2341x module code (I have been far too
> buried in another project right now), could a driver force it to
> update on video standard change by forcing a complete
> reinitialization of the encoder?  Changing the video standard is not
> something one is going to routinely do and when it happens I have to
> assume that it is going to be disruptive regardless - since
> presumably one of the choices (pre- or post-) probably wasn't correct
> to begin with.  So just reinitializing everything in this case should
> not be out of bounds.

I've thought about that, but in principle the driver should not change 
controls. And this is actually the only MPEG control that's affected by 
a standard change.

Perhaps a simple heuristic might also work: e.g. if the gop_size was 12 
and the standard was NTSC and you switch to PAL, then silently change 
the gop_size to 15. Otherwise keep the old (apparently non-standard) 
value.

But that's rather a hack I think.

Regards,

	Hans

> > I'll look at this tomorrow and if I haven't come up with a better
> > idea I'll propose such a change.
> >
> > Small fixes to bring cx88, cx23885 and pvrusb2 in line with
> > ivtv/cx18 should most likely be OK to get into 2.6.26, but an API
> > change is definitely 2.6.27.
>
> Agree.
>
>   -Mike