RE: [maemo-developers] libxv status?
Daniel Stone wrote: It means that the video hardware does not support RGB565 (everything on the device, basically) and YUV together. You can't have part of the screen being RGB and part being YUV; the problem is a couple of layers below the X server. Yes it does and yes you can, as I wrote the support and it works pretty well... ;) Oh, thanks. Now I understand. From the product brief http://www.erd.epson.com/vdc/html/contents/S1D13742.htm and from kernel sources I wrongly guessed that the conversion is done on the fly (per each update) when moving data from main memory to videoram. But as it is simple DMA it looks like You understood the kernel sources correctly. Just set the format flag in ioctl() for each update specifying the format for the updated window area. This functionality is independent from the source of the data (be it ARM or C55). - Jussi Laako ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
On Tuesday 25 July 2006 09:01, you wrote: http://www.internettablettalk.com/forums/showthread.php?t=2405 Actually mplayer works surprisingly fast and has performance not much inferior to default video player on Nokia 770 that is using DSP. And that all is even without hardware colorspace conversion support! So is it possible to have an accelerated version of libxv on Nokia 770 that would support colorspace conversion and scaling (no matter whether using video controller capabilities or relay this task to DSP)? So that a more universal and well supported ARM core could deal only with video stream decoding. We don't have any plans to do this for the 770. Thanks for your reply. In order not to take much of your time, just a few more questions which require only yes/no/maybe answers :) Does Nokia 770 hardware really support YUV colorspace? Is it technically possible (I'm not asking whether it is planned by Nokia now) to have some simple API for YUV colorspaces support added probably as part of libxsp? Is Nokia interested in getting any assistance from the community (from me for example) in improving performance and capabilities of the software and libraries preinstalled on the device? I'm interested in good video support and also game development (official support for twice lower resolution in SDL using pixel doubling, support for portrait/landscape screen orientation modes, background music playback utilizing DSP core, virtual keyboard for X11 applications and SDL in particular, etc.). So I don't mind contributing some of my free time to do some work in order to get all this real. Thanks. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
On Wed, Jul 26, 2006 at 09:07:57AM +0300, ext Siarhei Siamashka wrote: On Tuesday 25 July 2006 09:01, you wrote: http://www.internettablettalk.com/forums/showthread.php?t=2405 Actually mplayer works surprisingly fast and has performance not much inferior to default video player on Nokia 770 that is using DSP. And that all is even without hardware colorspace conversion support! So is it possible to have an accelerated version of libxv on Nokia 770 that would support colorspace conversion and scaling (no matter whether using video controller capabilities or relay this task to DSP)? So that a more universal and well supported ARM core could deal only with video stream decoding. We don't have any plans to do this for the 770. Thanks for your reply. In order not to take much of your time, just a few more questions which require only yes/no/maybe answers :) Does Nokia 770 hardware really support YUV colorspace? My understanding is that the only support we have right now is through the DSP. Is it technically possible (I'm not asking whether it is planned by Nokia now) to have some simple API for YUV colorspaces support added probably as part of libxsp? Having some sort of wrapper around the DSP access would be desirable, yes. It's theoretically possible to do with Xv as well, if someone's sufficiently motivated: there's no necessary tie between Xv and actually using the GPU. Is Nokia interested in getting any assistance from the community (from me for example) in improving performance and capabilities of the software and libraries preinstalled on the device? I can't speak for the company as a whole, but I'd hazard a guess at the answer to that one generally being yes. :) I'm interested in good video support and also game development (official support for twice lower resolution in SDL using pixel doubling, support for portrait/landscape screen orientation modes, background music playback utilizing DSP core, virtual keyboard for X11 applications and SDL in particular, etc.). So I don't mind contributing some of my free time to do some work in order to get all this real. To be honest, I haven't played with the SDL stuff at all, and it's not really in my area, so I'd have to defer to someone else here. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
Daniel Stone wrote: On Wed, Jul 26, 2006 at 09:07:57AM +0300, ext Siarhei Siamashka wrote: Does Nokia 770 hardware really support YUV colorspace? My understanding is that the only support we have right now is through the DSP. Hello Daniel, could we clarify this a bit? As far as I understand it the omapfb framebuffer driver (drivers/video/omap/hwa742.c) has access to the Epson 742 chip and according to kernel source supports YUV-RGB color conversion when transferring data from main memory to internal video ram via OMAPFB_UPDATE_WINDOW ioctl defined in include/asm-arm/arch-omap/omapfb.h. There is color format parameter in this ioctl and one of the defined ones is OMAPFB_COLOR_YUV420 Do you say that DSP has such driver duplicated in DSP code and accesses this chip directly? or does the DSP do colorspace conversion in its code and the features of HWA747 chip and ioctls with OMAPFB_COLOR_YUV420 is actually not used (maybe because there is some problem with it)? I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? I have actually asked similar question but so far got no answer. http://www.gossamer-threads.com/lists/maemo/developers/10223#10223 Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
On Wed, Jul 26, 2006 at 09:34:03AM +0200, ext Frantisek Dufka wrote: could we clarify this a bit? As far as I understand it the omapfb framebuffer driver (drivers/video/omap/hwa742.c) has access to the Epson 742 chip and according to kernel source supports YUV-RGB color conversion when transferring data from main memory to internal video ram via OMAPFB_UPDATE_WINDOW ioctl defined in include/asm-arm/arch-omap/omapfb.h. There is color format parameter in this ioctl and one of the defined ones is OMAPFB_COLOR_YUV420 You can only have one format per plane, and the plane is set up as RGB565 (for obvious reasons). Do you say that DSP has such driver duplicated in DSP code and accesses this chip directly? or does the DSP do colorspace conversion in its code and the features of HWA747 chip and ioctls with OMAPFB_COLOR_YUV420 is actually not used (maybe because there is some problem with it)? I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Correct. Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? Not at the moment: you need multiple planes, so you can also set up a separate YUV surface, you can't just blit in with a different format. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
Daniel Stone wrote: On Wed, Jul 26, 2006 at 09:34:03AM +0200, ext Frantisek Dufka wrote: Do you say that DSP has such driver duplicated in DSP code and accesses this chip directly? or does the DSP do colorspace conversion in its code and the features of HWA747 chip and ioctls with OMAPFB_COLOR_YUV420 is actually not used (maybe because there is some problem with it)? I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Correct. Sorry, but is is still not clear to me which parts you quoted are correct. So currently DSP code decodes mp4 into RGB and then lets the framebuffer code blit it to the epson chip in RGB? And ioctls with OMAPFB_COLOR_YUV420 is not used due to not solved problems with multiple surfaces? Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? Not at the moment: you need multiple planes, so you can also set up a separate YUV surface, you can't just blit in with a different format. And why this is a problem? Yes I understand you need extra memory (surface) allocated for YUV operations. Why it is a problem to have 800x600 in RGB and additional 320x240 in YUV both managed by xserver? Isn't this generic thing already solved in xserver and used on other plaforms? Sorry for being too ignorant about X internals :-) Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
On Wed, Jul 26, 2006 at 10:48:40AM +0200, ext Frantisek Dufka wrote: Daniel Stone wrote: On Wed, Jul 26, 2006 at 09:34:03AM +0200, ext Frantisek Dufka wrote: I thought DSP only decodes video to shared framebuffer in main memory and the actual transfer to epson chip is done by omapfb driver i.e. by ARM CPU from gstreamer or directly from mediaserver code. Correct. Sorry, but is is still not clear to me which parts you quoted are correct. So currently DSP code decodes mp4 into RGB and then lets the framebuffer code blit it to the epson chip in RGB? And ioctls with OMAPFB_COLOR_YUV420 is not used due to not solved problems with multiple surfaces? The paragraph I've left quoted is correct: the DSP decodes into a shared framebuffer, which is then DMA'ed across. Am I wrong with this? If not, is it possible to add YUV surfaces to xserver (via Xv or Nokia Xsp extensions) so it could be used from X11 code in Mplayer or (nonpartched or patched) SDL ? Not at the moment: you need multiple planes, so you can also set up a separate YUV surface, you can't just blit in with a different format. And why this is a problem? Yes I understand you need extra memory (surface) allocated for YUV operations. Why it is a problem to have 800x600 in RGB and additional 320x240 in YUV both managed by xserver? Isn't this generic thing already solved in xserver and used on other plaforms? Sorry for being too ignorant about X internals :-) It means that the video hardware does not support RGB565 (everything on the device, basically) and YUV together. You can't have part of the screen being RGB and part being YUV; the problem is a couple of layers below the X server. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] libxv status?
On Tue, Jul 11, 2006 at 01:53:13PM +0300, ext Siarhei Siamashka wrote: When trying to compile mplayer, I have noticed that there is libxv packaged in maemo sdk and also it can also be installed using apt-get on the real device. It is useless at least for mplayer though: It seems there is no Xvideo support for your video card available. Run 'xvinfo' to verify its Xv support and read DOCS/HTML/en/video.html#xv! See 'mplayer -vo help' for other (non-xv) video out drivers. Try -vo x11 http://www.internettablettalk.com/forums/showthread.php?t=2405 Actually mplayer works surprisingly fast and has performance not much inferior to default video player on Nokia 770 that is using DSP. And that all is even without hardware colorspace conversion support! So is it possible to have an accelerated version of libxv on Nokia 770 that would support colorspace conversion and scaling (no matter whether using video controller capabilities or relay this task to DSP)? So that a more universal and well supported ARM core could deal only with video stream decoding. Hi, We don't have any plans to do this for the 770. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
[maemo-developers] libxv status?
Hello All, When trying to compile mplayer, I have noticed that there is libxv packaged in maemo sdk and also it can also be installed using apt-get on the real device. It is useless at least for mplayer though: It seems there is no Xvideo support for your video card available. Run 'xvinfo' to verify its Xv support and read DOCS/HTML/en/video.html#xv! See 'mplayer -vo help' for other (non-xv) video out drivers. Try -vo x11 http://www.internettablettalk.com/forums/showthread.php?t=2405 Actually mplayer works surprisingly fast and has performance not much inferior to default video player on Nokia 770 that is using DSP. And that all is even without hardware colorspace conversion support! So is it possible to have an accelerated version of libxv on Nokia 770 that would support colorspace conversion and scaling (no matter whether using video controller capabilities or relay this task to DSP)? So that a more universal and well supported ARM core could deal only with video stream decoding. Having a more capable video player with *.ogm, *.mkv formats support, subtitles, wider variety of supported codec and other nice features would be nice to have. ARM core may have higher power consumption, but it seems to be fast enough for decoding video. Some people may want to trade battery life for better video formats support and quality. Also it is interesting to know about the future plans of Nokia team. What can we expect to see improved in the near future (maybe after some nice summer vacations you all deserved ;))? Also what help can the community provide? ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
