Hi Matthias, you're right, I'm sorry, I forgot to add these details. I'm doing all the work and tests on Fedora Core 6 machines, using some different versions of Ekiga stable (2.0.9 too) for the clients. I didn't try using the SVN trunk, I'll try and report here if something relevant emerges.
Thanks again, Lorenzo On Tuesday 22 May 2007 22:16:52 Matthias Schneider wrote: > Hi Lorenzo, > could you please specify which version of ekgia you are using (SVN trunk, > which revision, or ekiga stable). Also you didnt mention the platform > (linux, win32,...) > > Thaks in advance, > Matthias > > --- Lorenzo Miniero <[EMAIL PROTECTED]> schrieb: > > Hi all, > > > > I'm writing this mail and not on -users since I think this will be of > > more interest to developers than users. > > > > I'm developing a videomixing application and I'm using Ekiga to test its > > functionality with H.261. The mixing and composition, both based on > > libavcodec/libswscale, of more Ekiga video sources works fine (well > > fine... let's say it somehow works, to be a start), but I noticed a > > strange behavior when sending the mixed frames back to the Ekigas. All > > is done on 176x144 frames, which means that each Ekiga sends its own > > 176x144 frame, and they receive back a 176x144 composed frame containing > > a mix of all the sources. However, when Ekiga receives the first mixed > > frame, the video window is resized to 352x288, even if only the top-left > > part (which is 176x144) is filled with the incoming frames, while the > > rest of the window remains empty, except for some garbage. > > > > The strange thing is that, if before sending Ekiga the first mixed > > frame, I send it back a frame of it's own video, the window is not > > resized and the mixed video appears in a normal 176x144 window. > > I don't know if it's a bug in Ekiga or if it's what I'm sending that is > > corrupt, which is why I've written you about it, since I really can't > > understand what could be wrong. > > > > I've uploaded an example of what is sent to an Ekiga: > > > > * a Wireshark dump, http://confiance.sf.net/ekiga_wireshark.dump > > * and a RTPTools dump, http://confiance.sf.net/ekiga_rtptools.dump > > > > both about 300k, which I hope can help you riproduce the scenario. > > If you're interested you can use the rtptools dump to see how ffplay > > instead correctly understands the size of the frames: > > > > rtpplay -s 6666 -f ekiga_rtptools.dump /6668 (sender) > > rtpdump -F payload /6668 | ffplay -f h261 - (receiver) > > > > which of course means nothing, since I just used libavcodec to encode > > the frames. > > > > Thanks in advance for any feedback you'll be able to give me, I hope to > > hear from you soon. > > > > Regards, > > Lorenzo > > > > -- > > Lorenzo Miniero, Junior Researcher > > Dipartimento di Informatica e Sistemistica > > Università degli Studi di Napoli "Federico II" > > Via Claudio 21 -- 80125 Napoli (Italy) > > Phone: +390817683821 - Fax: +390817683816 > > Email: [EMAIL PROTECTED] > > _______________________________________________ > > Ekiga-devel-list mailing list > > Ekiga-devel-list@gnome.org > > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list > > Heute schon einen Blick in die Zukunft von E-Mails wagen? Versuchen > Sie´s mit dem neuen Yahoo! Mail. www.yahoo.de/mail > _______________________________________________ > Ekiga-devel-list mailing list > Ekiga-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- Lorenzo Miniero, Junior Researcher Dipartimento di Informatica e Sistemistica Università degli Studi di Napoli "Federico II" Via Claudio 21 -- 80125 Napoli (Italy) Phone: +390817683821 - Fax: +390817683816 Email: [EMAIL PROTECTED] _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list