|
List Info Thread: Some points on the EKIGA/OPAL video plugin
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
Some points on the EKIGA/OPAL video plugin |
|
List Info Thread: Some points on the EKIGA/OPAL video plugin
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
yahoo.de> wrote:
> Hi all,
>
> in the process of developing a video plugin for
ekiga/opal I noticed some things that I would like
> to clarify. Everything mentioned here refers to the
latest HEAD version of OPAL, EKIGA nd PWLIB.I
> am posting this to both openh323/opal and ekiga lists
since some topics do concern both software
> packages..
>
> OPAL issue:
>
> - in patch.cxx OpalMediaPatch::Main() we do a sleep (5)
after each packet received
> 5ms sleeping is much too long and has lead to buffer
overruns in the UDP input que in my case
> (e.g. if a frame is transmitted as 4 packets at 25fps,
and we need 20 ms waiting after the
> received packet, leaving only another 20 ms per frame
to decode and display it - not enough in my
> case) Right now my workaround is to wait 5 ms only
after every frame since I have not yet
> understood the motivation for this sleep - the select
that is called in order to collect the
> packets should e blocking anyway, so we dont need any
sleep? Or does this depend on the platform?
> Possibly this problem doesnt appear on windows - there
is an #if !defined (WIN32) in the code.
> Also I do not understand which other thread should be
allowed to take the mutex...
The 5ms sleep was inserted to prevent the codec thread from
consuming
all of the available CPU time. This commonly occurs on Linux
with it's
"opportunistic" scheduling, but can also occur on
Windows too.
>
> EKIGA bug:
>
> - EKIGA does not complete a remotely initiated
termination of a call (see attached file
> terminate.txt) - happens with different endpoints. If
video is activated, outbound video
> transmission does not even stop. If the connection is
terminated by ekiga everything works like
> expected.
>
> Plugin uncertainties:
>
> - dynamic RTP
> If I understand correctly, EKIGA/OPAL should support
dynamic RTP payload types (like in the
> speex plugin) for video as well.
Correct
> - Is it correct interpretation of RFC 4566 (please
advise if there is an RFC more specific on
> dynamic RTP PTs) that the rtpmap attribute specifies
the PT on which it will be received and that
> it can be asymmetric (e.g. A sending with PT 96 while
receiving the same codec on 99 because A
> sent an SDP line "a=rtpmap:99 X/90000" and B
"a=rtpmap:96 X/90000"?
This sounds correct, and OPAL should handle this case.
> - How do I handle dynamic RTP types in a video
plugin? As I understand there are two options -
> shared RTP code (e.g. speex) and separately coded RTP
(e.g. h263ffmpeg.cxx). If I understand
> correctly I have to register a dynamic PT codec plugin
with the RTPTypeDynamic flag. - With which
> PT do I register my plugin? How do I know with which
RTP PT to tag the outgoing frames? Or is it
> mandatory to use the shared RTP code in this case? How
do I put in the correct timecode and maker
> in that case?
Your understanding is not quite accurate.
The two modes for RTP are either explicit RTP payload code
(used for
codecs that have defined payload types such as G.711 or
H.261) and
dynamic payload codes (used for everything else)
Where there are many codecs with the same IANA name and
clock rate (such
as Speex narrow band audio), OPAL will automatically use the
same
payload code for all of them in order to avoid the needless
consumption
of the limited RTP payload code space. This is not something
you need to
worry about as it happens automatically and should not
affect anything
else
> Also, if I add the RTPTypeDynamic flag instead of
RTPTypeExplicit, the
> codec does no longer appear in the EKIGA codec list...
Have you tried the opalcodecinfo program that is supplied
with OPAL? It
lists the available codecs as reported by the underlying
OPAL system -
this would help determine if the problem is in OPAL or
Ekiga.
> - fmtp handling
> How is the a=fmtp line in sip/sdp handled? I noticed
that it is possible to hand an fmtp line
> from the encoder side to the SDP handler like in speex.
However this happens BEFORE options like
> width and height of frame are set up, making it
impossible to include anything based on that in
> the fmtp line, which is sometimes necessary. Also I am
wondering how the received a=fmtp line is
> passed to the decoder.
fmtp handling is not yet complete
> General Questions:
> - cerr and PTRACEs commented out in h323ffmpeg.cxx
> All log output in h323ffmpeg.cxx is commented out.
What would be the correct way for outputting
> log information in a video plugin without introducing
unneccessary dependencies?
I'm not sure. It's not easy to provide a mechanism for
outputting
debugging from a plugin that is loaded (perhaps) by a
program that has
no console. Under Windows, any console output from a GUI
program is
silently discarded - I'm not sure about Linux.
..deleted
Craig
------------------------------------------------------------
-----------
Craig Southeren Post Increment – VoIP Consulting
and Software
craigs