Re: [GnomeMeeting-list] H261PixelEncoder : H.261 bad geometry: 320x240
- From: Damien Sandras <damien sandras it-optics com>
- To: gnomemeeting-list gnome org
- Subject: Re: [GnomeMeeting-list] H261PixelEncoder : H.261 bad geometry: 320x240
- Date: Wed, 07 Jan 2004 23:41:00 +0100
Le mer 07/01/2004 à 23:13, Stefan Bruens a écrit :
> I think the problem is something else:
> Scaling from SIF to QIF is done because we need it for transmission, so it is
> done on the sending side, and this can't be done by special hardware
> effectively (although video cards are fast with transmission to the card and
> scaling, they are _really_ slow at reading back to normal ram, and we will
> need it there to encode an transmit it).
> This is atm done by pwlib, and I think it is the right place to do it,
> although real scaling, not padding, would be good.
>
I think what Miguel meant was :
- scaling to QCIF for transmission with padding
- displaying as it was real QSIF locally
> The next thing is to scale the received video, this can be done by special
> hardware, and here it might be good to use SDL/Xv/OpenGL.
> IIRC for embedded view, this is done by GDK, while for fullscreen, SDL is
> used.
Indeed, you are correct. But IMHO, there is no need to scale at the
reception side. You are receiving either QCIF or CIF, scaling would mean
you need to detect somehow it is not real QCIF or CIF, but padded
QCIF/CIF, and in that case do a local scaling to remove the border (if
any) before displaying it. That's a hack, not a solution.
>
> Greets,
> Stefan
--
_ Damien Sandras
(o-
//\ It-Optics s.a.
v_/_ GnomeMeeting: http://www.gnomemeeting.org/
FOSDEM 2004: http://www.fosdem.org
H.323 phone: callto:ils.seconix.com/dsandras seconix com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]