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