Anybody bored? I need help with converting a file format

[Helevitia]

Hi MURC

I recently purchased an Alpine head unit for my FJ. Alpine lets you change the wallpaper, but only ones that they create. boohoo! I, like everyone else that owns Alpine wants to put there own custom wallpaper. Some guy figured it out and has given many clues but won't write down the gritty details yet. Unfortunately it requires knowledge of a hex editor, and understanding of an MPEG-2 file and a bunch of other stuff I don't understand. I tried to download a hex editor and muck with the file, but I sat there scratching my head

If any of you feel like taking look on how to turn a bmp into a 2 frame mpeg file that is renamed with a .apn extension, I'd be willing to send beer, lots of BEER!

Here is some info to get your curiosity started

belive the following about APN files:

* The data is MPEG2 encoded--likely by a linux based encoding method
* The file is really 2 - 32k files appended together
* The file must be exactly 64k total (65,536 bytes).
* The files get to be their full size via padding bytes at the end (FF values)
* Windows Media Player will play the files if you have "Nero Video Decoder" installed by Nero 7 Ultra Edition (and maybe other versions)
* The duration of the files tends to make it hard to see but Windows Media player does play both frames
* I think the second file is for a diferent aspect ratio and/or maybe PAL. It may play on rear displays, I don't have one. The file on this forum can be split exactly in half and the files compare identical. I also tested taking an Alpine file, splitting it and appending it to itself--it loaded fine.

BTW - I attached a .apn file(renamed with a .txt extenstion so it would upload to the forums) to play with and I also attached a .jpg of the same file so you could see what it looks like. Oh and here is the link ot the forum where the guy figured it out

http://forum.ecoustics.com/bbs/messages/4/200512.html

[Helevitia]

OK, so I can see the "MPEG-2 Verification sequence" in the hex editor. Now I'm stuck again

[Helevitia]

OK, so the files starts with 0x2662. When I check MPEG Headers Quick Reference page, I don't see how that is possible.

EDIT: Oh, I see, the first 4 bytes are a mystery according ot the guy that figured it out. So 0xBA is where the header starts...I think.

[Helevitia]

Oh and I'm serious about the BEER

[schmosef]

do you know anything about how the mpeg2 needs to be configured? frames per second? resolution? field order?

all i know is what i read in your post but if i had to guess i'd say the two frames were for supporting interlacing.

[schmosef]

if you gave me some details on the mpeg2 setup i could try use an NLE to render two images as individual frames into a movie. Then email it to you so you could pad it and possibly modify the file headers, etc.

[Helevitia]

I'm not sure, but I'll post what I feel is the most relevant info.

Now for more technical tidbits from today's research...

If you don't have a basic understanding hex editors, file formats and image encoding, I'd recommend just skipping this post. I'm only going to answer technical questions pertaining to my research and/or new leads.

