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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
