Codec quirks in hardware decoder?

[／人◕‿‿ ◕人＼]

I really haven't done much testing on this, but I've noticed a number of quirks with the stock video/music player (or possibly the hardware decoder).
Is this just me, or has anyone else noticed any of the following?

MKV with 1280x720 H.264 high@L4.1 + Vorbis stream:
Seriously laggy video. Have tried reducing the H.264 stream to baseline@L3.0, but same result.
mVideoPlayer shows exactly the same behaviour, suggesting possibly an issue with OS itself?
MX Video Player only seems to run this through the software decoder, and works fine.

MP4 with 1280x720 H.264 high@L4.1 + AAC-LC stream:
Simply remuxing the above video stream into MP4 seems to get rid of the lagginess. But seeking is horribly broken here. Audio seeks fine, but video doesn't, leading to audio/video desync.
MX Video Player (HW decoding) has exactly the same issue. The SW decoder is fine though.
Interestingly, Dice Player, using HW decoder, doesn't have this bug. What's up with that?

44.1kHz HE-AAC music in MP4 container:
Seems mostly fine, but I've noticed "clipping" artifacts in some places of the audio. These don't show up using a software decoder.


Also, is there a more definitive guide on what exactly is supported in terms of media/codecs? I've seen this [http ://developer.android.com/guide/appendix/media-formats.html] (remove the space), but it's inaccurate, or at least lacking information. For example, some things I've picked up:
- MKV: header compression (which is enabled by default in mkvmerge) is not supported - will show up as invalid video if you have it
- H.264 support up to High profile @ level 4.1, level 5.0 won't play back (on HW decoder at least)

Thanks

 

[／人◕‿‿ ◕人＼]

Okay some partial solutions if anyone finds this.

I'm guessing the demuxers in Android are buggy/partially broken. I'm guessing DicePlayer uses its own demuxer and feeds the audio/video to the hardware decoder, whilst MX probably sends everything to the system to decode.

Haven't done much testing with MKV, so it's still stuttery.
The MP4 issue seems to be with the frame rate. I believe some devices have trouble with frame rates with high rationals. MP4Box specifically sets 23.976fps to 24000/1001, which fixes the broken video seeking behaviour. Interestingly, using a shorter GOP seems to have an effect if you use a 'broken rational frame rate', though if you use a good frame rate, GOP doesn't seem to matter much.
As for video, it seems that 'x264 --profile high --level 4.1 --preset placebo' always works (haven't tried open-gop). Do note that I originally just fed the x264 MP4s, which don't seem to work as x264 sets high rational frame rates (so encode to .264 and mux with MP4Box separately).

For the audio issue, it seems that applying a 5dB cut before encoding stops the clipping from happening. It only occurs with audio that pretty much maxes the volume.
AAC (without SBR), Vorbis and MP3 seems to work fine without having to do this, so there's something with AAC+SBR causing the decoder to clip the audio (probably something in the decoding chain which pushes the volume too high).