[h323plus] [Opalvoip-devel] Custom Video Frame Size

Hannes Friederich hannesf at ee.ethz.ch
Tue Nov 6 03:21:22 EST 2007


Simon,


On 06.11.2007, at 03:55, Simon Horne wrote:

>
> I have CC'd this to the h323plus list.
>
> Robert
>
> Getting back to the initial question. I want to move forward with H. 
> 239
> support in h323plus so can I remove the fixed frame size  
> constraints from
> the video plugins so the project can move forward or if that's not
> recommended then, as I don't want to have different versions of the  
> video
> plugins that break interoperability, can I put in a compiler  
> directive to
> get us out of a pickle? Once these opal architectural glitches are  
> resolved
> then the directive can be removed.
>
> I really am confused on the codec issues, and the discrete video  
> sizes with
> H.261/H.263 and the generic capabilities etc. The way this is done in
> H323plus is to detect the capabilities of the video device at  
> application
> startup via the changes I made in the ptlib videodevice factory  
> which allows
> the device capability list to be exposed without instantaneousing the
> device. You use the device capabilities list to determine the  
> maximum frame
> size available for the device so in this way you can detect and  
> support HD
> webcams etc. There is a H323Endpoint function that then goes  
> through and
> removes all the capabilities unsupported for that particular  
> webcam. Easy!
> On the OpenVideoChannel function callback the user can then set the  
> frame
> size and fps on the wire. This sets the header height/width fields  
> of the
> YUV420 frame which then goes back into the plugin codec to resize  
> the codec.
> This is how it used to work in OpenH323 and it works just fine. The  
> problem
> you refer to is, I guess, an open Opal issue perhaps?.

Just don't forget that newer codecs such as H.264 no longer define  
explicit frame size, but rather profile/levels, which actually  
defines a range of sizes. So, it is no longer that easy to just  
remove particular capabilities, as a particular profile/level may  
mean higher resolution/lower framerate or vice versa. Also, I don't  
know how flexible existing H.239 systems are in terms of supported  
frame sizes. I guess it will be safest if you stick to well-known  
discrete resolutions such as 4CIF / 16 CIF.
>
> The "Extended Video Channel" is different to Hannes work in Opal.
> ExtendedVideoCapability is a type of Video capability which contains a
> subset of capabilites designed to be used for the likes of H.239.  
> There is a
> flag I have added to the codec definitions in the video plugins  
> which marks
> the codecs to be loaded into this subset group. Hannes's work is on  
> having
> multiple primary video windows which is not related in H.239. The  
> secondary
> or "Extended" video capability is opened via a function with sends  
> a H.245
> OLC and returns a channel number which you can then use to close the
> channel. Since each channel has a unique channel number, multiple  
> video
> windows can be opened/closed on the fly.  There is a working  
> example of this
> in simple in applications directory in the H323plus CVS. This type of
> concept opens the way to develop more advanced concepts like  
> telepresence
> where you can allocate 3 or more different video input for each  
> secondary
> channel. Since all this is done on a secondary video capability,  
> existing
> interoperability on the primary video is ensured and no existing
> architectural changes in h323plus are required.

I think I have to explain more in-detail how the MediaType stuff  
actually works, as it really was intended to support H.239. A  
OpalEndpoint does not primarily know about H.239, as this is H.323  
specific stuff. To Opal, this is just another video stream. However,  
this video stream has different characteristics as the primary video  
stream, since - as you mentioned - the capabilities used are  
different ones. So, it needs different OpalMediaFormat definitions.  
The OpalMediaType class introduced is just an extension to the  
sessionID parameter used so far. First, statically assigning session  
IDs others than 1,2,3 is not according to H.245, as these session IDs  
have to be assigned by the H.245 master. The MediaType is just a  
description of the media type (video, audio, application, etc) along  
with a label (e.g. DefaultVideo, SecondaryVideo)
So far, the existing code explicitely tries to open a logical channel  
for DefaultAudioSessionID, DefaultVideoSessionID,  
DefaultDataSessionID. If you want to use other data streams (e.g. H. 
224/H.281), you need to add #ifdef protected code at various places,  
which is rather painful. My changes simply try to open logical  
channels for each MediaType available, and the MediaTypeList is  
dynamically managed. I don't see why H.239 shouldn't fit into this  
concept.

Hannes




More information about the h323plus mailing list