[libavg-devel] Re: V4L2-libAVG integration

[OXullo Intersecans]

Il giorno 10/giu/07, alle ore 21:57, Ulrich von Zadow ha scritto:

> OXullo Intersecans schrieb:
>> First of all: do you prefer that these questions belong to mailing  
>> list
>> and not only to a private thread?
>
> I've cc'd the list :-).

Good. I just subscribed it.
>
>> 1. Workspace
>> We reaped a checkout (rev 2095) and imported the whole tree to our  
>> svn
>> repository. We are supposed to work there and at last we'll give  
>> you a
>> bunch of diffs for a manual and assisted integration in your head.
>> We'll keep your side updated at the latest revision.
>
> If you want to do that, that's ok, but I can also give you write  
> access
> to the libavg repository. You could just do all development on a  
> branch.
> That would probably make updating and merging a lot easier. The only
> condition would be that you send me a diff before you merge to the  
> trunk.
>
> We could also merge more often with this setup, so I can check if  
> any of
> your changes break Firewire support. The smaller the patches, the
> better.

that's surely the best way: we'll stay better on track and we're less  
prone to conflicts.
We'll wait your svn copy and write access.

Ben Lau: so, please wait for the settlement, branching is the best  
solution for all!

> You probably don't have a FW camera, right?

nope (indeed, we have a DV camera which is not IDC compliant, so no  
camera). However, if you need that we should take in account the  
reliability of FW code after our intervention, we'll buy one (your  
Fire-I by Unibrain, for example).

>>> player/CameraNode.cpp, imaging/CameraUtils.cpp: we'll manage  
>>> defines,
>> ORring V4L2 availability and integrating some specific-level code
>
> There shouldn't really be many #ifdefs nessesary in these files. In
> CameraNode.cpp, the #ifdefs in the constructors need to stay, but the
> rest... I've just checked in a new version that shouldn't need any  
> others.

We saw the diff. That's ok

> And CameraUtils should probably be renamed FWCameraUtils. It's only
> there to hide away differences between different versions of  
> libdc1394.

We noticed it. And sounds really better, so each camera technology  
could have its specific support functions.
However: for the encapsulation sake, isn't better to put all these  
functions in the specific camera class?
In this way CameraUtils would disappear and all the methods would be  
covered by the class (if some methods can be generalized, they can be  
put on ICamera)

>> PS: why only CameraUtils.(h | cpp) files are subjected to ENABLE_1394
>> | ENABLE_1394_2 defines and Camera.(h | cpp) are not? Is the only  
>> reason
>> the fact that Camera would be a dummy device, still instantiable?  
>> (eg:
>> Player.cpp:327)
>
> Hm - I don't think there's a good reason Camera.(h|cpp) is still
> compiled when there's no camera support at all. Maybe instantiate
> DummyCamera instead and issue a warning when there's no camera  
> support?
> Then we would always have a camera object and get rid of a lot of  
> ifs in
> CameraNode as well :-).

It still remains your FakeCamera, which is ever available, isn't?
That would be the perfect dummy..

> Anyway, feel free to clean up that part of the code, it's not  
> really ok
> the way it is. (In a separate patch, if that's easy for you.)

ok, we'll try to do as best as we can :)

>> 4. Inheritances
>> As you pointed out, Camera (actual main interface to your firewire
>> camera) would be changed to FWCamera.
>> Both FWCamera and V4LCamera are ICamera derived classes.
>
> Perfect :-). If any code moves to ICamera, that class would need to be
> renamed to Camera.

Camera will still remain the ancestor class for all camera, right?

>> X. Various questions (forgive_naiveness_please!)
>>> At compile time user can get or not get V4L code integration, using
>> 'enable-v4l2' configure parameter: we should decide how user can  
>> switch
>> between firewire and v4l camera (runtime). An example for CameraNode:
>> avg file camera node can provide a specific attribute like 'fw' or
>> 'v4l'. But there's also TrackerEventSource * Player::addTracker,  
>> how to
>> treat this latter?
>
> For CameraNode: <camera source="firewire|video4linux|dummy".../>
>
> For the tracker: This belongs in .avgtrackerrc:
>
>   <camera>
>     <source value="firewire"/>
>     ...
>   </camera>

good.

>>> How frame per second setting is used, looking that image dequeue
>> timing is handled by TrackerThread and CameraNode (doFrame, in the
>> latter case?) ? Maybe firewire camera hasn't a timecode setting at  
>> all,
>> in the contrary of a V4L video feed which comes usually from an  
>> analogue
>> device.
>
> The fps is a configuration setting of FW cameras (Camera.cpp, 144).

so, nothing really related to doFrame() granularity, which usually is  
linked to screen refresh and cpu/gpu power

>>> According to our actual knowledge of libAVG, camera video feed  
>>> can be
>> used as avg node (via CameraNode, instantiated by the avg file parser
>> Player::loadFile) or as a tracker using Player::addTracker, right?
>
> Yes, and you can use src/test/TestCamera.py to check if camera support
> is still working. It should never crash, with or without V4L or  
> Firewire
> camera :-).

ok. we're on it, just waiting for svn branching and write access  
credential.
byez!

--
OXullo Intersecans

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