10-14-2010 05:25 PM
Does anyone know what the image format for indivual frames in the RIMM streaming file format is? I was able to use the sample code that is posted here:
to open up a the video recording API and start streaming video ... the parser seems to be working and saves key frames to the filesystem but I have no idea how to interpret these frames.
I know there is a descriptor which will signal MPEG4 or H264, but does this apply to the individual frames? I am woefully ignorant about video compression and imaging tech... A senior dev here suggested that the frames might be in some format like YUV or RGB, but my gut says that if the streaming video is encoded or compressed, then the entire thing will be affected... isn't that right?
Thanks a lot for any help.
I'm sorry for cross posting this from Stack Overflow, but it's inevitable... here's my original question there:
10-19-2010 02:19 PM
The RIM format is documented here:
RIM proprietary video format (RIMM streaming file)
10-21-2010 11:06 AM - edited 10-21-2010 11:07 AM
Thanks MSohm, but I know. Actually I posted a link to the same set of docs in my original post which you might have missed. I believe that the RIMM format is a container which is holding the frames in some other encoding, like MPEG or H264. My question was about this format.
I've since gotten an email from a developer contact at RIM who said that if the video encoding is MPEG then the key frames will be JPEGs.
Does anyone with more experience with video compression and encoding know if this is true? When I tried to do EncodedImage.createImage() with the byte array supposedly containing a key frame, it threw an IllegalArg exception.
10-21-2010 02:58 PM
Get the frame data and read through it, if it doesn't have tags that match JPEG then it's not JPEG. If you simply passed it into EncodedImage.createImage and it threw an exception then it rules out BMP, WBMP, JPG, PNG, TIFF, and GIF.
Since we got those out of the way look for a "magic" that might identify it, patterns in the beginning of the file (end would be data). Go to a normal MPEG video and get the frame out of that (there are tools to do that) and see if some data elements are the same.
You play around with it enough you can find out the format of it.
On a side note can you try and save part of the RIMM data (header and a frame or too), it might make it easier for someone to try to figure it out without needing to write a app of their own to extract data.
10-21-2010 03:21 PM - edited 10-21-2010 04:42 PM
Thanks, good suggestions, I'll try some of them.
As for saving part of the RIMM header, if someone else wants to take a look at it feel free - the code is available from
10-21-2010 04:15 PM
How did I miss that? I might try it out later. The other reason for asking you for the code was because it is in whatever format you recorded it in where as I might end up with something else (though there are not many options it can still happen).
10-21-2010 04:41 PM
I spent the afternoon doing some research and trying it out on a device...
When I write out individual key frames as parsed from the KeyFrameOutputStream class they always begin with 0x000001b6. This doesn't seem to be a JPEG start code, but instead an MPEG reserved start code ... I do not know enough about video encoding to understand how to use this information though. Just thought I would add what I've found.
10-22-2010 12:32 AM
Not bad, I would say try to copy the data over to the desktop and find a utility to convert to a image. If it doesn't work then you will have a fun time trying to figure Otherwise you know it follows the standard and can find some source code to parse it.
04-11-2011 10:41 AM
Hey guys, were you able to decode the video frames into pixels?
I can read the frames all fine, but FFMPEG just gives me green pixels for both H264 and MPEG-4 video.
I DO however have a codec that works in windows, the mc_demux_mp2_ds.ax from blackberry, so I think Blackberry should stand up and document their format with a working example.