Re: [Ekiga-devel-list] Incoming video in Ekiga

[Lorenzo Miniero <lorenzo miniero unina it>]

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 <lorenzo miniero unina it> 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: lorenzo miniero unina it
> > _______________________________________________
> > 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: lorenzo miniero unina it