Is there an MP4 multiplexer which can compress the moov box?

[zinga]

Hi,

I've been looking around, but it seems that neither MP4Box nor MP4creator have options to create MP4s with compressed moov atoms (cmov atoms).

I may be missing/overlooking something, but does anyone know any (preferably free) multiplexer that will be able to do this?


Alternatively, I have been trying to write my own script which will compress the moov atom of an MP4, but have had no luck. The only two references I'm able to find are here (http://wiki.multimedia.cx/index.php?title=MP4#Decompressing_Compressed_moov_Atoms_With_zlib) and here (http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt). I've basically tried doing what's mentioned there (grab entire moov atom, deflate it, including standard zlib header, create new moov/cmov/dcom/cmvd atoms, insert back into MP4), however, I've had no success.

Would anyone be able to help me out on this?

Thanks a lot in advance :)

[mediator]

If the moov box is compressed, then it's no longer an ISO MP4-file. Only QuickTime defines/allows compressed moov boxes, so this a subtle difference.

Regarding the problem itself I unfortunately also don't know a tool which compresses moov (it should of course be possible to tell QuickTime somehow to do it).

[zinga]

Hi mediator,

Oh okay, thanks a lot for the advice! If it makes it non-standard then I guess there's probably not too much point.

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

EDIT: Maybe I should add:
The reason I'm asking is because I'm trying to stream MP4 (using the Flash player). Whilst this works fine for short "test" videos, I've noticed that with longer videos, the moov atom gets rather large. Is there any solution to reduce the size of the moov atom (apart from using a larger interleave duration)?

Thanks!

[Sagekilla]

I'm having the same issue as well. After (futilely) trying to remux a few of my videos I had already converted, I stumbled upon this whole issue of the moov atom being too large. I really don't understand why they used such a short duration (2 seconds) when problems can arise. Why not even allow passing of a statement to the decoder that says "Hey, the moov atom is present and is xxx big" so that it won't just skip over it because it's too large.

[mediator]

there is no real solution for this problem, but situation can be enhanced a bit:

- optimized layout of stbl tables: muxer needs to take care of this
- use movie fragmentation: not many parsers do support this in it's entirety.

So.... no common/real/good solution :(

[Sagekilla]

Ugh, it looks like I have to resort to plan B: Cut the movie into two pieces and make a playlist (invisible to the user) that would automatically play the second part after the second. Is that what movie fragmentation is, or is that another concept entirely?

[zinga]

Hi, thanks for the responses :P
I'm having the same issue as well. After (futilely) trying to remux a few of my videos I had already converted, I stumbled upon this whole issue of the moov atom being too large. I really don't understand why they used such a short duration (2 seconds) when problems can arise. Why not even allow passing of a statement to the decoder that says "Hey, the moov atom is present and is xxx big" so that it won't just skip over it because it's too large.
I'm not too sure I know what you're trying to say, but I can understand why the moov atom is placed at the beginning of the file.
Are you trying to say that it'd be good if, the moov box is found to be too large, that it'd be broken up and interleaved into the stream? Probably a good idea for streaming, though it makes seeking somewhat more difficult.


- optimized layout of stbl tables: muxer needs to take care of thisI've tried stuff like that, but, unfortunately, the size reduction is quite small :(

- use movie fragmentation: not many parsers do support this in it's entirety.
Hmm, I'm guessing this is the -frag option in MP4Box? Might try it - thanks :)


Also had an idea of GZipping the entire MP4 file, and (since it's being streamed over HTTP) send a Content-Encoding: gzip header (Flash should unpack it). All major browsers support gzip unpacking (and those that don't are probably incapable of displaying the Flash clip anyway), and apart from the slight extra overhead of inflating the data, it would work well, if it wasn't for IE6 not properly unpacking data being sent to it (can't actually confirm this myself; just found this (http://mentalized.net/journal/2007/07/31/warning_gzip_content_flash_player_and_internet_explorer_6/) whilst searching).
:(


Thanks for the suggestions anyway :D

[Sagekilla]

No, more like make it so that the moov atom includes a line where it says something like "start=30720 bytes. end=50000 bytes" so the decoder doesn't just skip over it because it was too large to download in 2 seconds. Of course you'd need support from the decoder so that it actually reads that portion! What you just described was fragmentation, which I believe mp4box already does. Doesn't solve the too large of a moov atom problem though.

Edit: To clarify, the player has instructions to download a file to finish before playing back if it cannot find a moov atom in it's entirety after downloading for 2 seconds. Fairly stupid and poor implementation, if you ask me.

[zinga]

The size of the moov atom is specified I believe (the 4 bytes before the "moov" ASCII string).
However, to skip downloading the portion, through HTTP, would require the use of additional ranged requests (and connecting over HTTP isn't the fastest thing). It would be nice if Adobe implemented something like this I guess (as well as ranged requests for seeking ahead)...

EDIT: tried remuxing an MP4 with MP4box, supplying a -frag 3000 param to it. Flash player doesn't play it :( (neither does MPC using it's MP4 splitter, or Haali's Media Splitter).

I guess I'll just have to give up on this one then.
Thanks again to everyone for helping!

[Lele-brz]

I had the same issue, I found out that using Matroska as a container can decrease dramatically the size of the header. So much faster start-up of the play.
I'm still looking for a way to do that in MP4, I tried the frag option but I don't think there are many players that can support that.

[zinga]

Hi Lele-brz,

I'd love to use MKV as well, but unfortunately Adobe only added support for MP4... :(

Thanks anyway!

[foxyshadis]

Did you have any luck with the gzip compressed download method? I'm interested in it.

[crypto]

there is no real solution for this problem, but situation can be enhanced a bit:

- optimized layout of stbl tables: muxer needs to take care of this
- use movie fragmentation: not many parsers do support this in it's entirety.

So.... no common/real/good solution :(
Did you try mp4creator (http://mp4creator.sourceforge.net) with the optimize option? It is exactly for these cases in HTTP streaming. The option should be used after all tracks have been added. I would also add a hint track on the video track.

Unfortunately I have overseen this optimize option and is is not accessable from the mp4muxer GUI. I will add it in the next version.