On 7. Aug 2007, at 03:52, Craig Southeren wrote:
> Hannes Friederich wrote:
>> Hi,
>> One problem is that currently, the media options aren't propagated
>> to the other endpoint, which could inspect them to signal the
>> correct media format description to the remote endpoint.
>
> I'm not sure what this means.
It may have changed meanwhile, but I've seen the following problem:
XMeeting is organized like a gateway. Instead of specifying YUV420P
as a possible media format, it specifies e.g. H.261 directly. So, the
OPAL transcoding system isn't used (for video at least). If I use non-
default media format parameters (e.g. a lower bitrate than the one
specified in the media format constructor), this information isn't
propagated and the other connection always sees the default
parameters. There are good reasons for this behaviour (I don't recall
all details since it's too long since I was working on that), so
there is needed another way to correctly propagate media format
options. Pretty much the same applies here, as I think the signalling
code (be it H.323 or SDP) needs to know which frame sizes, bitrates
etc to use. Using H.263+ or H.264, it is possible to send non-
standard frame sizes, and in case of H.263+ the frame size
possibilities should be signaled as well.
>
> When a connection is made (say) to a H.323 endpoint, the H.323
> connection negotiates the parameters that are used on that side of the
> call. The OpalMediaFormat instances on the media streams for that
> connection will contain the negotiated parameters.
Yes, but which are the parameters to start the negotiation with? If
you want a video codec plugin to be easy useable, it should be
possible to specify beforehand which frame size / bitrate you'd like,
and the plugin should update it's media formats accordingly.
Otherwise everyone that wants to send custom picture sizes needs
either to use the plugin manager API directly or write its own plugin
>
> The "other" side of the OPAL call should not need to see these
> parameters, as it is isolated by the conversion to/from YUV420P (or
> whatever intermediate format is used).
>
> If there is a mismatch between the video formats on the two sides
> of the
> call, OPAL will insert code to resize or recode the video frames as
> necessary. It's not the responsibility of the codecs to "peek" at the
> other side and do strange things on that basis.
>
> One good reason for this is that an OpalCall was always designed as a
> "one to many" relationship, with one "source" stream feeding multiple
> "sink" streams. How would a source stream know what sink stream to
> optimise itself for?
I completely agree that it is not always possible to know which
picture format to use. But it is an unnecessary overhead to let the
video be captured at, say, 640x480 just to be rescaled to 352x288
(CIF). If you can get CIF directly from the camera driver, chances
are high that the code is faster, even if the camera driver has to do
some internal rescaling itself. But I have to admit that I never
really used the OPAL transcoding system / video input, as XMeeting
uses a completely different approach in this area.
>
> I'd welcome further discussion on this topic, especially when Robert
> gets back from his vacation next week :)
>
>> The other problem
>> probably is that the code responsible for signaling the media
>> description (H.323 capabilities or SIP SDP) most probably don't
>> consider non-default values.
>
> This is not a limitation of OPAL or the codecs. The H.323 capability
> specifications for codecs such as baseline H.263 and H.261 do not
> allow
> frame sizes other than standard ones such as QCIF, CIF etc.
>
> MPEG4 or H.263+ may also allow this functionality, but I don't know
> enough about those H.323 capabilities. SIP may also be different.
>
> Thinking about this, there is probably no reason why the
> transcoders themselves could not be modified to accept any legal
> frame size, and leave the enforcement of the CIF/QCIF etc to the
> protocol specific code. This would be an interesting field of
> research for anybody who was interested.
>
>> For problem one, there is a solution in the MediaTypeBranch of
>> OPAL, that might be added to the next stable release of OPAL. It
>> makes sure that custom media format options are correctly
>> propagated to the other connection/endpoint. If you use H.323,
>> you may consider writing a custom H.323 capability for your media
>> format, that correctly reads and signals the media format options.
>
> To address the original question, there are three things you need
> to do if you want add a custom video frame size to OPAL (four if
> you want to support H.323)
>
> 1) You need to create a new OpalMediaFormat that names and
> describes the frame size and format. The following code does that:
>
> class MyMediaFormat : public OpalVideoFormat
> {
> public:
> MyMediaFormat(const PString & name,
> unsigned width,
> unsigned height,
> unsigned rate)
> : OpalVideoFormat(name, // name used for media format
> RTP_DataFrame::DynamicBase,
> // use dynamically allocated
> payload
> PString("x-") + name, // SDP format name
> width, // frame width
> height, // frame height
> rate, // frame rate
> 1000000) // bandwidth (guess)
> { OpalMediaFormatFactory::Register(*this, this); }
>
> ~MyMediaFormat()
> { OpalMediaFormatFactory::Unregister(*this); }
>
> PObject * Clone() const
> { return new MyMediaFormat(*this); }
>
> bool IsValidForProtocol(const PString & protocol) const
> { return protocol *= "sip"; }
> };
>
> 2) You need to register the new media format, usually done in the
> the Initialise member function of the OpalManager descendant. The
> following code will do this:
>
> // add non-standard video size
> new MyMediaFormat("MyFormat", 704, 576, 25);
>
> 3) You need to create and register transcoders that can convert
> between the new format and YUV420P. You can either create your
> transcoders from scratch, or you can use the new function I just
> added to PWLib to register a transcoder using another transcoder,
> as follows:
>
> // add transcoders for this format based on H.263
> OpalTranscoderFactory::RegisterAs(
> OpalMediaFormatPair("MyFormat", "YUV420P"),
> OpalMediaFormatPair("H.263", "YUV420P")
> );
> OpalTranscoderFactory::RegisterAs(
> OpalMediaFormatPair("YUV420P", "MyFormat"),
> OpalMediaFormatPair("YUV420P", "H.263")
> );
>
> Note that this registers new transcoders for MyFormat using the
> transcoders for H.263. This assumes that the H.263 transcoders will
> accept the size 704 x 576 which they should, as this is CIF4. They
> won't accept the frame size in your original example (640x480) but
> you could try modifying the codec plugin code to remove this
> restriction.
>
> 4) If you want to use H.323, you will need to create and register
> capabilities for the new format. This is seriously advanced - I
> suspect you don't want to do this :)
>
> BTW: you will need the latest CVS of PWLib and OPAL (as of about 10
> minutes ago) to use the above code.
>
> But it *does* work - I've tested it :)
>
> 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]
