Well It looks like after all to be a container problem and not a codec issue, how could I otherwise retrieve the information?
You can salvage your videos manually unless gruntster/mean provides a work around in avidemux.
download MKVToolNix 02 Sep 2012: Released v5.8.0
open video causing problems with mkvinfo, look for TrackID's:
...
+ A track
| + Track number: 1 (track ID for mkvmerge & mkvextract: 0)
| + Track UID: 1
| + Track type: video
...
+ A track
| + Track number: 2 (track ID for mkvmerge & mkvextract: 1)
| + Track UID: 2
| + Track type: audio
The bold above shows you track ID to use with mkvextract. In this case video is at track 0 and audio at track 1.
These become in the command line
0:video001 and
1:audio001 tracks = required mode, -f = parse fully
Filenames: whatever works for you, keep it recognizable for ease of working.
mkvextract tracks notworking.mkv -f 0:video001 1:audio001
Warning: Track 0: NAL too big. Size according to header field: 4, available bytes in packet: 2. This NAL is defect and will be skipped.
Extracting track 0 with the CodecID 'V_MPEG4/ISO/AVC' to the file 'video001'. Container format: AVC/h.264 elementary stream
Extracting track 1 with the CodecID 'A_EAC3' to the file 'audio001'. Container format: Dolby Digital Plus (EAC3)
Progress: 100%
You should now have 2 recovered tracks: video001 and audio001.
Start
mmg -- a GUI for mkvmerge.
Add video001 and
add audio001 and Start muxing
You should now have a playable mkv, don't forget to switch compression header off.
Source, documentation and downloads @
MKVToolNix