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.
The proper solution is to ask the vendor of your player to support this feature. A temporary solution is to re-mux such files turning off extra compression for all tracks.
So its Wd´s turn to make a new Firmware for the WD TV, the Problem is not mkvmerge!
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.
The proper solution is to ask the vendor of your player to support this feature. A temporary solution is to re-mux such files turning off extra compression for all tracks.
So its Wd´s turn to make a new Firmware for the WD TV, the Problem is not mkvmerge!
We have been all through this on other threads. The problem may be the WDTV but also the MKVmerge developer for introducing something that he knew would not work with most hardware units. He is purely trying to make a point. WD know about it and maybe at some point in time they will update the firmware but until that time everybody will have to use an old version of MKVmerge or remember to turn off the compression every-time they use the program. It makes you wonder what else has not yet been introduced. Personally I have now lost confidence in MKVmerge and I won’t be updating mine from 4.0.0. The fact of life is that I purchased my WDTV and I need files that will work. I have no interest in joining some crusade by the author of MKVmerge into getting manufactures to follow the letter of the spec. I note that the author did not bother to follow the spec for the last 6 years so I question his motive for doing so now. Perhaps he is getting too big for his boots and he thinks that he can control manufacturers because he has a popular program.
“…he can control manufacturers because he has a popular program.”
Ten to One he’ll be successful.
I don’t agree with his approach, but I’d about bet it’ll have the desired effect…
He may be able but he is also upsetting a lot of users by doing so. Also other programs like popcorn MKV audioconverter have been updated to take care of this issue.
The point is what can we do if WD do not want to update their firmware. We can either have no sound, or remember to manually switch off compression or just use the 4.0.0 version. As I said my purpose in life is to watch my videos not join a pointless campaign particularly when it appears that the MKVmerge author could not bother to implement this part of the spec for years.
Thanks for the temporary solution while we all anxiously wait for a WD firmware update to address the issue. My only question now is: how do you get such detailed video file properties/media and Codec information as the one in this post?
Thanks for the temporary solution while we all anxiously wait for a WD firmware update to address the issue. My only question now is: how do you get such detailed video file properties/media and Codec information as the one in this post?
I a new to the WD TV Live, and am also having this problem with mkv files.
I’ve downloaded mkmerge and remuxed with compression set to none and this still seems not to work for me. I did upgrade my firmware yesterday would this have anything to do with it.
Here is my file after remuxed:
General
Complete name : E:\Movies\Movie_Encoded.720p remux2.mkv
Format : Matroska
File size : 6.55 GiB
Duration : 2h 28mn
Overall bit rate : 6 332 Kbps
Encoded date : UTC 2010-11-21 16:49:52
Writing application : mkvmerge v4.4.0 (‘Die Wiederkehr’) built on Oct 31 2010 21:52:48
Writing library : libebml v1.0.0 + libmatroska v1.0.0
Audio
ID : 1
Format : DTS
Format/Info : Digital Theater Systems
Codec ID : A_DTS
Duration : 2h 28mn
Bit rate mode : Constant
Bit rate : 1 510 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 24 bits
Video delay : 11ms
Stream size : 1.56 GiB (24%)
Language : English
Text
ID : 2
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Language : English
The audio problems are most likely the same bug in the new firmware that’s troubling many other users. You might want to downgrade until WD sorts things out.
The other thing I can see is the 5 reference frames in your encodes. You might want to only use 3 or 4 reference frames in future encodes you make – even though you’re “allowed” to go as high as something silly like 32 reference frames, most players simply don’t have the buffer space to deal with such insane levels. I’d thought I’d read that the WDTVs only have enough physical memory to buffer 4 reference frames, so your 5-ref-frame encodes might not always play back cleanly on WDTVs (and if you use a lower number, your encode will go quicker as well ).
).
