Igor

The problem is caused by an master/slave conflict when first opening the audio channel which results in the OLC being rejected. The correct process is to renegotiate the OLC. It appears that the T1000 cannot properly renegotiate the OLC and incorrectly allocates an invalid sessionID of 0 which causes the assert and behavior you highlighted.

I also see you are using a modified and working H.264 plugin and have decided not to contribute any of that work back to the project. This is a pity.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com] Sent: Monday, 28 December 2009 9:46 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

Sending log. T1000 in most cases after Reject sends OLC with sessionID=0, and in less cases send OLC with sessionID from 32 up to 53 (increase 1 after each reject).

2009/12/28 Simon Horne s.horne@packetizer.com

Igor

Session ID should never be zero. This is clearly an error coming from the T1000 unit.

Can you post a level 6 trace showing the condition the T1000 sends an OLC with sessionID = 0

Simon

_____

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Igor Pavlov Sent: Monday, 28 December 2009 8:25 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Valid sessionID in OpenLogicalChannel command

Hi.

I have problem when I reject OpenLogicalChannel (audio) while communicating with Tandberg T1000. In most cases Tandberg send me OpenLogicalChannel again with sessionID=0 so my application falls in assertion in file rtp.cxx line 760 : PAssert(id > 0 && id < 256, PInvalidParameter);

I could not find valid value range for sessionID, but I don't like when application crashes in this case :( What can I do in this situation?

Igor Pavlov

Igor

The problem you are having with the Tandberg T1000 is a tandberg bug. The endpoint cannot properly renegotiate the OLC on a master/slave conflict. The H323plus end advises the T1000 that it is master however the T1000 ignores it causing the conflict. Tandberg may have a firmware update to correct the problem.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com] Sent: Monday, 28 December 2009 11:07 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

About H.264 plugin - actualy I have 3rd party static library for H.264 encoding/decoding and use H264 plugin as wrapper to connect library to h323plus. I don't think anyone has interest of half working plugin without static library...

28 декабря 2009 г. 15:57 пользователь Simon Horne s.horne@packetizer.com написал:

Igor

The problem is caused by an master/slave conflict when first opening the audio channel which results in the OLC being rejected. The correct process is to renegotiate the OLC. It appears that the T1000 cannot properly renegotiate the OLC and incorrectly allocates an invalid sessionID of 0 which causes the assert and behavior you highlighted.

I also see you are using a modified and working H.264 plugin and have decided not to contribute any of that work back to the project. This is a pity.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com] Sent: Monday, 28 December 2009 9:46 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

Sending log. T1000 in most cases after Reject sends OLC with sessionID=0, and in less cases send OLC with sessionID from 32 up to 53 (increase 1 after each reject).

2009/12/28 Simon Horne s.horne@packetizer.com

Igor

Session ID should never be zero. This is clearly an error coming from the T1000 unit.

Can you post a level 6 trace showing the condition the T1000 sends an OLC with sessionID = 0

Simon

_____

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Igor Pavlov Sent: Monday, 28 December 2009 8:25 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Valid sessionID in OpenLogicalChannel command

Hi.

I have problem when I reject OpenLogicalChannel (audio) while communicating with Tandberg T1000. In most cases Tandberg send me OpenLogicalChannel again with sessionID=0 so my application falls in assertion in file rtp.cxx line 760 : PAssert(id > 0 && id < 256, PInvalidParameter);

I could not find valid value range for sessionID, but I don't like when application crashes in this case :( What can I do in this situation?

Igor Pavlov

Igor

There are 2 things here. 1. compensate for the T1000 inability to renegotiate the channel on master/slave conflict. (it should be the slave but ignores the message from H323plus) so that you still get audio. 2. ensure that if the OLC does contain an invalid sessionID that we avoid the assert and reject the OLC.

I have checked a patch into the CVS (h323.cxx,h323neg.cxx) that should resolve both problems.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com] Sent: Tuesday, 29 December 2009 12:24 AM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

Simon

I can see following sequence of packets with sniffer:

me -> T1000 : masterSlaveDetermination : terminalType 50 T1000 -> me : masterSlaveDetermination : terminalType 50 me -> T1000 : masterSlaveDeterminationAck : descision slave(1) T1000 -> me : masterSlaveDeterminationAck : descision master(0)

