From: Antonio G. C. <aga...@de...> - 2008-09-09 08:17:18
|
Brendan McCane escribió: > 2008/9/9 Matt Leotta <mat...@gm...>: > >> Antonio, thanks for the code! I've already checked in your additions >> to vidl2_convert.cxx since they are more broadly useful. I can check >> your code in as is, but I don't have time to maintain it or any >> experience with video 4 linux to test it. I think either another VXL >> maintainer needs to try it out and then help maintain it, or we'll >> need you to become VXL maintainer and do it yourself. Are you >> interested in becoming a VXL maintainer? >> >> Brendan, as the other V4L expert, are you or is anyone in your group >> interested in picking this up? Either as is or as a starting point to >> upgrade the current V4L code. >> > > Hi Matt/Brendan, I am not a v4l2 expert. I have written this code reading other programs but not studying the problem in depth. Probably, an v4l2 expert could improve this code. Anyway, although I do not have much time, I can read comments and try to maintain this code. > Hi Matt, > > Ideally I would, but I'm absolutely snowed at the moment and am > unlikely to get to it in the foreseeable future. > > I do think that it should follow the style of the the other vidl > streams, that is, use a parameters class - that will make it simpler > writing cross-platform code. > I was thinking about a new design for controls because, as indicated in v4l2 specification, different devices have different controls available, and furthermore, the range of possible values vary from device to device. Then, if I write a parameters class, which is te range of values? default value? or even, which are the controls associated with current input? Too many questions, then I delayed the design thinking that the best solution would be a set of classes that provide a better control of the device. For example, it could be possible to write an program which includes a dynamic set of controls obtained from the driver. Well, as you see, I have not yet written anything about controls. ;) > >> I'll hold off on checking in the rest of the code for now, but it >> looks alright to me. The design is a little different from some of >> the other live streams. It uses a "device" class which is configured >> and then passed to an istream instead of a parameters class. The >> device class holds parameters and does most of the work while the >> istream mostly a wrapper around the device. We don't really have a >> standard on initializing with parameters yet, but maybe we should. >> There was talk a while back about reading parameters from files using >> XML or some standard file format... >> That's right. The device class appears because a device is very different from a istream. These are two different objects and it is not easy to create a single class to handle a v4l2_istream including all power from istream and devices. I thought that a better design should separate the two concepts such that it would be easier to maintain both classes. Anyway, it could be interesting to think about a solution in which a parameter class is used, perhaps including the most important controls as a wrapper around the device controls... ¿? Antonio. |