FreeAgent Theater and GoFlexTV

[JacksonW]

Matroska has a compressed header feature that is now the default in mkvmerge. The current version of the firmware (1.55) does not support this standard feature and won't play these files. Please fix this bug! I purchased this because of its support of these files.

http://www.matroska.org/news/compressed-headers.html

[noobie]

---

JacksonW wrote:

Matroska has a compressed header feature that is now the default in mkvmerge. The current version of the firmware (1.55) does not support this standard feature and won't play these files. Please fix this bug! I purchased this because of its support of these files.

http://www.matroska.org/news/compressed-headers.html

---

+1... 

Thanks for posting this...  I haven't came across this problem yet, but it is good to know.

From the above info looks like WDTV has the same issue, however Popcorn Hour has a FW fix for it.  So adding compressed header support should be very doable for Seagate.    For time being users experiancing this problem have to use the workaround (mkWDclean from mkclean toolset).  

[Tinwable]

With mmg (mkvmerge gui) you can just select Compression to none. 

For those who aren't aware of what the Header Compression does, according to Mosu's faq:

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.

However, after proforming several tests with standard movies, using both compressed & uncompressed, & I can see no real difference in the size of the mkv, other than maybe a few 100 to 1000k.

[noobie]

---

Tinwable wrote:

With mmg (mkvmerge gui) you can just select Compression to none. 

For those who aren't aware of what the Header Compression does, according to Mosu's faq:

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.

However, after proforming several tests with standard movies, using both compressed & uncompressed, & I can see no real difference in the size of the mkv, other than maybe a few 100 to 1000k.

---

Thanks for sharing this info   This should be part of future workarounds sticky thread.

I guess Matroska guys are pushing hw manifactures to comply with the their standards, which were never in affect untill now.    I do agree with you if the difference is 100k to 1mb in your tests, what is the point of this comotion?    I guess we have to remeber to always turn off header compresson when encoding files.   

[nomadelmundo]

For clarification, click on the individual tracks, chapter and tags for each  .mkv file one at a time using mkvmerge GUI (or MKVtoolnix for mac OS) and then select the 3rd tab with "Extra Options" and select compression setting to "none"

This will solve the blank screen issue playing .mkv files formatted with x264 rather than H264, and it will work on NTFS formatted hard drive just fine (not a Fat32 issue). The WD players have similar issues. Currently using 2.20 firmware for Theater+.

Hope this helps. It took me 6 hours of frustration to figure out, so hope this will make it quicker.

[tony55]

Ver. 140 of MKVToolNix does not have autoheader comression. My understanding is that the latest ver. of this software has the option to turn it of as a default setting. But,I haven't tried it. 140 works just fine for me.

Also, it might be worth knowing that the Fat+ doesn't like Partially muxed MKVToolNix files. In

using that program, everything should be muxed out than remuxed by adding in whatever stream changes you want to make.

Tony

[bodhi78]

---

tony55 wrote:

Ver. 140 of MKVToolNix does not have autoheader comression. My understanding is that the latest ver. of this software has the option to turn it of as a default setting. But,I haven't tried it. 140 works just fine for me.

Also, it might be worth knowing that the Fat+ doesn't like Partially muxed MKVToolNix files. In

using that program, everything should be muxed out than remuxed by adding in whatever stream changes you want to make.

Tony

---

Tony,

What's a partially muxed MKV file? is it like when you mux a new audio stream? into an MKV file that already has an audio stream (that you remove and replace with the new stream)?

Thx

[tony55]

Bodhi,

That's exactly what I meant.

Unless everything is demuxed into their streams before something new is muxed in or something is just taken out, the Fat+ takes too long to read the new MKV. My WD player will play these but they take about 15 seconds to load in the WD. The fat+ just gives up and will not play them.

For example, if you just want to add an AC3 file to an existing MKV you should mux out everything in the MKV and than add it all back in.I use MKVcleaver to do the de-muxing and MMG 400 to mux everything back in.

Also let me correct my previous mention of MKVToolNix ver. 140. I meant to indicate Ver. 4.00 Any problems I've had with the Fat+ and MKVs are a result of misuse of MKVToolNix.

Tony

[bodhi78]

Thanks! it's good to know. I'm sure I will have a need to do that.