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

[OXullo Intersecans]

Il giorno 25/giu/07, alle ore 17:21, Ulrich von Zadow ha scritto:

> Hi,

dearest,
that's good to hear you again!

> looks like everything is coming along very well :-).

yep! the port is almost done, we should test it.
Ben, have you got some feedback for us?

> Do you think you can check a version that works and doesn't break
> anything old into subversion before the weekend? Then I'll try it  
> here,
> maybe fix firewire if that's necessary and see if I can commit the  
> stuff
> that you've done to trunk.

We worked mostly in a independent way, Camera code *should* work, but  
we have no such IDC camera to make testing.
Unit tests work flawlessy, the only relevant bug was pointed out by  
Ben Lau and a workaround has been applied, waiting to a better  
solution (see below).
Our latest commit is someway in line with the latest additions  
(merged till rev2131)


>> mode: WxH_PF where PF can be: RGB, MONO8, YUV422 (the same as  
>> firewire
>> camera)
>> channel: video mux selector, for example, a bt878 pci board has:
>> 0=tuner, 1=composite, 2=svideo
>> source: 'v4l' instead of 'firewire' is the magic switch
>
> Looks good. The 'mode' attribute seems a bit strange to me in the v2l
> case, but I don't have any good idea how to change it.

sure? we followed your traces!
<width>x<height>_<pixelformat>

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

>> 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!

>> At this time, V4LCamera does not honour tune-in attributes, therefore
>> the <camera> node of the rc is simply ignored.
>
> Are you going to implement that? If not, we should throw an error  
> if the
> camera node is there.

gone with the last two commits
unsupported features (they may vary) are simply ignored with a WARNING
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?

For now, features are set in real-time and with no further values  
storaging.

byez!

--
OXullo Intersecans

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