[h323plus] Video Resolution

Carlos Haj unazona at hotmail.com
Mon Jan 18 06:19:05 EST 2010


I've been working on this, I have more detailed results.

of all, my webcam VideoInputDevice has the correct qCIF size before the
attachVideoReader, while tracing the read of the codec it the
rawChannel and grabwidth and grabheight are correct.

I traced the plugin DLL.

H323plus callback OpenVideoChannel, the videoCodec framesize is already
set using H261EncoderContext::SetFrameSize(352,288); which corresponds
to default frame size I suppose.

The only problem.. A further
call to codec.SetFrameSize sets the new framesize only in h323
capabilities, and it never reachs the plugin DLL I have traced one call
to h261encodecontext::SetFrameSize.

No trace for h261 setframesize while invoking the codec.setframesize.

each call of H261 EncodeFrames(...) returns 0 on TRACE(1,"H261\tPayload
of grabbed frame too small for full frame"); as assigned frameSize is
different than the videoDevice.

It seems that mediaFormat.SetOptionInteger never tell the pluginDLL about the frameSize option changing.

Have you and idea?


From: s.horne at packetizer.com
To: unazona at hotmail.com; h323plus at lists.packetizer.com
Subject: RE: [h323plus] Video Resolution
Date: Sat, 16 Jan 2010 04:05:25 +1000

Maybe I should 
rephase my last email
The old openH323 behaviour in the OpenVideoChannel allowed the 
user to safely set the webcam framesize to the default size of the 
codec because it was always fixed. So if your codec was CIF webcam was 
CIF. So that is why QCIF/CIF in both 
directions works. Now you have changed the frame 
size of CIF capability to QCIF in the codec it won't. 
Why? You must make sure in your code the framesize coming out of 
the VideoInputdevice when you create it is set to QCIF otherwise 
it will be CIF and the encoder will expect QCIF and 
that is why you are getting the codec encoder call returning 0 and the 
channel being closed down.
Did I miss something?

From: Carlos Haj [mailto:unazona at hotmail.com] 

Sent: Saturday, 16 January 2010 3:24 AM
s.horne at packetizer.com; h323plus at lists.packetizer.com
Subject: RE: 
[h323plus] Video Resolution


I used fixed width and height to determine display and 
reader working, and I traced again my application.

This time I went 
deeper into the h323plus library, I think it's a bug of h323plus, between the 
library and the video codec plugin.

Bug Scenario:

I have set 

    AddAllCapabilities(0, P_MAX_INDEX, 

I only use H261 this time


Set the maximum Frame size 
and send a kind of parameter cifTag to the plugin

on my 
OnVideoChannel I initialise 

if (encoder) 


This is the call stack by chronological order for an h323 video 
call using a CIF<->QCIF endpoint (trace is for endpoint that sending 


it creates the 
encoder, and set frame size to CIF (the default plugin maximum 


it adjusts the frame 
size, called from my OnVideoChannel, with qcif Value


All work, my rawChannel, 
renderer, etc... until I reach line 1690

H323pluginmgr.cxx::1690 - THE 
FIRST READ call to encode video fails

    int retval = (codec->codecFunction)(codec, 
bufferRTP.GetPointer(), &fromLen,
dst.GetPointer(), &toLen,

retval = 0, which results 
into closing the channel as it returns false,

if I change 
SetVideoFrameSize(H323Capability::cifMPI); into 

The codec function 
works again, but naturally with qCIF on both sides

I think that once the 
codec parameter was tagged to use a cif or a qcif it can't change resolution 
during the call. so the encoding function fail for a resolution different than 
one setted using the SetVideoFrameSize.

It's likely that the 
SetVideoFrameSize send an additional information to plugin code using a 
setcontrolcodec which are required later so the encoding function works 

I noticed, that video resolution fail is only a local 
behaviour, and has nothing to do with remote endpoint.

I will be 
debugging more, I still don't know the plugin code so much, so you might have a 
clearer idea than me? I think if you make a simple test you would encounter the 
same behaviour!


From: s.horne at packetizer.com
To: unazona at hotmail.com; 
h323plus at lists.packetizer.com
Subject: RE: [h323plus] Video 
Date: Sat, 16 Jan 2010 01:37:07 +1000

You cannot know what the remote will send when you call 
OpenVideoChannel for the decoding side, that can only be done when you 
receive the first RTP packets. 
You need to do a level 6 trace to work out who and why the 
channel is being closed. I don't think it is a capability issue, usually the 
problem comes from either the video encoder device (webcam) or the display 
device. Check to see that you have set the video input device to 
send at the same size as your encoder. The old openH323 used 
to do be able to do that automatically as the frame size for the 
capability was known. You have to make sure the input 
to the encoder from the webcam is correct.  
Version of h323plus would be irrelevent in this case. 


From: Carlos Haj [mailto:unazona at hotmail.com] 

Sent: Saturday, 16 January 2010 1:06 AM
s.horne at spranto.com.au; s.horne at packetizer.com; 
h323plus at lists.packetizer.com
Subject: RE: [h323plus] Video 


Thanks for valuable information. What is happening 
literally in a minimised case: I derived OnVideoChannel

on the Local 

if (encoding)
codec.SetFrameSize(352, 288);
      cout << 
      cout << 
      // I receive CIF 

on the Remote 

if (encoding)
codec.SetFrameSize(176, 144);
      cout << 
      cout << 
      // I receive 
CIF (normal)

I looked into H323 trace Log, 
(remote endpoint which supposed to send QCIF) 

PLUGIN       Error encoding frame from 
plugin H.261-CIF
Request CloseLogicalChannel
H323RTP     Transmit 
H.261-CIF thread ended

It seems that the H.261 channel is closed 
prematurely. As my local endpoint received an incorrect video size I suppose 
that local endpoint causes remote to close the transmission 

Could this be related to the version of the plugin or h323plus 
lib which I use? it's likely that the video resolution is sent before 
codec.SetFrameSize is invoked!

Did you in practice used different video 
resolution under the same capability? e.g. CIF<->QCIF 


From: s.horne at spranto.com.au
To: unazona at hotmail.com; s.horne at packetizer.com; 
h323plus at lists.packetizer.com
Subject: RE: [h323plus] Video 
Date: Fri, 15 Jan 2010 23:14:23 +1000

The current behaviour is correct. 
The old OpenH323 used to only send CIF with *-CIF{sw} 
capability and only QCIF with *-QCIF{sw} . This was 
changed with the video plugins so the capability could do up to CIF so 
it would also supported QCIF. This is perfectly 
H.245 legal.
In this way only 1 capability can do both frame sizes. 
This is the way most manufacturers implement the capability 
The capability has a flag for the size it supports so the old CIF 
capability used to say QCIF - 0 CIF - 1. So if you wanted to do QCIF you 
had to use the *-QCIF{sw} capability as the QCIF flag in the *-CIF{sw} was 0. 
This was changed so that the *-CIF{sw} capability had the QCIF flag so it could 
also support QCIF. Then it was safe to remove the *-QCIF{sw} capability and only 
exchange using the *-CIF{sw}. 
Now SetVideoFrameSize() will set the global frame size limit so 
regardless of the direction that will be the maximum size permitted (if CIF 
only up to CIF capability is available). The codec.FrameSize() in the 
MyH323Endpoint::OpenVideoChannel() allows the implementor to set the 
actual frame size to send. 
Is there something else I missed?

From: Carlos Haj [mailto:unazona at hotmail.com] 

Sent: Friday, 15 January 2010 8:39 PM
s.horne at packetizer.com; h323plus at lists.packetizer.com
Subject: RE: 
[h323plus] Video Resolution


Thanks for your quick answer, just noticed that I had a 
bad thread name;)

Well, I have the codec.SetFrameSize(w, h); in my 

When adding capabilities I 

AddAllCapabilities(0, P_MAX_INDEX, 

table shows as 

Set 0: 0: 

I receive an OpenVideoChannel for encoder, I open 
channel and attach video reader + colourConverter, just after that I receive a 
close video signal from a H245Negotation, here I join Call Stack

>   testApp.exe!mmDDSVideoOutputBridge::close2()  Ligne 
359    C++
testApp.exe!mmVideoInputDevice::~mmVideoInputDevice()  Ligne 43 + 
0x1b    C++
testApp.exe!mmVideoInputDevice::`scalar deleting destructor'()  + 
0x2b    C++
testApp.exe!PVideoChannel::CloseVideoReader()  Ligne 203 + 
0x24    C++
testApp.exe!PVideoChannel::Close()  Ligne 145    
testApp.exe!H323Codec::CloseRawDataChannel()  Ligne 488 + 
0x11    C++
testApp.exe!H323VideoCodec::Close()  Ligne 747    
testApp.exe!H323Channel::CleanUpOnTermination()  Ligne 
716    C++
testApp.exe!H323_RTPChannel::CleanUpOnTermination()  Ligne 
1160    C++
testApp.exe!H245NegLogicalChannel::Release()  Ligne 1219    
H245_CloseLogicalChannelAck & __formal={...})  Ligne 
1086    C++
H245_CloseLogicalChannelAck & pdu={...})  Ligne 1372 + 
0xf    C++
testApp.exe!H323Connection::OnH245Response(const H323ControlPDU & 
pdu={...})  Ligne 3293 + 0x22    C++
testApp.exe!H323Connection::HandleControlPDU(const H323ControlPDU & 
pdu={...})  Ligne 3189 + 0x12    C++
testApp.exe!H323Connection::HandleControlData(PPER_Stream & 
strm={...})  Ligne 3170 + 0x18    C++
testApp.exe!H323Connection::HandleReceivedControlPDU(bool readStatus=true, 
PPER_Stream & strm={...})  Ligne 3103 + 0x12    
testApp.exe!H323Connection::HandleControlChannel()  Ligne 3085 + 
0x13    C++
testApp.exe!H245TransportThread::Main()  Ligne 700    

If I remove the 
"SetVideoFrameSize(H323Capability::cifMPI);", I get the following capabilities 

1: H.261-CIF{sw}

with exactly same 
strange behaviour, QCIF is not sending while CIF is being received, by the way 
qcif endpoint says

Local Video Codec - H.261-CIF{sw}
Local Resolution 
- 176x144

Remote Video Codec - H.261-CIF{sw}
Remote Resolution - 

I tried a "ReorderCapabilities(PStringArray("QCIF"));" after 
my addcapabilities, I ended up with both endpoints using QCIF and ignoring my 
SetFrameSize anyway!!

Is there a glitch using H323Plus video plugins? my 
code works perfectly on openh323 

"SetVideoFrameSize(H323Capability::cifMPI);" is supposed to define 
a maximum video resolution?! as you said in API doc "... to set the maximum 
framesize allowed to the specified value "

Is that usual to have 
H.261-CIF with a QCIF resolution? On which order codec plugins can be added to 
avoid such problems of negotiation?


From: s.horne at packetizer.com
To: unazona at hotmail.com; 
h323plus at lists.packetizer.com
Subject: RE: [h323plus] Valid sessionID in 
OpenLogicalChannel command
Date: Fri, 15 Jan 2010 08:12:54 +1000

In your 

From: h323plus-bounces at lists.packetizer.com 
[mailto:h323plus-bounces at lists.packetizer.com] On Behalf Of Carlos 
Sent: Friday, 15 January 2010 12:59 AM
h323plus at lists.packetizer.com
Subject: Re: [h323plus] Valid sessionID 
in OpenLogicalChannel command

Hello Guys,

I would like to have different frame sizes for two endpoints, 
first I tried to play around with H323Endpoint::SetVideoFrameSize, but it seems 
that part changes the maximum allowed size, which means that if I switch the 
videoFrameSize to qCIF, I wouldn't be able to receive CIF from the other 
endpoint. my test only received QCIF.

I tried also to modify the 
OpalMediaFormat by using a GetWritableMediaFormat for a capability, that ended 
with unusual CIF format while having a QCIF resolution.

On the other 
hand, I looked Opal examples where they use an OpalManager, but unfortuntly that 
seems incompatible with h323plus, while old openh323 tutorials and exampls don't 
have any video plugins support.

How I can manage to receive and send 
different resolutions (frame sizes) using H323plus?

I appreciate a lot 
your help

Discute avec tes amis partout, grâce à Messenger sur ton mobile. Cliquez ici ! 

Avec Internet Explorer, surfez en toute discrétion sur internet Cliquez ici ! 

Avec Internet Explorer, surfez en toute discrétion sur internet Cliquez ici 
Discutez en direct avec vos amis sur Messenger !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/h323plus/attachments/20100118/2172775f/attachment.htm>

More information about the h323plus mailing list