[h323plus] lost rtp packets and using jitter for video session

[Konstantin]

Dear Simon,

I tried to check if h323plus endpoint works with demanded jitter value
or not. From the linux server side that has OpenMCU started I executed:
# tc qdisc add dev eth0 root netem delay 74ms 2ms
(74ms is average delay, 2ms is jitter)

And the video receiving on the client side (Myphone) became distorted.

Then I tried to decrease jitter value from 2 to 1ms with:
# tc qdisc delete dev eth0 root netem delay 74ms 2ms
# tc qdisc add dev eth0 root netem delay 74ms 1ms
(74ms avg delay, 1ms jitter)

And the video come back to normal. So 1ms jitter looks OK, 2ms - not OK:

6-level tracing shows time to time:
2012/08/09 14:34:49.034	3	         rtp.cxx(1122)	RTP	Dropped 1 packet(s) at 19195, ssrc=532876226
2012/08/09 14:34:49.034	6	h323pluginmgr.cxx(2105)	PLUGIN	Partial Frame received H.264-4CIF2 Ignoring rendering.
2012/08/09 14:34:49.034	3	         rtp.cxx(1103)	RTP	Out of order packet, received 19194 expected 19196 ssrc=532876226

h323plus version I use has been forked, it is from Myphone3 project, so I
don't mean you should fix something in the original h323plus... But de-jittering
used for receiving audio only in both branches of project, that's why I need to
ask you do you see any other way to resolve this except to get jitter buffer
work with the video RTP also?

I tried to increase jitter buffer stack, fix 40ms/frame constant and force it to
work with video, but my endpoint just hangs when attempting to draw incoming
video frame at the moment. And I need an advice, is this way "right" or not?
And what's the reason of creating additional buffers for outputdevice if the
out-of- order packets just drops?




Simon Horne s.horne at packetizer.com
Tue Feb 8 08:29:07 EST 2011
--------------------------------------------------------------------------
Igor

 

The main issue is not the packets are being lost but the rendering being too
slow and blocking  the receive thread which would drop packets. 

The quick solution was to throw the actual rending within your
VideoOutputDevice onto another thread and use a std::queue (with mutex) to
load the frames coming out of the codec and grab the frames to send to the
renderer. This will then not block the receiving thread.

 

You can be cleaver and build a 1-3 frame buffer in your outputdevice to
simulate a jitter buffer.

See

MyVideoOutputDevice::SetFrameData(..,const void * mark);

 

The mark is a H323_RTPInformation pointer which contains a pointer to the
last raw received RTP packet of the completed frame.  You can get timestamp
information from this and pace the output to the render, so if a frame is
dropped then you can conceal it.

 

Simon

 

 

From: h323plus-bounces at lists.packetizer.com
[mailto:h323plus-bounces at lists.packetizer.com] On Behalf Of Igor Pavlov
Sent: 08 February 2011 22:27
To: h323plus at lists.packetizer.com
Subject: [h323plus] lost rtp packets and using jitter for video session

 

Hi,

On connection speed greater than 384 kbps I have many lost rtp packets.
If I switch off decoding of incoming video packets, than number of lost
packets decreases.
That is why I would like to try use jitter on video stream.
I changed call of OpalMediaFormat() constructor inside OpalVideoFormat
constructor in such way that needsjitter member become TRUE.
But It is not working, not decoding any data.

How can I use Jitter for my purpose and in general - can I do it?

Igor Pavlov