openmcu and h323plus - getting video operational
hi,
i'm in the process of getting openmcu up and running. the usual issues which have been discussed many many times - audio working but video is not - are being experienced. i've managed to get to the point where, after downloading the source code for ffmpeg, ptlib, h323plus, openmcu and various other plugins that i've found on openmcu.ru, and after making various modifications i can get a stable build... *without* video. the moment i add in the plugins which handle video, a connection from ekiga hangs openmcu indefinitely, to the extent where even the web interface on port 1420 doesn't work.
so, things that *might* be stopping this from working: i haven't been able to build any of the h323plus plugins, except just now, and i had to modify the "configure" script as well as the source code, because the detection of h263p_encoder has now been modified: it's called ff_h263p_encoder, as is h264_encoder, decoder and mpeg_decoder - they all now have the prefix "ff_" as you can see from these patches (which i found via very very obscure google searches)
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/opal/patches/
but... this still isn't enough, because the actual detection in configure.ac is utterly broken. so, instead what i did - temporarily - was to hack the configure script to define HAVE_H263P=yes, HAVE_H264_DETECTION=yes, HAVE_H263=yes on a permanent basis.
that then allowed me to actually have the plugins configured, *but* they're not actually compiled! so i had to "cd plugins" and run "make", that then discovered that there's an error in include/openh323buildopts.h - i had to edit this file to hard-code the location of ptlib's revision.h file (#include "/root/ptlib-2.10.4~dfsg/revision.h"), and hooray, the make worked.
i say worked, but it still didn't compile things: the detection for LIBAVCODEC changes is wrong - features that said to be in version 54 are actually present in version 52, so i had to make changes like this:
#if LIBAVCODEC_VERSION_MAJOR < 52 _context->codec_type = CODEC_TYPE_VIDEO; #else _context->codec_type = AVMEDIA_TYPE_VIDEO; #endif _context->codec_id = CODEC_ID_H264;
then there was also a #include that was commented out in rfc2190.cxx #include <malloc.h> which had to go back in, because the "free" function is undefined otherwise.
so fiiinally, that allowed h261-vic_video_pwplugin.so and a whole bunch of other codecs to be built (hooray!)
and, so, having compiled all these plugins, i now install them aaaaaand.... openmcu hangs when h261-vic_video_pwplugin.so is installed. all other plugins are installed (h264 etc.) but making a call with ekiga using these plugins, they're not activated.
so... after struggling to get even the plugins compiled (several hours of investigation), and struggling to get the source code compiled (2 days), things are no further along.
does anyone have a successful recipe and build environment and/or has anyone actually ever got openmcu to ever work with video, or does anyone have any advice on how to go about investigating and/or fixing the issue of hanging with h261-vic-video-pwplugin?
many thanks,
l.
huh, this is interesting - this came up in the trace.txt file - why is 1877.6kb/s being requested? is this something to do with ekiga not being set up properly?
0:07.438 H225 Answer:b5da7b70 20 options found: Adaptive Packet Delay = 0 Annex D = 0 CIF MPI = 1 CIF16 MPI = 0 CIF4 MPI = 0 Dynamic Video Quality = 0 Encoding Quality = 15 Frame Height = 144 Frame Time = 3003 Frame Width = 176 h323_stillImageTransmission = 0 h323_temporalSpatialTradeOffCapability = 0 Max Bit Rate = 1920000 Max Rx Frame Height = 288 Max Rx Frame Width = 352 Min Rx Frame Height = 288 Min Rx Frame Width = 352 QCIF MPI = 1 SQCIF MPI = 0 Target Bit Rate = 621700
0:07.438 H225 Answer:b5da7b70 LogChan Bandwidth requested/used = 1920.0/0.0 kb/s 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: -0.0kb/s, available: 1877.6kb/s 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: +1920.0kb/s, available: 1877.6kb/s 0:07.438 H225 Answer:b5da7b70 H323 Available bandwidth exceeded 0:07.438 H225 Answer:b5da7b70 H323 OnReceivedPDU gave error 7 0:07.438 H225 Answer:b5da7b70 RTP Found existing session 2 0:07.438 H225 Answer:b5da7b70 RTP Releasing session 2 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: -0.0kb/s, available: 1877.6kb/s 0:07.439 H225 Answer:b5da7b70 H225 Fast start open: { forwardLogicalChannelNumber = 1 forwardLogicalChannelParameters = { dataType = nullData <<null>>
Luke
The maximum bitrate is wrong. A value of above 621700 is technically impossible to transmit. The value should be whatever is set in the client. If you set 384k the maximum bitrate transmitted in the TCS should be 384k I suggest you try another H.323 client.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of lkcl luke Sent: 14 August 2012 23:23 To: h323plus@lists.packetizer.com Subject: Re: [h323plus] openmcu and h323plus - getting video operational
huh, this is interesting - this came up in the trace.txt file - why is 1877.6kb/s being requested? is this something to do with ekiga not being set up properly?
0:07.438 H225 Answer:b5da7b70 20 options found: Adaptive Packet Delay = 0 Annex D = 0 CIF MPI = 1 CIF16 MPI = 0 CIF4 MPI = 0 Dynamic Video Quality = 0 Encoding Quality = 15 Frame Height = 144 Frame Time = 3003 Frame Width = 176 h323_stillImageTransmission = 0 h323_temporalSpatialTradeOffCapability = 0 Max Bit Rate = 1920000 Max Rx Frame Height = 288 Max Rx Frame Width = 352 Min Rx Frame Height = 288 Min Rx Frame Width = 352 QCIF MPI = 1 SQCIF MPI = 0 Target Bit Rate = 621700
0:07.438 H225 Answer:b5da7b70 LogChan Bandwidth requested/used = 1920.0/0.0 kb/s 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: -0.0kb/s, available: 1877.6kb/s 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: +1920.0kb/s, available: 1877.6kb/s 0:07.438 H225 Answer:b5da7b70 H323 Available bandwidth exceeded 0:07.438 H225 Answer:b5da7b70 H323 OnReceivedPDU gave error 7 0:07.438 H225 Answer:b5da7b70 RTP Found existing session 2 0:07.438 H225 Answer:b5da7b70 RTP Releasing session 2 0:07.438 H225 Answer:b5da7b70 H323 Bandwidth request: -0.0kb/s, available: 1877.6kb/s 0:07.439 H225 Answer:b5da7b70 H225 Fast start open: { forwardLogicalChannelNumber = 1 forwardLogicalChannelParameters = { dataType = nullData <<null>>
On Wed, Aug 15, 2012 at 12:29 PM, Simon Horne s.horne@packetizer.com wrote:
Luke
The maximum bitrate is wrong. A value of above 621700 is technically impossible to transmit.
i have no idea where the value is coming from - i do know that my server's quite quick though (100mb/sec) and on a decent backbone.
The value should be whatever is set in the client. If you set 384k the maximum bitrate transmitted in the TCS should be 384k I suggest you try another H.323 client.
ok, will do. i appear to be downloading a looot of H323 clients :)
l.
There has been major upheaval in FFMPEG between version 52 to 54 and most of the api calls have changed (including detection). I thought we had caught most of them but even between different versions of 52 for instance the API changed. Very difficult to capture.
Usually the configure scripts will create the makefile in the plugin directory. So it's only a matter of going to the directory and typing make to build the particular plugin.
I suggest you test with a different client and see if you are experiencing the same issue. H.261 is very stable and is used in production on a wide variety of clients.
Simon
-----Original Message----- From: h323plus-bounces@lists.packetizer.com [mailto:h323plus-bounces@lists.packetizer.com] On Behalf Of lkcl luke Sent: 14 August 2012 23:14 To: h323plus@lists.packetizer.com Subject: [h323plus] openmcu and h323plus - getting video operational
hi,
i'm in the process of getting openmcu up and running. the usual issues which have been discussed many many times - audio working but video is not - are being experienced. i've managed to get to the point where, after downloading the source code for ffmpeg, ptlib, h323plus, openmcu and various other plugins that i've found on openmcu.ru, and after making various modifications i can get a stable build... *without* video. the moment i add in the plugins which handle video, a connection from ekiga hangs openmcu indefinitely, to the extent where even the web interface on port 1420 doesn't work.
so, things that *might* be stopping this from working: i haven't been able to build any of the h323plus plugins, except just now, and i had to modify the "configure" script as well as the source code, because the detection of h263p_encoder has now been modified: it's called ff_h263p_encoder, as is h264_encoder, decoder and mpeg_decoder - they all now have the prefix "ff_" as you can see from these patches (which i found via very very obscure google searches)
http://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/opal/patches/
but... this still isn't enough, because the actual detection in configure.ac is utterly broken. so, instead what i did - temporarily - was to hack the configure script to define HAVE_H263P=yes, HAVE_H264_DETECTION=yes, HAVE_H263=yes on a permanent basis.
that then allowed me to actually have the plugins configured, *but* they're not actually compiled! so i had to "cd plugins" and run "make", that then discovered that there's an error in include/openh323buildopts.h - i had to edit this file to hard-code the location of ptlib's revision.h file (#include "/root/ptlib-2.10.4~dfsg/revision.h"), and hooray, the make worked.
i say worked, but it still didn't compile things: the detection for LIBAVCODEC changes is wrong - features that said to be in version 54 are actually present in version 52, so i had to make changes like this:
#if LIBAVCODEC_VERSION_MAJOR < 52 _context->codec_type = CODEC_TYPE_VIDEO; #else _context->codec_type = AVMEDIA_TYPE_VIDEO; #endif _context->codec_id = CODEC_ID_H264;
then there was also a #include that was commented out in rfc2190.cxx #include <malloc.h> which had to go back in, because the "free" function is undefined otherwise.
so fiiinally, that allowed h261-vic_video_pwplugin.so and a whole bunch of other codecs to be built (hooray!)
and, so, having compiled all these plugins, i now install them aaaaaand.... openmcu hangs when h261-vic_video_pwplugin.so is installed. all other plugins are installed (h264 etc.) but making a call with ekiga using these plugins, they're not activated.
so... after struggling to get even the plugins compiled (several hours of investigation), and struggling to get the source code compiled (2 days), things are no further along.
does anyone have a successful recipe and build environment and/or has anyone actually ever got openmcu to ever work with video, or does anyone have any advice on how to go about investigating and/or fixing the issue of hanging with h261-vic-video-pwplugin?
many thanks,
l.
participants (2)
-
lkcl luke
-
Simon Horne