[h323plus] Video Resolution
Simon Horne
s.horne at packetizer.com
Mon Jan 18 15:57:41 EST 2010
Carlos
Well caught. I have applied a fix into the CVS.
Simon
_____
From: Carlos Haj [mailto:unazona at hotmail.com]
Sent: Tuesday, 19 January 2010 12:32 AM
To: s.horne at packetizer.com; h323plus at lists.packetizer.com
Subject: RE: [h323plus] Video Resolution
Hello Simon,
Thanks for your time and effort. I had the same problem using H263 plugin on
both windows and linux.
I found the glitch finally in h323plus code, the following function calls
fine but sends absolutly nothing to the video plugin DLL
h323pluginmgr.cxx::730
PBoolean SetCodecControl(...):
you can verify that by tracing "encoder_set_options" in the video plugin
dll!! Codec options can't be changed during a call, including framewidth,
bandwidth, quality, etc...
on the other hand, the call to encoder_set_options in H323PluginVideoCodec
constructor works, that's why the plugin has initial default profile values.
h323pluginmgr.cxx::1590
PluginCodec_ControlDefn * ctl = GetCodecControl(codec,
SET_CODEC_OPTIONS_CONTROL);
etc...
I modified the SetCodecControl static function, here is it
static PBoolean SetCodecControl(const PluginCodec_Definition * codec,
void * context,
const char * name,
const char * parm,
const char * value)
{
PluginCodec_ControlDefn * codecControls = GetCodecControl(codec, name);
if (codecControls == NULL)
return FALSE;
PStringArray list;
list += parm;
list += value;
char ** _options = list.ToCharArray();
unsigned int optionsLen = sizeof(_options);
bool result = (*codecControls->control)(codec, context,
SET_CODEC_OPTIONS_CONTROL, _options, &optionsLen);
free(_options);
return result;
/* old Code
....
char const * options[2] = { parm, value };
unsigned optionsLen = 2;
return (*codecControls->control)(codec, context,
SET_CODEC_OPTIONS_CONTROL, options, &optionsLen);
*/
}
With that, I'm able to have a CIF-QCIF and QCIF-CIF calls!!
Hope this was helpful, good luck appreciate your effort.
Greetings,
Carlos
_____
From: s.horne at packetizer.com
To: unazona at hotmail.com
Subject: RE: [h323plus] Video Resolution
Date: Mon, 18 Jan 2010 22:50:42 +1000
Carlos
The framesize information is passed to the encoder as part of the frame
header information. The codec should adjust the frame size according to the
header information passed to it. This would be a bug in the H.261 encoder.
Simon
_____
From: h323plus-bounces at lists.packetizer.com
[mailto:h323plus-bounces at lists.packetizer.com] On Behalf Of Carlos Haj
Sent: Monday, 18 January 2010 9:19 PM
To: h323plus at lists.packetizer.com
Subject: Re: [h323plus] Video Resolution
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 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
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 at hotmail.com]
Sent: Saturday, 16 January 2010 3:24 AM
To: s.horne at packetizer.com; h323plus at 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 at packetizer.com
To: unazona at hotmail.com; h323plus at 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 at hotmail.com]
Sent: Saturday, 16 January 2010 1:06 AM
To: s.horne at spranto.com.au; s.horne at packetizer.com;
h323plus at 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 at spranto.com.au
To: unazona at hotmail.com; s.horne at packetizer.com;
h323plus at 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 at hotmail.com]
Sent: Friday, 15 January 2010 8:39 PM
To: s.horne at packetizer.com; h323plus at 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 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
Carlos
In your derived
H323EndPoint::OpenVideoChannel(()
(isEncoding)
codec.SetFrameSize(w,h);
Simon
_____
From: h323plus-bounces at lists.packetizer.com
[mailto:h323plus-bounces at lists.packetizer.com] On Behalf Of Carlos Haj
Sent: Friday, 15 January 2010 12:59 AM
To: 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
Carlos
<http://clk.atdmt.com/FRM/go/182932252/direct/01/>
_____
Discute avec tes amis partout, grâce à Messenger sur ton mobile. Cliquez ici
! <http://www.messengersurvotremobile.com/>
_____
Avec Internet Explorer, surfez en toute discrétion sur internet Cliquez ici
! <http://clk.atdmt.com/FRM/go/182932252/direct/01/>
_____
Avec Internet Explorer, surfez en toute discrétion sur internet Cliquez ici
! <http://clk.atdmt.com/FRM/go/182932252/direct/01/>
_____
Discute avec tes amis partout, grâce à Messenger sur ton mobile. Cliquez ici
! <http://www.messengersurvotremobile.com/>
_____
Avec Internet Explorer, surfez en toute discrétion sur internet Cliquez ici
<http://clk.atdmt.com/FRM/go/182932252/direct/01/> !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/h323plus/attachments/20100119/154e1d5c/attachment-0004.html>
More information about the h323plus
mailing list