Re: [Ekiga-devel-list] Send other than RTP packets in RTP stream / Envoyer autre chose que du RTP dans le flux RTP
David Jardin wrote: Hi everyone, For academic purpose (I'm currently a student at Limoges University), I need to modify the source code of Ekiga in order to send packets other than RTP in the RTP stream. How can I do that? I'm working on the code for several days but I'm completly blocked. The deadline is soon and I cannot manage to do what I want. I looked mainly to rtp.cxx and mediastrm.cxx of the lib opal. Do I have to look at ptlib? I propose you to use the opal upstream mailing list for opal/ptlib questions: opalvoip-u...@lists.sourceforge.net -- Eugen Dedu ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] DCCP
I'm currently working on a TFRC integration to obtain a video rate control that is adaptive to the network conditions (e.g. congestion state). Up til now, I were using RTCP receiver reports (RR) and sender reports (SR) to calculate the following parameters: at the sender: - localRTT = ReceiverReportArrivalTime - LSR - DLSR - TFRC rate as a function of the RTT and of the loss event rate p. The encoding rate is then adjusted as a function of this rate. at the receiver: - loss event rate, as a function of the received RTT parameter, which is then returned to the receiver Both, the loss event rate and the RTT values are transmitted in application defined messages (APP) with the SR and RR messages using a RTCP compound packet. So far, this scheme works pretty well and the encoding rate adapts on-the-fly during an RTP session according to the congestion faced on the network. Well, this post is about optimizing this scheme, since I recently came across a different way of computing and transmitting the necessary TFRC parameters that seems more efficient concerning the RTCP bandwidth constraints (RTCP traffic should take no more than 5% of RTP traffic): RTP with TCP Friendly Rate Control (http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10) Especially the requirement for a feedback message to be sent at least every RTT could generate a considerable overhead (ex. in a LAN) with my scheme. As this new scheme would eliminate the need for SR or RR (which are used to calculate the RTT in my scheme), I am wondering why the RTCP SR and RR were initially used for in Ekiga/Opal. So far, I could not find a reason for this... I would be glad if someone could explain their use in Ekiga or whether these reports can be eliminated without loosing any required functionality. Thank you, Thomas -- View this message in context: http://www.nabble.com/DCCP-tp17711387p23938663.html Sent from the Ekiga Dev mailing list archive at Nabble.com. ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] Mingw32 : Having problem with ffmpeg
Am Dienstag, den 09.06.2009, 13:22 +0200 schrieb paul hillereau: I have looked through your logs. It appears that you have vfw.h snip ..snip First I am very thankfull for all of your answers, thanks you for spending some time on my problem. I installed the new mingw32 runtime on my debian lenny, and at least issues with vfw vere solved. But after changing the WINVER macro in ptlib/include/ptlib/msos/ptlib/contain.h from value 0x500 (windows 2k) to 0x501 (windows XP), which correct errors with getaddrinfo in ekiga/win32/ptlib/src/ptlib/common/sockets.cxx; now there is a linker error : [snip] /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/contain.o /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/object.o -lwinmm -lwsock32 -lsnmpapi -lmpr -lcomdlg32 -lgdi32 -lavicap32 -liphlpapi -lole32 -lregex -lexpat -ldsound -ldxerr9 -ldxguid -lstrmiids -lole32 -luuid -loleaut32 -lquartz -ldnsapi /home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/obj_d/sockets.o: In function `_ZN11PHostByName7GetHostERK7PString': /home/devel/win32/ekiga/win32/ptlib/src/ptlib/common/sockets.cxx:532: undefined reference to `_getaddri...@16' /home/devel/win32/ekiga/win32/ptlib/src/ptlib/common/sockets.cxx:535: undefined reference to `_freeaddri...@4' collect2: ld returned 1 exit status make[3]: *** [/home/devel/win32/ekiga/win32/ptlib/lib_mingw_x86/libpt_d.dll.2.7-beta0] Error 1 make[3]: Leaving directory `/home/devel/win32/ekiga/win32/ptlib/src' make[2]: *** [debug] Error 2 Seems I will have to submit another patch to their build system. In the meantime try to change into the directory from which the Makefile issued the link command and repeat it by hand appending -lws2_32 without the quotes. You will have to do that also when linking Ekiga. Regards Michael ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [POLL] Which video output implementation are you using?
trying to understand the following bug : http://bugzilla.gnome.org/show_bug.cgi?id=575887 I stumbled on a terrible question : what if the X video output had always been broken?! Could you please answer to that mail stating whether ekiga is using XV or X for the video output on your box? I'm pretty sure the Fedora build is using Xv. What's the easiest way to detect this? I haven't had any reports of it from Fedora users (not to say that its not a problem). I presonally don't use video regularly. Peter ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] New ekiga stable release soon
Peter Robinson wrote: Hi Eugen, Is there a list of blockers for this crash/freeze/hang-free ekiga ;-) Is there anything that needs further testing etc? Just before doing the release, I checked my connection to 5...@ekiga.net with the new release and I had a bug which I wait to be fixed (I tried to, but without success..., the line which does that is around src/gui/main.cpp:149: mw-priv-accounts.remove (host); ) When I call 500, the URI bar changes for a few moments to to:udp$...@ekiga.net or something like that. Do you have it too with stable branches of ptlib/opal/ekiga? This bug should have been fixed by http://git.gnome.org/cgit/ekiga/commit/?h=gnome-2-26id=a26fb7de3203a0e80b4cdc69bda5918fbeaad3b2. but it seems it is not yet fixed (in all cases). The problem is that I do not track stable branch, but trunk/master. It does not appear on master. I tried also a git bissect, without success, I think it appeared also before, I do not know what to say. I do not know what to do instead of waiting... Eugen Peter On Sat, May 30, 2009 at 9:47 AM, Eugen Dedueugen.d...@pu-pm.univ-fcomte.fr wrote: Hi, Many fixes for crashes have accumulated since last stable (10 days ago). We would like to release another stable version. Our secret goal :o) is to have a (nearly) crash/freeze/hang-free ekiga. When people, especially distribution maintainers (windows included :o)), would like it to happen: in a few days, in one week, in 10 days? (For info, next stable gnome is very late, for 29 June.) I think that many of the bugs at http://bugzilla.gnome.org/buglist.cgi?product=ekigabug_status=NEWbug_status=REOPENEDbug_status=ASSIGNEDbug_status=UNCONFIRMEDbug_status=NEEDINFObug_severity=critical are fixed, could people involved check? Currently, there are three identical crashes in Write method (NEEDINFO on bugzilla) for which Roberts waits output logs... What else do you like to have it fixed (reasonable)? -- Eugen ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [POLL] Which video output implementation are you using?
Peter Robinson a écrit : trying to understand the following bug : http://bugzilla.gnome.org/show_bug.cgi?id=575887 I stumbled on a terrible question : what if the X video output had always been broken?! Could you please answer to that mail stating whether ekiga is using XV or X for the video output on your box? I'm pretty sure the Fedora build is using Xv. What's the easiest way to detect this? I haven't had any reports of it from Fedora users (not to say that its not a problem). I presonally don't use video regularly. ekiga -d 4 says what is used when video preview is enabled. I think the X code is a fallback for the XV code. :-/ Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] [POLL] Which video output implementation are you using?
Julien Puydt a écrit : Peter Robinson a écrit : trying to understand the following bug : http://bugzilla.gnome.org/show_bug.cgi?id=575887 I stumbled on a terrible question : what if the X video output had always been broken?! Could you please answer to that mail stating whether ekiga is using XV or X for the video output on your box? I'm pretty sure the Fedora build is using Xv. What's the easiest way to detect this? I haven't had any reports of it from Fedora users (not to say that its not a problem). I presonally don't use video regularly. ekiga -d 4 says what is used when video preview is enabled. I think the X code is a fallback for the XV code. :-/ Hoo! Now I remember Mathias implemented a gconf for his tests to disable XV. I'm not sure but maybe the code is still there; i found this in gconf: /apps/ekiga/general/user_interface/video_display/disable_hw_accel Is this what you're looking for Snark? Best regards, Yannick Snark ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list ___ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