My guess is that the process of creating the MPG starts with saving a still image (720x480) as a PPM file in a program like Adobe Photoshop, then use that file in mpeg2encode (dang win32 binaries aren't working so I had to compile on my Fedora Core 5 system) from mpeg.org. Then use the tool with a .par file like mine below (except use your file name--my ppm is called sonic0.ppm):

MPEG-2 Verification Sequence
sonic%d /* name of source files */
q%d /* name of reconstructed images ("-": don't store) */
- /* name of intra quant matrix file ("-": default matrix) */
- /* name of non intra quant matrix file ("-": default matrix) */
stat.out /* name of statistics file ("-": stdout ) */
2 /* input picture file format: 0=*.Y,*.U,*.V, 1=*.yuv, 2=*.ppm */
1 /* number of frames */
0 /* number of first frame */
00:00:00:00 /* timecode of first frame */
15 /* N (# of frames in GOP) */
3 /* M (I/P frame distance) */
0 /* ISO/IEC 11172-2 stream */
0 /* 0:frame pictures, 1:field pictures */
720 /* horizontal_size */
480 /* vertical_size */
2 /* aspect_ratio_information 1=square pel, 2=4:3, 3=16:9, 4=2.11:1 */
4 /* frame_rate_code 1=23.976, 2=24, 3=25, 4=29.97, 5=30 frames/sec. */
7560000.0 /* bit_rate (bits/s) */
112 /* vbv_buffer_size (in multiples of 16 kbit) */
0 /* low_delay */
0 /* constrained_parameters_flag */
4 /* Profile ID: Simple = 5, Main = 4, SNR = 3, Spatial = 2, High = 1 */
8 /* Level ID: Low = 10, Main = 8, High 1440 = 6, High = 4 */
0 /* progressive_sequence */
1 /* chroma_format: 1=4:2:0, 2=4:2:2, 3=4:4:4 */
2 /* video_format: 0=comp., 1=PAL, 2=NTSC, 3=SECAM, 4=MAC, 5=unspec. */
5 /* color_primaries */
5 /* transfer_characteristics */
4 /* matrix_coefficients */
720 /* display_horizontal_size */
480 /* display_vertical_size */
0 /* intra_dc_precision (0: 8 bit, 1: 9 bit, 2: 10 bit, 3: 11 bit */
1 /* top_field_first */
0 0 0 /* frame_pred_frame_dct (I P B) */
0 0 0 /* concealment_motion_vectors (I P B) */
1 1 1 /* q_scale_type (I P B) */
1 0 0 /* intra_vlc_format (I P B)*/
0 0 0 /* alternate_scan (I P B) */
0 /* repeat_first_field */
0 /* progressive_frame */
0 /* P distance between complete intra slice refresh */
0 /* rate control: r (reaction parameter) */
0 /* rate control: avg_act (initial average activity) */
0 /* rate control: Xi (initial I frame global complexity measure) */
0 /* rate control: Xp (initial P frame global complexity measure) */
0 /* rate control: Xb (initial B frame global complexity measure) */
0 /* rate control: d0i (initial I frame virtual buffer fullness) */
0 /* rate control: d0p (initial P frame virtual buffer fullness) */
0 /* rate control: d0b (initial B frame virtual buffer fullness) */
2 2 11 11 /* P: forw_hor_f_code forw_vert_f_code search_width/height */
1 1 3 3 /* B1: forw_hor_f_code forw_vert_f_code search_width/height */
1 1 7 7 /* B1: back_hor_f_code back_vert_f_code search_width/height */
1 1 7 7 /* B2: forw_hor_f_code forw_vert_f_code search_width/height */
1 1 3 3 /* B2: back_hor_f_code back_vert_f_code search_width/height */

This is quite close to the original NTSC template file provided in the tar.gz--they just changed the comment and a few other settings. The "MPEG-2 Verification Sequence" string seems to finally show up in the right spot now. Now how to verify anything about this...

Whoo hoo! An MPEG headers quick reference. Now lets see here. How are we doing so far...?

I can see the start MPEG encoding sequence after 10 bytes. But its starting with 0xB3 instead of 0xBA like Alpine's stream... Ah! I finally got a 0xBA by muxing--using TMPGenc I went into File, MPEG Tools, Multpilex Tab, type MPEG-2 Program (VBR) added my mpeg2encode file and outputed it to a new file. Hmmm. Tons of padding but I'll assume its still valid for now. I've tried to mux with the mencoder from mplayer, but that had less than stellar results (wouldn't play locally).

The big mystery?

Alright that takes care of a lot, but I'm still in the dark on the first 10 bytes of the file. It looks like out of those bytes, only 4 are significant:


*pair1* *pair2* *start MPEG pack header*
0x** 0x** 0x00 0x00 0x00 0x00 0x00 0x00 0x** 0x** 0x00 0x00 0x01 0xba 0x44

