Hi Mike, Am Sun, 22 Feb 2009 19:13:07 -0600 (CST) schrieb Mike Isely <[email protected]>:
> 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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
