Difference between revisions of "MPlayer integration"
(front panel and menus) |
m (→Bitmap overlays) |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
Mplayer has become somewhat of a monolithic application in the linux world. Our use of mplayer will be to delegate to it the task which it does best, while retaining control over all other aspects. In particular the user interface provided by mplayer is somewhat primitive (athough extensible). It does however allow a bitmap overlay in real time via a pipe. This enables another program to generate the interface and have mplayer display it. | Mplayer has become somewhat of a monolithic application in the linux world. Our use of mplayer will be to delegate to it the task which it does best, while retaining control over all other aspects. In particular the user interface provided by mplayer is somewhat primitive (athough extensible). It does however allow a bitmap overlay in real time via a pipe. This enables another program to generate the interface and have mplayer display it. | ||
=Design ideas= | =Design ideas= | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Mplayer's menu system, while useable is not ideal. There is too much emphasis on layers of menus. | Mplayer's menu system, while useable is not ideal. There is too much emphasis on layers of menus. | ||
The simplicity of the font panel controls will be reflected in the remote control buttons. I want to avoid traversing a menu with the remote entirely. In cases where we want to access heirarchical structures, thumbnails of the content are more appropriate than text lists. Who cares if the name of a picture is ''dcs1273563254.jpg'' - this has no meaning. | The simplicity of the font panel controls will be reflected in the remote control buttons. I want to avoid traversing a menu with the remote entirely. In cases where we want to access heirarchical structures, thumbnails of the content are more appropriate than text lists. Who cares if the name of a picture is ''dcs1273563254.jpg'' - this has no meaning. | ||
=Bitmap overlays= | =Bitmap overlays= | ||
| + | The most modern way to get nice OSD with mplayer is vf_overlay. | ||
| + | |||
| + | At present this is a patch on MPlayer and due to political reasons, seems like it will remain like that for a while. This is not too much of a problem as Jason Tackaberry, the guy who maintains the patch seem quite dilligent, and he is supported by a number of other PVR projects (eg Freevo) who like the functionality it provides. | ||
| + | |||
| + | The main advantages of this patch is that it is not necessary to scale the overlay bitmap to the frame size of the playing video. vf_overlay will take a bitmap which is the same size as the display (say 800x600) and overlay this regardless of the frame size/apsect of the video (eg 16x9). | ||
| + | |||
| + | It also appears to provide a useful output buffer which would enable mplayer to feed video data directly into another process using shared memory with ''mmap'' | ||
| + | |||
| + | *http://urandom.ca/mebox/downloads/patches/ | ||
| + | *http://urandom.ca/mebox/downloads.php | ||
| + | |||
| + | |||
''bmovl'' is mplayer's built in overlay engine. When invoking mplayer in slave mode you can use this command to begin to use the bitmap overlay | ''bmovl'' is mplayer's built in overlay engine. When invoking mplayer in slave mode you can use this command to begin to use the bitmap overlay | ||
<pre> | <pre> | ||
| Line 42: | Line 47: | ||
*http://rve.sourceforge.net/doc/ | *http://rve.sourceforge.net/doc/ | ||
| − | |||
| − | |||
=Generating overlay bitmaps with SDL= | =Generating overlay bitmaps with SDL= | ||
Our existing SDL code should be able to integrate quite nicely, thanks to the [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat] function. This function specifies the bit packing for the SDL surface to be created. As long as this packing matches whatever packing is used in the overlay the bitmaps should work together. All that is required is a serialise function that will send the raw bitmap data into mplayer's pipe. | Our existing SDL code should be able to integrate quite nicely, thanks to the [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat] function. This function specifies the bit packing for the SDL surface to be created. As long as this packing matches whatever packing is used in the overlay the bitmaps should work together. All that is required is a serialise function that will send the raw bitmap data into mplayer's pipe. | ||
| Line 51: | Line 54: | ||
=See also= | =See also= | ||
*http://www.mplayerhq.hu/ | *http://www.mplayerhq.hu/ | ||
| + | *[http://oxine.sourceforge.net/ oxine] an OSD project for xine | ||
| + | *[http://njpatel.blogspot.com/2007/03/im-not-even-supposed-to-be-here-today.html Arena] a linux media center front end | ||
Latest revision as of 03:34, 20 August 2007
Mplayer has become somewhat of a monolithic application in the linux world. Our use of mplayer will be to delegate to it the task which it does best, while retaining control over all other aspects. In particular the user interface provided by mplayer is somewhat primitive (athough extensible). It does however allow a bitmap overlay in real time via a pipe. This enables another program to generate the interface and have mplayer display it.
Contents
Design ideas
Mplayer's menu system, while useable is not ideal. There is too much emphasis on layers of menus.
The simplicity of the font panel controls will be reflected in the remote control buttons. I want to avoid traversing a menu with the remote entirely. In cases where we want to access heirarchical structures, thumbnails of the content are more appropriate than text lists. Who cares if the name of a picture is dcs1273563254.jpg - this has no meaning.
Bitmap overlays
The most modern way to get nice OSD with mplayer is vf_overlay.
At present this is a patch on MPlayer and due to political reasons, seems like it will remain like that for a while. This is not too much of a problem as Jason Tackaberry, the guy who maintains the patch seem quite dilligent, and he is supported by a number of other PVR projects (eg Freevo) who like the functionality it provides.
The main advantages of this patch is that it is not necessary to scale the overlay bitmap to the frame size of the playing video. vf_overlay will take a bitmap which is the same size as the display (say 800x600) and overlay this regardless of the frame size/apsect of the video (eg 16x9).
It also appears to provide a useful output buffer which would enable mplayer to feed video data directly into another process using shared memory with mmap
bmovl is mplayer's built in overlay engine. When invoking mplayer in slave mode you can use this command to begin to use the bitmap overlay
bmovl=hidden:opaque:<fifo>
Read bitmaps from a FIFO and display them in window.
hidden: sets the default value of the 'hidden' flag (boolean)
opaque: flag switching between alphablended (transparent) and opaque (fast) mode
fifo: path/filename for the FIFO (named pipe connecting mplayer -vop bmovl to the controlling application)
FIFO commands are:
RGBA32 width height xpos ypos alpha clear
followed by width*height*4 bytes of raw RGBA32 data.
ABGR32 width height xpos ypos alpha clear
followed by width*height*4 bytes of raw ABGR32 data.
RGB24 width height xpos ypos alpha clear
followed by width*height*3 bytes of raw RGB32 data.
BGR24 width height xpos ypos alpha clear
followed by width*height*3 bytes of raw BGR32 data. <fifo>
See the mplayer man page this information was taken from for more details.
There is a program called Realtime Video Effects that makes it easy to feed Mplayer the correct bitmaps to display dynamic content over the top of video.
Generating overlay bitmaps with SDL
Our existing SDL code should be able to integrate quite nicely, thanks to the SDL_PixelFormat function. This function specifies the bit packing for the SDL surface to be created. As long as this packing matches whatever packing is used in the overlay the bitmaps should work together. All that is required is a serialise function that will send the raw bitmap data into mplayer's pipe.
Limitations
Mplayer's codecs do not handle review well - that is visually seeking backwards through video. This is the fault of the MPEG format, as the compresion is not desiged to play backwards.
See also
- http://www.mplayerhq.hu/
- oxine an OSD project for xine
- Arena a linux media center front end
