Software-only video decoder in J2ME
I have developped a software-only video decoder, written entirely in pure J2ME MIDP/2.0. It decodes a 176x144 video at 12 fps. The codec is proprietary and has been developped specificly for that purpose. With this stuff, it is possible to play a video from a midlet (HTTP streaming supported) without relying on the video player installed on the phone (Oplayo, RealPlayer, etc...). The quality is not bad, and is similar to 3GPP. Encoding rates vary between 120 and 170 Kbit/s. It supports real-time overlays with transparency, so that you can put a translucent image on top of the video. Landscape mode is also supported.
I would like to have your opinion about this. Do you think this is something that can be valuable ? Do you see any immediate market for this ? Or do you think that this kind of initiative can't be seriously used since everybody today is focusing on MPEG4/3GPP. I am currently thinking on bringing this technology to the open source world but I need your ideas guys.
[1003 byte] By [
nmadrane] at [2007-11-26 12:05:42]
# 1
What you've done is great.
But. (There are always some buts). Who would be interested in a J2ME video decoder? Lets see. JVM vendors? JVM vendors licensing their JVMs to some hardware vendors (or device vendors). These platforms (devices) already have video, because they have to have it (even if they dont have Java VM) for MMAPI support, video playback, etc.. So mostly JVM vendors just integrate their JVM code with existing video decoders.
Also, some JVM vendors have their own video players and therefore they have some budget behind it.
You could think about J2ME applications market, maybe you should try to provide some demo version for downloads and check the feedback.
Cheers,
Andrew
# 3
I've desperately trying to find someone who has already implemented a MIDlet that plays video and mp3 at the same time.
Have you ever heard about someone who's done this before?
Notice that it's 2 players here: a video (3gpp) and an mp3 player are playing at the same time.
My MIDlet is a dancing game where you select a song and command a character to make dance moves.
I've been having problems on some phones because when I start the video, the mp3 will stop playing. In other words I can't have the 2 players playing at the same time.
-Thanks
# 6
For those interested, I can send you a preview. Just send me an email at nmadrane@mn-rlab.com with the model of your phone and I will send you a JAR containing a video clip encoded with my codec.If everything goes ok, I will create a dev community around this stuff.Cheers
# 7
JoaoAndrioli,You should have a look at the possibility to create your own MMAPI DataSource. That way, you should be able to "multiplex" audio and video into a single logical stream. However I am not sure if this will work with 3GPP.
# 8
Meerloh,Both the container and the codec are proprietary. The codec is CPU intensive for the coding phase but is very fast during decoding. Recent experiments show that we can achieve 260x180 at 15 fps with alpha overlay on recent phones.
# 9
Andrew,
Yes the J2ME application market is definitely where I should go. There is no way, for a J2ME application developer, to deeply integrate a video player into its own midlet. I mean, no way to overlay something (subtitles, logos, ads), no way to place the video frame at a certain position in the canvas, no way to access the decoded frames, etc. This is possible with my codec.
The compression ratio is not as good as 3GPP but is suitable for 3G/HSDPA streaming. Furthermore, as I said, HTTP streaming is supported.
