Re: [Ekiga-devel-list] Building libopal with recent ffmpeg/libavcodec

2011-01-11 Thread Eugen Dedu

On 11/01/11 07:29, Howard Chu wrote:

I saw in this message
http://mail.gnome.org/archives/ekiga-list/2011-January/msg00026.html
that there were problems using libopal with current libx264. I had a few
problems compiling the H263/H264/MPEG4 plugins and wrote the attached
patch to address them. Now the code compiles, but I haven't got anyone
else running Ekiga to test against. Anyone out there able to try this?

(You can probably ignore the configure diff; that was an earlier hack
when I only had static libraries for libavcodec and so the configure
test failed to link. The problem doesn't occur when you have shared
libraries that are already linked against their dependencies.)

PS: I was just pointed to
https://bugzilla.gnome.org/show_bug.cgi?id=596006 so I've attached a
part of this patch there as well.


Sorry, I read the bug comment before this e-mail.

You can use 5...@ekiga.net to test.  It is always a bit of pain for me to 
test this codec, since it is not installed by default on my machine.


Could you please explain why lines
+#define __STDC_CONSTANT_MACROS
are needed?

--
Eugen
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Building libopal with recent ffmpeg/libavcodec

2011-01-11 Thread Howard Chu

Eugen Dedu wrote:

On 11/01/11 07:29, Howard Chu wrote:

I saw in this message
http://mail.gnome.org/archives/ekiga-list/2011-January/msg00026.html
that there were problems using libopal with current libx264. I had a few
problems compiling the H263/H264/MPEG4 plugins and wrote the attached
patch to address them. Now the code compiles, but I haven't got anyone
else running Ekiga to test against. Anyone out there able to try this?

(You can probably ignore the configure diff; that was an earlier hack
when I only had static libraries for libavcodec and so the configure
test failed to link. The problem doesn't occur when you have shared
libraries that are already linked against their dependencies.)

PS: I was just pointed to
https://bugzilla.gnome.org/show_bug.cgi?id=596006 so I've attached a
part of this patch there as well.


Sorry, I read the bug comment before this e-mail.

You can use 5...@ekiga.net to test.  It is always a bit of pain for me to
test this codec, since it is not installed by default on my machine.


I already tried 5...@ekiga.net but it only connected with H261. I guess I can 
try again after disabling the other codecs.


Could you please explain why lines
+#define __STDC_CONSTANT_MACROS
are needed?


Without that, there are complaints that UINT64_C is undefined, apparently the 
new libavcodec headers use this macro and by default this macro is explicitly 
disabled in C++.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list


Re: [Ekiga-devel-list] Building libopal with recent ffmpeg/libavcodec

2011-01-11 Thread Thierry Simonnet

On 01/11/2011 10:06 AM, Howard Chu wrote:

Eugen Dedu wrote:

On 11/01/11 07:29, Howard Chu wrote:

I saw in this message
http://mail.gnome.org/archives/ekiga-list/2011-January/msg00026.html
that there were problems using libopal with current libx264. I had a 
few

problems compiling the H263/H264/MPEG4 plugins and wrote the attached
patch to address them. Now the code compiles, but I haven't got anyone
else running Ekiga to test against. Anyone out there able to try this?

(You can probably ignore the configure diff; that was an earlier hack
when I only had static libraries for libavcodec and so the configure
test failed to link. The problem doesn't occur when you have shared
libraries that are already linked against their dependencies.)

PS: I was just pointed to
https://bugzilla.gnome.org/show_bug.cgi?id=596006 so I've attached a
part of this patch there as well.


Sorry, I read the bug comment before this e-mail.

You can use 5...@ekiga.net to test. It is always a bit of pain for me to
test this codec, since it is not installed by default on my machine.


I already tried 5...@ekiga.net but it only connected with H261. I guess 
I can try again after disabling the other codecs.


Could you please explain why lines
+#define __STDC_CONSTANT_MACROS
are needed?


Without that, there are complaints that UINT64_C is undefined, 
apparently the new libavcodec headers use this macro and by default 
this macro is explicitly disabled in C++.