I fail to figure out what those 4 bytes are
(hex, decimal, binary or otherwise). Whatever they are, they appear to be unique per encoded MPEG image. I did some swap testing taking those bytes from another Alpine provided file and placing them in another Alpine provided file. I did this for the first pair only, the second pair only and then both. All 3 versions failed to display an image on my unit (using distinct never been used 8.3 file names). These bytes seem to be required and must be correct. :-(

I just wish I knew if they were something like a MPEG transport stream header, CSS header data, a checksum or if Alpine is using it for something itself. I suspect its something non-Alpine and more MPEG though.

I've tried my hand at an all TMPGenc solution, however, the file always seems extra paddy with a required TMPGenc version comment that spooks me into thinking maybe that will never work. Also MPEG2STAT (http://www.slac.com/ian/mpeg2stat.html) was quite useful for helping get the .par file correct.

Hopefully that gives someone out there more to chew on. I think I'm going to have to take a break. I've been working this silly issue for over 24 hours straight already (yes I slept in between). Good luck!

and...

Daniel - Looks like it's just a single frame muxed MPEG2 movie. Though the one I downloaded says it is 640x480 ...


I think 640x480 is a side effect of the codec used to decode it. Every last one I have downloaded is 720 x 480--which makes sense for NTSC encoding. What was the file name of the one you used?

I'm not much for hacking file formats, but between all the DVD authoring tools on my Mac I would think this should be fairly easy to create basically a single-frame (duration of the 'movie' is 1/30 of a second) muxed MPEG2.

Hopefully the muxing will not also mux in a silent audio stream. That is one of the key differences between Alpine files and files generated by tools that let you mux video without audio.

My first attempt failed tonight (Editing tools just don't think a single frame is worth their time.. ).

Well if I understand enough of this now from my research... I would suspect the effects of your failed test (assuming you had a test file of 65,536 bytes) would be it "downloading" the file, but only showing up as a black background but you can still upload real APN files over your black image just fine. This would be because the first 10 byte header didn't have a valid checksum and length.

And I don't think I have the determination you have for this process, but...

Well I kinda think I have too much determination into this. I've got what I belive to be a solid method for making the alpine header information. I can take any half of an APN file, truncate off the header and padding and without being given any extra information, re-generate the same header and padding. This does bring me to a snag caused by a lack of patience on my behalf though.

Unless you make the header correctly, all correctly sized APN files will fail the checksum and it will not attempt to use the MPEG2 data leaving you with a black wallpaper. If you have a valid header, but incorrectly encoded MPEG2 data (i.e. your MPEG2 is a pure video data with no muxing) the unit will try to use the data leaving you with the black screen as before, but this time your unit won't read any discs. You can navigate the unit on all screens but it won't read even the disc it just read wallpaper data from (even in the same boot). It also won't let you select your other valid wallpaper data in the i-Personalize menu.

This is what has happened to me. I have an IVA-W200 brick. :-( But from the ashes, I build anew. I've decided to put my money where my mouth is--I bought another IVA-W200. I'm leaving the new one alone in my car but am taking a step back and trying to use the old unit for testing. My first goal will be to restore it to a useable state again. Hopefully this won't involve sending it back to Alpine. If I can fix it, I'm sure the information can help someone out and it will also make me much more capable to test things.

Thanks for digging into this. Hope you come up with a solution.

I hope so too. If all goes well, I plan to sell the development unit on E-Bay with a wallpaper of the user's chosing (in the correct dimensions of course). That will hopefully recoup most of the costs of buying a second unit.

Anyhow thats my update for this weekend. I've managed to at least get the old unit to power up in my apartment now--I just got to figure out how to "unlock it" (so I can access the "other setup" menu) and restore/blank the flash memory. At least now I don't have to run downstairs to try things. :-) Just wish I didn't have such a large brick wall stairing me down...

[Helevitia]

a little more...

On a technical note, I will say that the .par file I previously provided was close but had some flaws in itself. Also I would speculate that Alpine's discomfort with releasing the "DOS" (win32 console) tools they have for creating wallpapers is due to the unprofessionalism involved in releasing an "application" thats really not much more than a batch file calling a few applications powered by Cygwin. Top it off with no validation/error checking it could potentially create some bricked systems. Of course not having source to unify all the apps can also be a bit frustrating for them. Maybe my success in creating these will help Alpine speed the process of making a web service of their own available.

[ND66]

You would get a lot more help on this in the "Desktop Video" Forum, post it there.

.

[Helevitia]

Yeah, but this is more GH related.