Now that (as I believe) I’ve fixed remaining reconstruction bugs in VX decoder, why not do a quick comparison of various video codecs developed by Actimagine and see how they differ (if at all).
There seem to be the following codecs:
- Actimagine (VX)
- Mobiclip (Mods)
- Mobiclip (Moflex for 3DS also there’s a version of it for PC known as Mobiclip HD)
And while they all are based on H.264 with finer block partitioning, there are some differences as well.
Proper structure. The original VX codec used quantiser derived from FPS and all frames were encoded in the same way, while the latter codecs have I-frames and quantisers are transmitted for each frame (as delta for non-keyframes).
References and motion compensation. VX had three previous frames as reference ones, later codecs increased that number to five. VX had fullpel motion compensation, later codecs use halfpel MC.
Data coding. VX relied on Elias Gamma’ codes for all codes except coefficient coding, later codecs use codebooks for most coded values. Also while VX coded residue in 4×4 blocks in H.264 way (starting from the end and with tail of ones coded explicitly), newer codecs use separable transforms and the usual (zero run, coefficient level) coding. Additionally only nine coding modes out of twenty four have survived after VX (intra prediction, MC with motion vectors coded and splits).
Overall, while all those codecs are related, there are large differences between VX and later Mobiclip variants and the only differenced between Mobiclip variants are colourspace (Mods uses YCoCg model, HD uses the proper YUV model), quantiser being clipped to 12-52 range, and block mode codebooks being different.
As I mentioned before, somebody has reverse-engineered decoders for Mobiclip (and a quick check on codebooks used tells me that Mobiclip HD and 3DS versions are the same) so if somebody needs them it should not be that hard to write a decoder.
Do you have more than one MOHD sample?
No, but IIRC you can encode some using that Mobiclip Multicore Encoder.
Well, MOHD is different, if it uses same rangecoder as that reversed code than it reads it in different byte order.
Sounds strange, it should simply use bitreader and no arithmetic coding (it was deemed too slow for handheld consoles at the time). And when I looked at
mohd.axit had just gamma codes and static codebooks.So mohd.ax stores raw numbers in bitreader to signal intra frame?, and not bytereader + shifts like that github repo?
I think that encoder you mentioned does not support encoding MOHD avi files.
It’s the same thing. You can get one bit by shifting bit buffer by 31 right or by shifting it by one bit left and observing carry flag.
And you can expect both of them to be derived from the same codebase so the same tricks were employed in ARM and x86 version.
I have no idea what would work on producing MOHD AVI files though.