[pvrusb2] Misplaced Filter-Controls?

[Mike Isely]

On Thu, 19 Feb 2009, Carsten Meier wrote:

> Hi Mike,
> 
> I'm currently having a little bit of headache with the filter-controls.
> Aren't they misplaced in the MPEG-class? I think they should actually go
> to the user-controls. The background is the following:
> 
> I want to present the user a menu where controls of the user-class can
> be edited on a per-channel-basis. (because each channel has it's own
> understanding of black-level etc.) Some channels are more distored than
> others, so here I like to increase the temporal-filter (currently in
> textual config-files). But this won't work for UI-dialogs, because the
> MPEG-controls should only be visible in an encoder-profiles-dialog
> which is independant of channels (for bitrate, GOP-size, etc)
> 
> I also think that the filter-controls are better suited to the
> user-class, because they affect the image and not the encoding process
> as such.
> 
> Changing it would be a little bit difficult, because the controls are
> defined in the v4l-header. But I think it was wrong to put them there
> anyway, as they are private controls.
> 
> What do you think?

Carsten:

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

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.

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8