Am I understand you right that T1000 says that he is master, however don't discharge master's obligations correct ?

May be Assert should work only in debug? But in release in this case h323plus should just reject such RTP session (with incorrect sessionID) ?

Igor

28 декабря 2009 г. 16:47 пользователь Simon Horne s.horne@packetizer.com написал:

Igor

The problem you are having with the Tandberg T1000 is a tandberg bug. The endpoint cannot properly renegotiate the OLC on a master/slave conflict. The H323plus end advises the T1000 that it is master however the T1000 ignores it causing the conflict. Tandberg may have a firmware update to correct the problem.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com]

Sent: Monday, 28 December 2009 11:07 PM

To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

About H.264 plugin - actualy I have 3rd party static library for H.264 encoding/decoding and use H264 plugin as wrapper to connect library to h323plus. I don't think anyone has interest of half working plugin without static library...

28 декабря 2009 г. 15:57 пользователь Simon Horne s.horne@packetizer.com написал:

Igor

The problem is caused by an master/slave conflict when first opening the audio channel which results in the OLC being rejected. The correct process is to renegotiate the OLC. It appears that the T1000 cannot properly renegotiate the OLC and incorrectly allocates an invalid sessionID of 0 which causes the assert and behavior you highlighted.

I also see you are using a modified and working H.264 plugin and have decided not to contribute any of that work back to the project. This is a pity.

Simon

_____

From: Igor Pavlov [mailto:pavlov.ig@gmail.com] Sent: Monday, 28 December 2009 9:46 PM To: Simon Horne Cc: h323plus@lists.packetizer.com Subject: Re: [h323plus] Valid sessionID in OpenLogicalChannel command

Sending log. T1000 in most cases after Reject sends OLC with sessionID=0, and in less cases send OLC with sessionID from 32 up to 53 (increase 1 after each reject).

2009/12/28 Simon Horne s.horne@packetizer.com

Igor

Session ID should never be zero. This is clearly an error coming from the T1000 unit.

Can you post a level 6 trace showing the condition the T1000 sends an OLC with sessionID = 0

Simon

_____

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Igor Pavlov Sent: Monday, 28 December 2009 8:25 PM To: h323plus@lists.packetizer.com Subject: [h323plus] Valid sessionID in OpenLogicalChannel command

Hi.

I have problem when I reject OpenLogicalChannel (audio) while communicating with Tandberg T1000. In most cases Tandberg send me OpenLogicalChannel again with sessionID=0 so my application falls in assertion in file rtp.cxx line 760 : PAssert(id > 0 && id < 256, PInvalidParameter);

I could not find valid value range for sessionID, but I don't like when application crashes in this case :( What can I do in this situation?

Igor Pavlov

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 Carlos

_________________________________________________________________ Découvrez Windows 7 en 7 secondes ! http://clk.atdmt.com/FRM/go/181574577/direct/01/

Simon,

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

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

When adding capabilities I use

AddAllCapabilities(0, P_MAX_INDEX, "*");

SetVideoFrameSize(H323Capability::cifMPI);

Capabilities table shows as

Set 0: 0: audio 1: H.261-CIF{sw}

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 C++

testApp.exe!H323Codec::CloseRawDataChannel() Ligne 488 + 0x11 C++

testApp.exe!H323VideoCodec::Close() Ligne 747 C++

testApp.exe!H323Channel::CleanUpOnTermination() Ligne 716 C++

testApp.exe!H323_RTPChannel::CleanUpOnTermination() Ligne 1160 C++

testApp.exe!H245NegLogicalChannel::Release() Ligne 1219 C++

testApp.exe!H245NegLogicalChannel::HandleCloseAck(const H245_CloseLogicalChannelAck & __formal={...}) Ligne 1086 C++

