[pvrusb2] Misplaced Filter-Controls?

Carsten Meier cm at trexity.de
Wed Feb 25 05:04:43 CST 2009


Hi Mike,

Am Sun, 22 Feb 2009 19:13:07 -0600 (CST)
schrieb Mike Isely <isely at isely.net>:

> Sorry about the delay.  I have been out of town and otherwise
> distracted on other stuff.  Regarding your question..
> 

No problem. I'm currenty also having some trouble with my back. (Hope
you guys out there have a proper chair for sitting in front of the
computer and also some outdoor-activity. Otherwise you'll earn a lot of
pain...)

> The filter controls you are looking at *are* actually part of the
> mpeg encoder.  The same module in v4l-dvb which deals with the
> encoder deals with these controls.
> 
> I do understand what you are saying, but it is this way because (a)
> the only thing that implements these controls are devices with an
> mpeg encoder, and (b) all of those filter controls weren't even
> conceived of in v4l until drivers came along that supported the
> encoder.  Thus they got added later and are not a part of the "core"
> set of video capture controls.
> 
> This is one case where the implementation is affecting (somewhat) the 
> interface.  I generally don't like that sort of situation in
> principle. I am a big proponent of careful partitioning of
> implementation apart from interface (probably, some would say, to a
> fault).  But you are also seeing an effect of history within the V4L
> spec itself, since these controls did not even come into anyone's
> thought process until the mpeg encoder chip showed up.
> 
> As for the mpeg contorls being independent of channels, that's not my 
> call.  As far as a driver like pvrusb2 is concerned it's ALL
> independent of channel mappings.  The 'illusion' that certain things
> are specific to a channel and certain things are not is something
> completely up to the app (e.g. mythtv).  In cases like that, the app
> is going to be storing the settings on your behalf in a per-channel
> app-specific data structure and swapping them in/out as you change
> channels.  Filter settings should definitely be a per-channel thing
> since the optimal settings are going to depend on the S/N ratio of
> the signal.  The fact that they might be associated with mpeg
> settings might be unfortunate, but there's no reason why an app
> couldn't just swap in/out just the filter settings. The driver after
> all is not going to care how the app chooses when/if to adjust the
> various controls.
> 

I'm not asking you to change the driver just to match my app... :) The
channel- vs. global-profile just shows up the problem here. Of course I
can hard-code the specific filters to the channels-profile but this
would somehow defeat the generic control interface of v4l2 and lead to a
solution where additional features of other devices aren't supported
(like the non-existent filter-support in mythtv)

Another test-case is probably the forthcoming raw-image-data support.
If the pvrusb2 is used like a budget-card w/o an encoder by any TV-app,
it would typically not show any MPEG-controls but user-controls. Here
again, filters are completely inaccessible.

But I'm still unsure about this... When thinking about it I find
reasons both to put it in the MPEG- and the user-class :/

However, don't bother. If you have a nice idea, let me know. :)

Cheers,
Carsten


More information about the pvrusb2 mailing list