View Full Version : MP4Box in GordianKnot
Elias
10th April 2005, 14:13
*.ogm and *.mkv are supported in GordianKnot. From my experience with MP4Box, it's totally rock solid stable and ass-kicking. So, I was wondering why not add it in GK with a GUI developed for GK, or just borrow Mezzanine's MP4BoxGUI? I think this would rock. IF GK would implement its own GUI for MP4Box, I think it should be similar to the BeSweet GUI found in GK.
Kurtnoise
10th April 2005, 14:28
GK uses VirtualdubMod to mux the files...So, we can't create mp4 files with this tool. That's why we can't use mp4box directly under GK.
But a GK-like especially dedicated to mp4 will be great. ;)
Elias
10th April 2005, 14:41
Originally posted by Kurtnoise13
GK uses VirtualdubMod to mux the files...So, we can't create mp4 files with this tool. That's why we can't use mp4box directly under GK.
But a GK-like especially dedicated to mp4 will be great. ;) Yes, however, I think that would be redundant because really, it's not like it's impossible for the developers of GK to make a tiny change so that when mp4 is the output container, it uses MP4Box for muxing.
bond
10th April 2005, 14:53
Originally posted by Kurtnoise13
GK uses VirtualdubMod to mux the files...So, we can't create mp4 files with this tool.indeed, and this has been discussed indeed pretty often already
moved to gknot forum
Doom9
10th April 2005, 15:59
to make a tiny change so that when mp4 is the output container, it uses MP4Box for muxing.uhh.. you obviously don't write software. I encourage you to look at the source code of MeGUI to see just how much code it really takes for the MP4 part. And the latest sources aren't out yet - they contain a lot more logic geared towards MP4 (separate credits).
Plus, since GKnot supports x264, separate credits will be problematic because of what is mentioned here: http://forum.doom9.org/showthread.php?s=&postid=637120#post637120 .. so you no longer have the liberty at freely configuring the codec (and the problem might apply to other codecs as well.. I'm also having some weird issues muxing raw xvid streams), then there would be the need to support AAC audio encoding as well. So all in all, it's not something you can quickly write in between getting home from work and dinner.
Kurtnoise
10th April 2005, 16:05
Originally posted by Elias
Yes, however, I think that would be redundant because really, it's not like it's impossible for the developers of GK to make a tiny change so that when mp4 is the output container, it uses MP4Box for muxing.
Well...for my point of view, it will be better and easier to create a new GK_like app instead of modifying the current code of GK. (to avoid to create new bugs by example ;))
A simple task for users can be a complicated task for programmers sometimes...;)
[edit]Doom9 too fast...
Elias
10th April 2005, 16:17
Originally posted by Doom9
uhh.. you obviously don't write software.... So all in all, it's not something you can quickly write in between getting home from work and dinner. You're right, I don't. But still, I find it very hard to believe that letting MP4Box mux the files instead is such an excruciating task. But I could very well be wrong here.
Originally posted by Kurtnoise13
Well...for my point of view, it will be better and easier to create a new GK_like app instead of modifying the current code of GK. (to avoid to create new bugs by example ;))
A simple task for users can be a complicated task for programmers sometimes...;)That would rule, but imo mp4 output is the only thing GKnot lacks :)
Doom9
10th April 2005, 17:22
better start believing.
And then there's the issue with overhead (nobody has come up with a reliable formula for the mp4 overhead and by the looks of it, it varies by codec used), and even though mp4box may support AVI input.. there's always the issue with properly extracting the raw video from it (you can search for bond's posts on this issue.. it's a rather nasty one).
len0x
10th April 2005, 20:08
Originally posted by Doom9
nobody has come up with a reliable formula for the mp4 overhead and by the looks of it, it varies by codec used
Btw, what kind of overhead calculation do you use in MeGUI now for mp4?
Doom9
10th April 2005, 20:51
10.4 bytes/frame when using B-frames, and 4.3 without any. Though, the numbers I've gotten back so far (unfortunately either very few people use MeGUI or they just don't bother sending me back the stats), for x264 12.0 bytes/frame seems to be a reasonable assumption.. now I don't know if the ateme muxer (I got those values from ateme) is more efficient or if it's the codec. And as for the other codecs, I have no reliable values whatsoever :(
len0x
11th April 2005, 10:38
So those values are all for x264? And is it total overhead or without audio interleaving?
Doom9
11th April 2005, 10:59
Well.. I get audio either as raw AAC or MP4. Muxing a raw AAC into MP4 actually reduces the filesize somewhat but so far I have not properly investigated this.. so I just assume it is roughly the same size (the difference is not really breathtaking). So, basically this is the video overhead.. since I start with a given audio size, I don't have to take audio overhead into account (I also add the raw video stream to the audio MP4).
bond
11th April 2005, 12:21
adts "raw" aac is bigger than the same stream in .mp4 as in .mp4 the headers arent always repeated, but stored only once
something similar is the case afaik for raw .264 streams, as all mp4 muxers store the SPS/PPs headers only once, but i am not sure if these always really leads to a reduction of the filesizes (sometimes its indeed the case)
Doom9
11th April 2005, 12:50
@bond: from all the feedback I've gotten, plus my own experiments.. putting a .264 file into an mp4 with mp4creator gives a 12 byte/frame overhead (regardless of whether you mux the raw stream into an audio-only mp4 or create a new mp4 from scratch). That's half of what AVI produces, plus we don't have the audio overhead which can be considerable when putting VBR audio into an AVI.
Elias
11th April 2005, 12:53
So wait a second, beside the difficulty of making MP4Box mux video/audio files instead of VDubMod, is this frame overhead the only issue for GK not supporting mp4 output?
bond
11th April 2005, 12:59
Originally posted by Doom9
@bond: from all the feedback I've gotten, plus my own experiments.. putting a .264 file into an mp4 with mp4creator gives a 12 byte/frame overhead (regardless of whether you mux the raw stream into an audio-only mp4 or create a new mp4 from scratch). That's half of what AVI produces, plus we don't have the audio overhead which can be considerable when putting VBR audio into an AVI. additionally mp4box will need 2 bytes less per frame than mp4creator on most avc streams, as its able to set the nal header length to 2 bytes (if possible) whereas mp4creator always set 4 bytes (the max value)
Doom9
11th April 2005, 13:26
@Elias: Do you just not like to hear the problems or sweep them aside as being irrelevant? I have listed a great many difficulties.. if you think they are so trivial.. download the Delphi demo and get coding.. since it's so easy you should be done in 24h, shouldn't you? Or perhaps you should ask yourself why there is no tool that does all this for mp4.. there is an ample supply of programmers on this board.. if it were a 2h job I'm sure somebody would've done it already.
Doom9
11th April 2005, 13:27
additionally mp4box will need 2 bytes less per frame than mp4creator on most avc streamsHmm.. with that I'd probably be down to the values that I get using the ateme mp4 muxer. Gotta give it a try some time.
mezzanine
20th April 2005, 17:04
Elias, try AutoAC http://forum.doom9.org/showthread.php?s=&threadid=90732 and send me some feedback.
Elias
20th April 2005, 17:08
Originally posted by mezzanine
Elias, try AutoAC http://forum.doom9.org/showthread.php?s=&threadid=90732 and send me some feedback. Ok sure, I'll see what I can do :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.