[libavg-devel] video4Linux2 on libavg: some design choices

[OXullo Intersecans]

Il giorno 30/giu/07, alle ore 19:32, Ulrich von Zadow ha scritto:

> Hi,

nice to read ya!

> I just checked out the branch here and got it to work with a firewire
> camera again with minimal changes. Good work!

wonderful!

> I've checked in the changes to the branch (some additional #ifdefs to
> avoid unresolved externals when V4L isn't present on the system), and
> I'm attaching a diff as well so you can see what's going on.

yep, a missed shot, thanks

>> you'll see a tokenizer on V4LCamera.cpp code to split up these two
>> fields. Furthermore another tokenization between width and size  
>> seems to
>> be due
>
> It's really a minor issue, but for firewire cameras, there is a number
> of fixed modes. The dimensions and the pixel format of each mode is  
> set
> by the standard for all 'normal' modes, so the string is just  
> converted
> to a mode constant directly. With V4L, you need a tokenizer etc.,  
> and I
> sort of dislike adding another level of parsing when we've got  
> xml ;-).
>
> But it's not very important, so we'll leave it like it is.

ah, I didn't catch, thinking that it was more important to retain,  
where possible, the same fields&types
Well, we're going to add grab size parsing (the latest big lacking  
feature of our part): being in complete agreement on what you're  
pointing out, we can manage to use additional XML attributes to drive  
size and color space data.

>>>> We split this method in two: addFWTracker(device, mode) and
>>>> addV4LTracker(device, mode, channel). This seems not to be the  
>>>> best way,
>>>> but was the fastest, waiting for some Uli's advices basing on  
>>>> his best
>>>> flavours.
>>>
>>> Yeah, that doesn't seem like we want it to stay that way. I'll  
>>> look at
>>> the code over the weekend.
>>
>> waiting for your suggestions!
>
> Can't we just add a <source> node to .avgtrackerrc and an appropriate
> field to TrackerConfig? Then we only have to look at that field in
> addTracker and instantiate the correct camera?

sounds good

> I might be able to do that tomorrow, but I can't really promise  
> much at
> the moment.

we can try a draft solution (we have time to lend to libavg this  
evening)

>> you'll notice that if you instantiate a CameraNode you'll receive a
>> non-fatal error of a setFeature() called before device  
>> initialization.
>> Will we have to proxy feature set requests and throw them only at  
>> device
>> initialization time?
>
> libavg usually attempts to honor feature requests even if the
> appropriate resource is not yet available. This works, for instance,
> with video.play() or seek() called before AVGPlayer.play(). (Or if it
> doesn't, that's a bug and I'll try to fix it). So yes, it would be  
> great
> if you could save feature requests and apply them when the camera
> becomes available.

that has been added as TODO, we'll manage it ASAP

> Ah, and I think I saw some tab characters in the source code. Could  
> you
> clean those up?

sure

> I'll see if I can check in an example .avgtrackerrc tomorrow as well.

waiting for it!

byez

--
OXullo Intersecans

0 2 L > Outside Standing Level
http://www.02L.net