|
List Info Thread: Re: how real-world H.323 applications deal with video capabilities
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: how real-world H.323 applications deal with video capabilities |
|
List Info Thread: Re: how real-world H.323 applications deal with video capabilities
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
packetizer.com> wrote:
> Hannes
>
> I have checked in the ability to notify the plugin of
the proposed maximum
> frame size into the OpenH323 plugins branch. This
should allow, as you
> suggest to have 1 capability that can do all frame
sizes and be notified by
> the stack the maximum framesize to use so it can set
the appropriate
> profile/level etc to be used.
>
> To work
> In Implementers Endpoint
> AddAllCapabilities(0,0,"*");
> SetVideoFrameSize(H323Capability::cifMPI);
>
> This will remove existing "*-"
named capabilities that don't
> match "*-CIF" in the capablity list and send
a message via the
> "set_codec_options" message to the Plugin
Video Codec to set the approprite
> framesize string and then rereads the default settings
from the plugin to
> re-initialise the stack.
>
> With respect to generic plugins, I think this is the
way to go. I think we
> still have to finalise generic capability
mode/parameter matching issue.
>
> The actual frame size transmitted is the converted size
out of the video
> Input device and I think the way the image is displayed
in terms of
> centering, scaling etc should be left up to the
implementers Video Output
> device. In OpenH323 this can be done via the
implementers
> H323EndPoint::OpenVideoChannel() of cause in Opal this
is different.
>
> I think this is what you are after.
Simon, I am very impressed with the amount of work you have
done. I
really do not wish to cause any problems, but I'd like to
point out a
limitation with the approach you have taken.
The problem with the approach described above is that the
stack is
setting codec restrictions on a global basis, rather than on
a per-call
basis. Consider what would happen if two calls tried
simultaneously to
set the frame sizes to different values ? This could easily
happen in an
application such as OpenMCU which obviously maintains
multiple
simultaneous calls. It is likely that endpoints will use
different
frames sizes, for example talking to one code using H.263
CIF while
talking to another using H.263 QCIF.
>From a design point of view, the plugins are intended to
encapsulate the
simple functionality of converting between two media types.
The
capabilities they export should express the realm of media
types they
support. Any filtering of these media types should be done
outside the
plugins by whatever application is using them, and not by
setting global
state within the plugin object instances.
There is also the issue of managing the capability tables.
After each
call to SetMaxFrameSize, the plugin will need to free up the
memory used
by the old capability tables to avoid leaking memory over
time. However,
there may well be calls in progress using the old capability
tables,
which will promptly crash. Again, this problem becomes
obvious when the
issue of handling multiple simultaneous calls is
considered.
So, enough of the problems - what is the solution?
As I understand it, the code changes allow the stack to
offer a subset
of the video frames sizes actually supported by a plugin. I
completely
agree that this is a very useful concept that needs to be
available.
However, I propose that this is provided in a different
way.
We add a PString object to the H323Endpoint class that sets
the maximum
frame size that calls are allowed to use. This string should
be
expressed as a frame sizes such as "176x144" and
we also define a set of
useful synonyms such as "QCIF" etc
This PString is copied by the H323Connection constructor
into the
H323Connection object, so each connection has it's own
possible frame
size maximum. There are many call attributes that are
managed in this
way.
The video size is then used when the H323Connection
constructs the list
of outgoing capabilities or when it is matching incoming
capabilities.
This approach would also work with OPAL which uses the SIP
protocol.
I'd be happy to try this approach in OPAL first, which
should help with
the OpenH323 implementation.
I look forward to hearing responses from interested parties
Craig
------------------------------------------------------------
-----------
Craig Southeren Post Increment – VoIP Consulting
and Software
craigs