Simon Horne wrote:
> I'd like to chime in here and say I have to agree with hannes here. This
> something I raised earlier when I ported the video plugins to openH323.
>
> If I want to send say VGA 640x480 or HD 1080x720 video because the HDTV I
> am sending to only supports these two sizes? how can it be done? The only
> way I can see in Opal is to set the capability max size to either 4CIF for
> VGA or 16CIF for HD and have the capture device set to the required size
> VGA or HD. What if the capture device cannot be set to this size? What if
> the output image from the device needs to be scaled to fit a particular
> frame size?.
>
> In the same vain, what if you are doing application sharing H.239 and you
> need to scale down the application capture window (which could be any size)
> to fit into a 4CIF maximum frame size .
Whether you need to do this, or not, depends on what codec and how the
capabilities are negotiated. Here is how it is done for each protocol:
1) If the H.323 protocol is being used:
a) For H.261 the media will be exchanged using one of the frame sizes
defines in the H.245 specifications, which is CIF or QCIF. See
H261VideoCapability in the H.245 ASN definitions.
b) For H.263 codecs, the media will be exchanged using one of the
frame sizes defines in the H.245 specifications SQCIF, QCIF, CIF, CIF4,
or CIF16. See H263VideoCapability in the H.245 ASN definitions.
c) For H.263+ codecs, the frames size can be any multiple of 4
pixels. See CustomPictureFormat in the H.245 ASN definitions.
d) For H.264 and MPEG4, the frame sizes are constrained by the
profile definitions. Wikipedia has a good table of these - see
http://en.wikipedia.org/wiki/H.264
2) If the SIP protocol is being used:
a) For H.261 the media will be exchanged using one of the frame sizes
defines in the RFC 4587, i.e. either CIF or QCIF.
b) For different flavours of H.263 codecs, you need to understand the
various combinations available in RFC 4629.
c) SIP also uses profiles for MPEG4 and H.264
All of this only applies to the media on the wire. OPAL does lots of
additional work internally to prevent the codecs and devices from having
to worry about most of this.
When a media stream is opened, OPAL will tell the capture/display device
what frame size has been negotiated by the wire protocol. The
capture/display device can then either resize it's media, or it can
allow OPAL to insert code to do the resizing of the media instead.
All of this is done automatically if you are using plugin codecs.
> In the openH323 port this was not a problem as there was the legacy
> SetVideoFrameSize() function in the endpoint OpenVideoChannel function
> which was exposed so the user could directly set the actual frame size to
> send in the RTP stream and would automatically scaled the input (capture)
> device image to that size. I don't think this is implemented in Opal.
It's implemented completely differently in a way that will work with
both SIP and OpenH323.
> From what I have seen a lot of work has been done in Opal to allow the
> passing of remote generic parameters (received from the remote party) to
> the plug in codec, this has been an issue I noted some months back and I
> think this is what Hannes is referring to. If this is now working properly?
> the easiest way to define your own generic or non-standard capability is to
> define a plug in capability with either PluginCodec_H323Codec_nonStandard
> or PluginCodec_H323Codec_generic in the h323CapabilityType in the plugin
> definition. This should automatically create a non-standard or generic
> capability. I noticed that both the MPEG4 and H.264 plugins are not set
> correctly (as they define PluginCodec_H323VideoCodec_h263 when infact they
> should be PluginCodec_H323Codec_generic) I will eventually get around to
> fixing this if someone doesn't get to it first.
We will get around to fixing it. We're making sure all of the internal
infrastructure is working correctly first. Unlike OpenH323, OPAL has to
work with both SIP and H.323 - that's a significant complication
Craig
-----------------------------------------------------------------------
Craig Southeren Post Increment – VoIP Consulting and Software
craigs@xxxxxxxxxxxxxxxxxxxx www.postincrement.com.au
Phone: +61 243654666 ICQ: #86852844
Fax: +61 243656905 MSN: craig_southeren@xxxxxxxxxxx
Mobile: +61 417231046 Jabber: craigs@xxxxxxxxxx
"It takes a man to suffer ignorance and smile.
Be yourself, no matter what they say." Sting
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openh323-devel mailing list
Openh323-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openh323-devel
[Open H.323]
[IETF SIP]
[Gnu Gatekeeper]
[Asterisk PBX]
[Fedora Linux]
[Gimp]
[Yosemite News]
[Yosemite Photos]
[Yosemite Campsites]
[ISDN Cause Codes]
