Re: [GnomeMeeting-devel-list] Re: [OpenH323]VIDEO ISSUE SOLVED:Reg Latest Openh323 compilation in Linux



On Thu, 02 Sep 2004 14:15:25 +0200
Kilian Krause <kk verfaction de> wrote:

> > If GM wants their own forked set of plugins, then I don't need to get
> > involved. So I'll not bother discussing that any further - if the GM
> > team decides to follow this path then I guess I will see the new plugin
> > code eventually.
> 
> nope, don't take that "we will fork pwlib" too serious. It's just an
> expression of how much Damien loves his baby. ;)

Even so, my response is the same: either fork the code and do what you
like, or be prepared to discuss and perhaps defend your requirements as
part of a community and accept that you may not alway get what you want.
After five years of this, I'm tired of the constant threats and demands.

> > I don't understand the comments indicating that OpenH323 is somehow
> > stopping this from working. If that was true, then how does GM work?
> 
> Well, problem is not with opening a device that was shown in the
> listing. But aparently if you list "OV511 Cam", but request
> "/dev/video1", that'd fail. So if the listing would have a "/dev/video1"
> you could open that one, but couldn't open the "OV511 Cam" anymore. (Yet
> this limitation is not in pwlib, but in the openh323 layer according to
> Damien) 

OpenH323 handles video devices very differently from audio devices.

Whereas an audio device can be used with the stack simply by providing the
name of the device, the video device can only be attached by the
application in the overriden H323EndPoint::OpenVideoChannel function.
The stack never sees the name of video device, so it has no way of
enforcing any policy on the naming of devices. 

So I regret to say that I do not see how Damien could be correct. Feel
free to prove me wrong.

In any case, I think it is perfectly reasonable that a device cannot be
opened except by using a name that is advertised as being legal for that
device. 

Because I would still like to see a sensible implementation rather than
the existing mess, I'll have one more try at describing what I would
like to see.

  1) A function is called to get a list of the available devices. This
function returns entries like "/dev/video0", /dev/video1" or whatever
the host device name is. Note that on Windows or BSD or MacOSX these
could be basically any kind of string.

  2) Given a device name, another function can be called to get
interesting information about that device, including the "friendly" name,
or other attributes such as frames/sec, resolution etc etc

  3) The application then opens the device using the device name. Under
no circumstances should it use the the "friendly" name, because this
name may not exist, or may not uniquely identify the device

  The application should definitely display the "friendly" name (if it
exists) for each device in addition to the device name, as this will
help the user ensure they are selecting the right device. But using this
name for the internal handle does not make sense at all, and the current
code is currently jumping through hoops trying to make this work (and
demonstrably failing)

  Given that this is how most systems work (including Linux and Windows)
it sort of makes sense that we reflect this in PWLib as this would be
less work than anything else. But I lost hope of a sensible result to
this issue several emails ago - right now I would settle for just a way
to move forward.

  Craig
  
-----------------------------------------------------------------------
 Craig Southeren      craigs postincrement com / craigs voxgratia org

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243673140      MSN: craig_southeren hotmail com
 Mobile: +61 417231046   Jabber: craigs jabber voxgratia org

 Post Increment - Consulting & Services    http://www.postincrement.com
 Vox Gratia - The Open Source VoIP portal  http://www.voxgratia.org
 Raving Of A Strange Mind - the VoIP blog  http://www.southeren.com/blog




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]