I noticed also that some opal functions are deprecated.
Find 3 patches for compiling ekiga with opal/ptlib trunk versions :
I can have H263 working but H263-1998 is present but crashes.
For H264 it is more complex. Dyna does't load it.

--

Thierry Simonnet

ESIEE-Paris

Par respect pour l’environnement, n’imprimez ce mail que si nécessaire


--- ./lib/engine/components/opal/opal-call.cpp.orig   2010-06-03 08:16:15.0 +0200
+++ ./lib/engine/components/opal/opal-call.cpp  2010-06-03 13:46:57.0 +0200
@@ -157,11 +157,11 @@
   PSafePtrOpalConnection connection = get_remote_connection ();
   if (connection != NULL) {

-on_hold = connection-IsConnectionOnHold (false);
+on_hold = connection-IsOnHold (false);
 if (!on_hold)
-  connection-HoldConnection ();
+  connection-Hold (false, true);
 else
-  connection-RetrieveConnection ();
+  connection-Hold (false, false);
   }
 }

--- lib/engine/components/opal/sip-endpoint.cpp_orig	2011-01-11 09:42:18.0 +0100
+++ lib/engine/components/opal/sip-endpoint.cpp	2011-01-11 09:41:57.0 +0100
@@ -990,7 +990,7 @@
 
 
 void
-Opal::Sip::EndPoint::OnMessageFailed (const SIPURL  messageUrl,
+Opal::Sip::EndPoint::OnFailed (const SIPURL  messageUrl,
   SIP_PDU::StatusCodes /*reason*/)
 {
   SIPURL to = messageUrl;
--- lib/engine/components/opal/sip-endpoint.h_orig	2011-01-11 09:41:06.0 +0100
+++ lib/engine/components/opal/sip-endpoint.h	2011-01-11 09:45:00.0 +0100
@@ -195,7 +195,7 @@
   bool OnReceivedMESSAGE (OpalTransport  transport,
   SIP_PDU  pdu);
 
-  void OnMessageFailed (const SIPURL  messageUrl,
+  void OnFailed (const SIPURL  messageUrl,
 SIP_PDU::StatusCodes reason);
 
   SIPURL GetRegisteredPartyName (const SIPURL  host,
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

Re: [Ekiga-devel-list] Building libopal with recent ffmpeg/libavcodec

2011-01-11 Thread Eugen Dedu

On 11/01/11 10:55, Thierry Simonnet wrote:

On 01/11/2011 10:06 AM, Howard Chu wrote:

Eugen Dedu wrote:

On 11/01/11 07:29, Howard Chu wrote:

I saw in this message
http://mail.gnome.org/archives/ekiga-list/2011-January/msg00026.html
that there were problems using libopal with current libx264. I had a
few
problems compiling the H263/H264/MPEG4 plugins and wrote the attached
patch to address them. Now the code compiles, but I haven't got anyone
else running Ekiga to test against. Anyone out there able to try this?

(You can probably ignore the configure diff; that was an earlier hack
when I only had static libraries for libavcodec and so the configure
test failed to link. The problem doesn't occur when you have shared
libraries that are already linked against their dependencies.)

PS: I was just pointed to
https://bugzilla.gnome.org/show_bug.cgi?id=596006 so I've attached a
part of this patch there as well.


Sorry, I read the bug comment before this e-mail.

You can use 5...@ekiga.net to test. It is always a bit of pain for me to
test this codec, since it is not installed by default on my machine.


I already tried 5...@ekiga.net but it only connected with H261. I guess
I can try again after disabling the other codecs.


Could you please explain why lines
+#define __STDC_CONSTANT_MACROS
are needed?


Without that, there are complaints that UINT64_C is undefined,
apparently the new libavcodec headers use this macro and by default
this macro is explicitly disabled in C++.


I noticed also that some opal functions are deprecated.
Find 3 patches for compiling ekiga with opal/ptlib trunk versions :
I can have H263 working but H263-1998 is present but crashes.
For H264 it is more complex. Dyna does't load it.


These 3 patches allow just to use opal trunk instead of opal branch, so 
it does not advance the problem at all.


--
Eugen
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list