Invalid file MKV

[marten72]

I found a solution regarding MKVmerge and only getting sound but no video. It seems to be changes to the header compression in MKVToolnix v 4.2.0 that causes the problem. Solution:
1) Downgrade to prior MKVtoolnix version 4.1.1
2) Use MKVtoolnix 4.2.0, but set "Compression" to "None" for each track (video and audio). This can be found in the "General Options" tab after you load a file and select a track.

Maybe this could be a problem for more of you soon ad hopefuly there will be included in a future upgrade.

Se original post: http://www.mpcclub.com/forum/showthread.php?t=24821

[tachita]

yes , it is not the first version that create problems.

most of times, is better to eat the grass that you know.........

[scorpioso69]

For cmpleteness I have pasted this nice explanation of the particular MKV issue some of us may be experiencing.

Re: BUG: MKVToolnix/mkvmerge 4.2.0 and Tvix 6600 incompatible

--------------------------------------------------------------------------------

Originally Posted by DVE 

Well I didn't want to bother anyone here with tech detail, but I guess it's necessary to avoid even more confusion and explain why it's the MP developers fault and not the fault of latest mkvmerge. Please read this from the Matroska FAQ:

'Why does audio or video not play anymore since v4.1.0 (e.g. MP3, AC3, DTS audio tracks, h264 video tracks)?'

The Matroska specifications know a feature called "header removal compression". This allows a muxer to keep a certain number of bytes that are identical for each frame in the track headers removing them from the individual frames. This reduces the size of the tracks significantly without altering the content as a demuxer can add the bytes found in the track headers to each frame during demuxing.

Starting with v4.1.0 mkvmerge uses header removal compression for a couple of track types by default. These include AC3, DTS and MP3 audio tracks as well as Dirac and MPEG-4 part 2 (aka. XviD/DivX) video tracks. The user muxing a file may disable it by explicitely selecting 'none' as the compression scheme for such a track.

If your player has difficulties playing such files then it is a bug in that player or in the demuxer but not in mkvmerge. This feature has been part of the Matroska specification since more than six years, and there's no excuse for refusing to add support for it. 

Please remember: Matroska has nothing to do with the players chipsets. Neither Sigma nor Realtek chipsets can understand Matroska containers. So all MKV files need to be demuxed by players firmware (which is a small Linux OS on most systems) and the respective streams handed over to the chipset for playback.

Regarding that all PC playback filters (either for Windows or Linux) work just fine, shows that media player firmware developers did not respect full Matroska specs up until now. Either out of convenience or out of laziness. I don't know, ask them yourself.

And it is NOT the first time that Matroska specs are not complied to. Almost any hardware player discards the "default track" or "forced track" flags for audio and/or subtitle streams which are part of the specs for years. While PC playback filters respect these flags and play the tracks that are marked by default in the Matroska files, hardware media players stubbernly just play the first audio/sub track they find.

I hope now you understand why authors of Matroska Tools are the wrong people to blame. 

[tachita]

please dont be fooled by complex answers........

what you see there is a compresion that can be handled by computers and not by media players.....

it is out of standard !

maybe tomorow, this compression, it will be a standard....until then .....

[jer1956]

The problems is the expectation that mediaplayers will play everything however it's packaged or encoded. Mediaplyers will only play files where the contents conform to the players spec, even if they are packaged using a flexible package like MKV.
Rember with  mediaplyer it's the chip which decodes, and the puny support processor which unwraps. Not a problem with  a normal package where all codec functions are inside the contained media.  This header issue arises becuase mastroska have chosen to be clever and merge the two functions. This is a moot point with a PC as both tasks are done by the CPU. This header is an option. That dosn't mean a user can chose or not chose it as they see fit. It means it can't be made mandatory because it isn't appropriate in all circumstances. A device which can't support an option isn't in breach of the standard.  The default should be the option setting which justifies it being an option, i.e off! The GUI guys should ask the simple question - Why is this an option? The answer is"Becuase it can't be on (or off!)  in all circumstances. That's why Off should be the default in this case. That should be the case with all options.  Users shouldn't be having to download older versions of MKVMerge where the default was in the correct setting.
 
Look at Handbrake. They recognise that different hardware require different profiles and give you the option to chose the right one for you. Why can't MKVMerge do the same?  

Mediplayer makers could avoid a whole load of hassle and only support the streams the chip understands. Everyone would then be left to strip out the contents of general purpose wrappers such as AVI and MKV. Indeed once you turn the MKV header on MKV becomes a codec, an unsupported one at that!

[tachita]

for new guys,
use the method described up,
or just follow this:

http://www.mede8erforum.com/index.php/topic,3010.msg19619/boardseen.html#new