Re: [GnomeMeeting-list] H261PixelEncoder : H.261 bad geometry: 320x240

[Miguel Rodríguez <migrax terra es>]

El mié, 07-01-2004 a las 23:41, Damien Sandras escribió:
> 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
> 
I didn't realise that the image was already being scaled before being
transmitted. In this case the scaling should be applied by the lib.
In any case, it would be cool still if the image was displayed in GM
using XVideo, so that the user could scale the iamge as much as he
wanted, even with the grey borders :(
Those I separated issues, even if I was able to mix/confuse them ;)

> > 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