testApp.exe!H245NegLogicalChannels::HandleCloseAck(const 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 C++

testApp.exe!H323Connection::HandleControlChannel() Ligne 3085 + 0x13 C++

testApp.exe!H245TransportThread::Main() Ligne 700 C++

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

1: H.261-CIF{sw}

H.261-QCIF{sw}

H.261{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 - 352x288

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 stack.

"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?

Regards

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

Carlos

In your derived

H323EndPoint::OpenVideoChannel(()

(isEncoding)

codec.SetFrameSize(w,h);

Simon

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Carlos Haj Sent: Friday, 15 January 2010 12:59 AM To: h323plus@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 Carlos

_________________________________________________________________ Discutez en direct avec vos amis sur Messenger ! http://www.windowslive.fr/messenger

Simon,

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

on the Local endpoint

if (encoding)

{

codec.SetFrameSize(352, 288);

.....

}

else

{

cout << codec.GetWidth();

cout << codec.GetHeight();

// I receive CIF (ERROR)

.....

}

on the Remote endpoint

if (encoding)

{

codec.SetFrameSize(176, 144);

.....

}

else

{

cout << codec.GetWidth();

cout << codec.GetHeight();

// 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

H245 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 channel.

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 calls

Carlos

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

Carlos

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 exchange. 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?

Simon

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

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

Simon,

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

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

When adding capabilities I use

AddAllCapabilities(0, P_MAX_INDEX, "*"); SetVideoFrameSize(H323Capability::cifMPI);

Capabilities table shows as

Set 0: 0: audio 1: H.261-CIF{sw}

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 C++

testApp.exe!H323Codec::CloseRawDataChannel() Ligne 488 + 0x11 C++

testApp.exe!H323VideoCodec::Close() Ligne 747 C++

testApp.exe!H323Channel::CleanUpOnTermination() Ligne 716 C++

testApp.exe!H323_RTPChannel::CleanUpOnTermination() Ligne 1160 C++

testApp.exe!H245NegLogicalChannel::Release() Ligne 1219 C++

testApp.exe!H245NegLogicalChannel::HandleCloseAck(const H245_CloseLogicalChannelAck & __formal={...}) Ligne 1086 C++

testApp.exe!H245NegLogicalChannels::HandleCloseAck(const 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 C++

testApp.exe!H323Connection::HandleControlChannel() Ligne 3085 + 0x13 C++

testApp.exe!H245TransportThread::Main() Ligne 700 C++

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

1: H.261-CIF{sw}

H.261-QCIF{sw} H.261{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 - 352x288

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 stack.

"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?

Regards

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

Carlos

In your derived H323EndPoint::OpenVideoChannel(()

(isEncoding)

codec.SetFrameSize(w,h);

Simon

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Carlos Haj Sent: Friday, 15 January 2010 12:59 AM To: h323plus@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 Carlos

Discute avec tes amis partout, grâce à Messenger sur ton mobile. Cliquez ici ! _________________________________________________________________ Découvrez Windows 7 en 7 secondes ! http://clk.atdmt.com/FRM/go/181574577/direct/01/

Simon,

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

SetVideoFrameSize(H323Capability::cifMPI);

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

on my OnVideoChannel I initialise

if (encoder)

codec.SetFrameSize(176, 144);

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

1) H323PluginVideoCodec::H323PluginVideoCodec(...)

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

2) H323PluginVideoCodec::SetFrameSize(...)

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

3) H323PluginVideoCodec::Read(...)

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, context,

bufferRTP.GetPointer(), &fromLen,

dst.GetPointer(), &toLen,

&flags);

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

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

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 properly.

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!

Thanks

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

Carlos

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.

Simon

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

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

Simon,

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

on the Local endpoint

if (encoding) {

codec.SetFrameSize(352, 288); ..... } else { cout << codec.GetWidth(); cout << codec.GetHeight(); // I receive CIF (ERROR) ..... }

on the Remote endpoint

if (encoding) {

codec.SetFrameSize(176, 144); ..... } else { cout << codec.GetWidth(); cout << codec.GetHeight(); // 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 H245 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 channel.

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 calls

Carlos

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

Carlos

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 exchange. 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?

Simon

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

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

Simon,

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

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

When adding capabilities I use

AddAllCapabilities(0, P_MAX_INDEX, "*"); SetVideoFrameSize(H323Capability::cifMPI);

Capabilities table shows as

Set 0: 0: audio 1: H.261-CIF{sw}

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 C++

testApp.exe!H323Codec::CloseRawDataChannel() Ligne 488 + 0x11 C++

testApp.exe!H323VideoCodec::Close() Ligne 747 C++

testApp.exe!H323Channel::CleanUpOnTermination() Ligne 716 C++

testApp.exe!H323_RTPChannel::CleanUpOnTermination() Ligne 1160 C++

testApp.exe!H245NegLogicalChannel::Release() Ligne 1219 C++

testApp.exe!H245NegLogicalChannel::HandleCloseAck(const H245_CloseLogicalChannelAck & __formal={...}) Ligne 1086 C++

testApp.exe!H245NegLogicalChannels::HandleCloseAck(const 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 C++

testApp.exe!H323Connection::HandleControlChannel() Ligne 3085 + 0x13 C++

testApp.exe!H245TransportThread::Main() Ligne 700 C++

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

1: H.261-CIF{sw}

H.261-QCIF{sw} H.261{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 - 352x288

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 stack.

"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?

Regards

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

Carlos

In your derived H323EndPoint::OpenVideoChannel(()

(isEncoding)

codec.SetFrameSize(w,h);

Simon

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Carlos Haj Sent: Friday, 15 January 2010 12:59 AM To: h323plus@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 Carlos

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 ! _________________________________________________________________ Découvrez Windows 7 en 7 secondes ! http://clk.atdmt.com/FRM/go/181574577/direct/01/

Simon,

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

First 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.

When 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.

So, 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?

Regards, Carlos

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

Carlos

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?

Simon

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

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

Simon,

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

SetVideoFrameSize(H323Capability::cifMPI);

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

on my OnVideoChannel I initialise

if (encoder)

codec.SetFrameSize(176, 144);

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

1) H323PluginVideoCodec::H323PluginVideoCodec(...)

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

2) H323PluginVideoCodec::SetFrameSize(...)

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

3) H323PluginVideoCodec::Read(...)

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, context,

bufferRTP.GetPointer(), &fromLen,

dst.GetPointer(), &toLen,

&flags);

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

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

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 properly.

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!

Thanks

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

Carlos

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.

Simon

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

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

Simon,

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

on the Local endpoint

if (encoding) {

codec.SetFrameSize(352, 288); ..... } else { cout << codec.GetWidth(); cout << codec.GetHeight(); // I receive CIF (ERROR) ..... }

on the Remote endpoint

if (encoding) {

codec.SetFrameSize(176, 144); ..... } else { cout << codec.GetWidth(); cout << codec.GetHeight(); // 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 H245 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 channel.

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 calls

Carlos

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

Carlos

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 exchange. 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?

Simon

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

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

Simon,

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

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

When adding capabilities I use

AddAllCapabilities(0, P_MAX_INDEX, "*"); SetVideoFrameSize(H323Capability::cifMPI);

Capabilities table shows as

Set 0: 0: audio 1: H.261-CIF{sw}

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 C++

testApp.exe!H323Codec::CloseRawDataChannel() Ligne 488 + 0x11 C++

testApp.exe!H323VideoCodec::Close() Ligne 747 C++

testApp.exe!H323Channel::CleanUpOnTermination() Ligne 716 C++

testApp.exe!H323_RTPChannel::CleanUpOnTermination() Ligne 1160 C++

testApp.exe!H245NegLogicalChannel::Release() Ligne 1219 C++

testApp.exe!H245NegLogicalChannel::HandleCloseAck(const H245_CloseLogicalChannelAck & __formal={...}) Ligne 1086 C++

testApp.exe!H245NegLogicalChannels::HandleCloseAck(const 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 C++

testApp.exe!H323Connection::HandleControlChannel() Ligne 3085 + 0x13 C++

testApp.exe!H245TransportThread::Main() Ligne 700 C++

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

1: H.261-CIF{sw}

H.261-QCIF{sw} H.261{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 - 352x288

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 stack.

"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?

Regards

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

Carlos

In your derived H323EndPoint::OpenVideoChannel(()

(isEncoding)

codec.SetFrameSize(w,h);

Simon

From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of Carlos Haj Sent: Friday, 15 January 2010 12:59 AM To: h323plus@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 Carlos

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 ! http://www.windowslive.fr/messenger