Skip to main content

How I hacked mplayer to work on Motorola ROKR - Part 2

It has been over a month since part 1, so let me start off quickly and finish this part. I will try to explain how I got the 19 bpp working in mplayer. It was very straight forward really. I had to edit the following files from the mplayer-cvs (you can download the code from http://code.google.com/p/j2me-ctunes/):
libmpcodecs/img_format.c
libmpcodecs/img_format.h
libmpcodecs/vf_scale.c
libvo/osd.c
libvo/osd.h
libvo/vo_fbdev.c
mplayer.c
postproc/yuv2rgb.c
postproc/swscale.c
In libmpcodecs/img_format.c, libmpcodecs/img_format.c and libmpcodecs/vf_scale.c I added a few lines to return something to say 19-bpp is supported in RGB and BGR formats.

libvo/osd.c is interesting. I added a method called vo_draw_alpha_rgb19() which draws the alpha for 19-bpp.

In libvo/vo_fbdev.c, I disabled some code that was causing problems in ROKR and disabled clipping because it was done elsewhere. In addtion added code to initialize variables for 19-bpp format (i.e. r, g, b offsets and lengths. Each color is 6 bits long with 1 bit for alpha) and drawing alpha (using the method previously added in osd.c)

I fixed a few things in mplayer because there was some weird state change after EOF. It did not work correctly on ROKR. I don't remember what was wrong, but for some reason I added a PAUSE state after a file has been played. I used the slave mode of mplayer (see man mplayer for more details about the slave mode) to play media files. So mplayer was always running and when it is time to play a new media file I just pass the new filename from java to the running process that controls the mplayer process. So when a file has completed playing the state of mplayer used to end in PLAYING state. I did not want it to be in that state for some reason so after a play ended I change the state to PAUSE.

postproc/yuv2rgb.c contains the most important hack of all. It is the one that converts YUV data to RGB 19bpp. It was the most fun of all to write the code. Take data point for each pixel in YUV format and convert it to RGB and then fit it in 19 bpp. A lookup table is created up front and the table is used to do the conversions quickly in realtime when the video is playing. I do know much of MMX or SSE extensions (and not sure if ARM supports them) so I had to do all the conversion in C, but it wasn't bad at all performance wise. I got 24 fps for most video formats on a 320 Mhz XScale processor.

The final change is in postproc/swscale.c which converts YUV to packed RGB format.

That is the end of part 2 :). Pretty simple isn't it. Next time I will explain some audio hacks.

Comments

You are a god!

I'm now looking to use a hacked mplayer to view videos on Sony Ericsson phones, and it's really inspiring to read your blog.

God luck.
You are a god!

I'm now looking to use a hacked mplayer to view videos on Sony Ericsson phones, and it's really inspiring to read your blog.

God luck.

Popular posts from this blog

Attesting General Power of Attorney in SF

Recently I had to go through the motions of getting a General Power of Attorney (GPA) document attested in San Francisco. I am an Indian by birth. My parents were trying to buy a house back in India for me. Since I did not want to travel to India they needed a GPA so that they can act on my behalf to sign all the documents required to buy the house. The problem however is that they needed it urgently because the seller lives in UK and wants to get all the things done quickly so he can go back. My parents send me a GPA document that they obtained from a lawyer. This is a document that will give the power to my parents to buy the said property in the document on my behalf. The lawyer said that I will have to get the document attested at an Indian Consulate in USA. The closest one for me is in SF and I can drive there in about an hour from where I live. So I though it will be like a day's work to get all the things done. I looked up at their  website  for the procedure to att

XBMC / Boxee remote control android app

I have been writing a few android apps over weekends at home and during 20% time at Google. However I never actually released any of them in the android market mainly because they were quick and dirty apps that fit my needs but perhaps would not be appealing to the general public. One such app that I quickly wrote over a couple of weekends is a XBMC remote. The media center that I use at home is XBMC and I have always wanted to have more control and faster access to my media. Using my remote to navigate through the menus is not as fast. Especially when I wanted to queue a lot of music it is very slow. So I wrote this nice little app called "XBMC remote" for my android phone to control XBMC from anywhere :). Give it a try. Search for "xbmc" in android market and install it if you use XBMC as your media center. When you first launch the app you will start with this screen. You will have to setup your web server address, username and password (if required) by

gtkdocize not found

If you are ever configuring an app and see the message "gtkdocize not found" in Gentoo, then you need to emerge gtk-doc. I had some hard time figuring this out so I am writing it in my blog for the next time. When I saw that error message I did an "emerge -s gtkdocize". Usually it is that simple in Gentoo. But not this time. The emerge command returned no results at all. Then I searched for gtkdoc and still no luck. After searching in Google, I still did not have a solution. After thinking for a while I decided to try to search for gtk-doc. Bingo! That worked! Interestingly, this is my first post from my Virtual machine :-)