Incoming video in Ekiga

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://c
onfiance.sf.net/ekiga_wireshark.dump
	* and a RTPTools dump, http://co
nfiance.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.minierounina.it
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

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.minierounina.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://c
onfiance.sf.net/ekiga_wireshark.dump
> 	* and a RTPTools dump, http://co
nfiance.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.minierounina.it
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-listgnome.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-listgnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list