Header removal compression


#1

This is something that is becomming more and more used now with the new version of “mkvmerge” !!! Quite a lot of recent mkv releases on the web are using “header reomoval compression” which basically means you won’t have any sound when playing your mkv movies through the WDTV

Quote

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.

Can this feature please be added ASAP.


#2

It’s already been mentioned in the FAQ and why not post a feature request in the ideas lab?


#3

warpath wrote:

This is something that is becomming more and more used now with the new version of “mkvmerge” !!! Quite a lot of recent mkv releases on the web are using “header reomoval compression” which basically means you won’t have any sound when playing your mkv movies through the WDTV

Quote

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.

Can this feature please be added ASAP.

If you use the latest version of MKVmerge 4.2.0 you will not have any vision either because that also has compression by default now. You have to turn off compression on both sound and video.

In short this is well known and you are posting old of date info. Note that the author of MKVmerge also did not bother to support it for 6 years.


#4

Finally using the feature is nice and all but why the heck set to default and don’t tell anyone?


#5

Exactly.   I have ZERO ISSUES with the guy adding it in as an option.   But as DEFAULT, it’s stupid.   It saves VERY LITTLE space, and breaks LOTS of players.  

He’s a naughty fellow, he knows it, and he’s having fun pissing people off.  ;)


#6

This has been fixed in firmware that’s in testing. I’m not sure when it’ll be released though.


#7

Guy_K wrote:

This has been fixed in firmware that’s in testing. I’m not sure when it’ll be released though.

Thanks Guy. I think I will just stay using ver 4.0.0 because you never know what else he may implement just for a laugh.


#8

Guy, that’s FANTASTIC news.   Would you please verify that they’re fixing both AUDIO *and* VIDEO header compression?   (MKVmerge 4.1.0 introduced the former as default, 4.2.0 introduced it in MP4 videos by default.)

By the way, this forum is so funny.   

It won’t censor the word “pissed” but it does censor the word “**bleep**” which is spelled f-o-r-k, as in the partner of a spoon.  That’s just so funny!  :smileyvery-happy:


#9

Fork isn’t even in the filter list.  But I do like the word pissed.


#10

**bleep** **bleep** **bleep**.

Uh, yes, it filters that utensil for me!  :)


#11

Tony, stick a **bleep** in it!

(See?  It censors me as well.  Bill is just priviledged – I’ll bet he could curse like a long shoreman here – tee hee).


#12

Mike, can you try it again?  I don’t have fork in the filter, but I had a variation that may have caused this.

[edit]

Let’s hope I don’t get tempted to cuss like a longshoreman.


#13

knife fork spoon.


#14

Techflaws wrote:

Finally using the feature is nice and all but why the heck set to default and don’t tell anyone?

Because he is an **bleep**. But why use the new ones at all, use the old ones - the work fine.

The word for the human posterior starting with an A and followed to by a s and possibly another s requires censorship? What a strange concept.


#15

whattheheck wrote:

 


Techflaws wrote:

Finally using the feature is nice and all but why the heck set to default and don’t tell anyone?


 

Because he is an **bleep**. But why use the new ones at all, use the old ones - the work fine.

 

The word for the human posterior starting with an A and followed to by a s and possibly another s requires censorship? What a strange concept.

 

I disagree. I think he’s doing it to try and force a change and I don’t know if I have a problem with it. As of today, compression saves very little space, but who knows where it might go? Imagine if it managed to save 15-25% in a year or two and your old WDTV Live wouldn’t support it… you’d be pissed AND you’d be running out of space faster then you would need to be. On top of that no one would be implementing it in firmware because everone thought it was “no big deal”. Do I think it is or will be a big deal? Probably not, but I’m often wrong about these things - mostly because people like Graeme Devine come along, invent a new type of compression and show me just how stupid I really am in the grand scope of things.

I do think the author went about it in a very sneaky way, but it is his software AND he’s giving it away. If you have a real issue with it download the source code, fix it yourself and give it away to others yourself. I would, but I honestly don’t feel like spending the time to fix it when all I have to do is remux or change a couple of options when muxing the first time.

Bruce “Keepin’ it REAL” Arnold


#16

Note to all:  This is FIXED in the PLUS Beta released today.


#17

TonyPh12345 wrote:

Note to all:  This is FIXED in the PLUS Beta released today.

 

 

Hopefully!!


#18

Tested and confirmed with three different file sets using MKVMerge 4.1 and 4.2.

Some time ago I created two test files, one with MKVMerge 4.1 (Audio Header Compression enaled)

and MKVMerge 4.2.0 (Audio and Video Header Compression.)

Before installing the update:

4.1: no sound

4.2: no sound and no video, and it pretty much wouldn’t play ANYTHING after the attempt.

After the update:

Both work perfectly fine.  :)


#19

I was so excited to see that this Beta version was supposed to fix the MKV audio problem.  I rushed home to upgrade only to find that in my case, it did not.  I still have no Audio on my MKV files.  I’ve gone under settings and verified the version number.  I’ve also rebooted a couple of adddional time just in case.  I also have a WD TV Live, and that plays the same MKVs with no problem whatsoever.  I use Handbrake, all default settings.  I’m not sure how that is effected if at all by the MKVMerge.  Any ideas about what the issue might be would be appreciated.  Thanks


#20

rcarr wrote:

I was so excited to see that this Beta version was supposed to fix the MKV audio problem.  I rushed home to upgrade only to find that in my case, it did not.  I still have no Audio on my MKV files.  I’ve gone under settings and verified the version number.  I’ve also rebooted a couple of adddional time just in case.  I also have a WD TV Live, and that plays the same MKVs with no problem whatsoever.  I use Handbrake, all default settings.  I’m not sure how that is effected if at all by the MKVMerge.  Any ideas about what the issue might be would be appreciated.  Thanks

Please post the Mediainfo for your files. The problem you are reporting might not be the header removal compression issue.