<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.12.0">
</HEAD>
<BODY>
Jochen,<BR>
<BR>
The system I've come up with is a working solution. My method performs a single file size change (when required) to write the smallest block possible ILST, META, or UDTA, and then updates the necessary higher level nested boxes and the offset tables. The only problem is statistically impossible case where the MOOV box changes size from less than to greater than 4GB.<BR>
<BR>
- Brian<BR>
<BR>
On Sat, 2006-09-16 at 11:32 +0200, Jochen Issing wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Hi Brian,</FONT>
<FONT COLOR="#000000">thanks for your quick answer.</FONT>
<FONT COLOR="#000000">Well as I am somewhat familar with the mp4 file format and thought about the </FONT>
<FONT COLOR="#000000">problem for some time already, I know about several solutions/hacks.</FONT>
<FONT COLOR="#000000">If yours is yet another one, let me know.</FONT>
<FONT COLOR="#000000">The hacks:</FONT>
<FONT COLOR="#000000">* take the whole moov-box, replace it with a free box and place it afterwards </FONT>
<FONT COLOR="#000000">the mdat box. This avoids recalculation of any offsets, though it makes the </FONT>
<FONT COLOR="#000000">structure of the mp4 file slightly worse. Anyway, the file format is still </FONT>
<FONT COLOR="#000000">conformant, but one wastes the size of a whole moov box.</FONT>
<FONT COLOR="#000000">* Ignore the free boxes and recalculate always everything. This solution has </FONT>
<FONT COLOR="#000000">no special cases and still preserves the mp4 file structure</FONT>
<FONT COLOR="#000000">The solution:</FONT>
<FONT COLOR="#000000">* Take the free/skip boxes into account and use it for buffering. If the size </FONT>
<FONT COLOR="#000000">of the modified moov box exceeds the size of the old moov box, rewrite the </FONT>
<FONT COLOR="#000000">offset table and add new buffers (free-boxes) at iTunes style positions.</FONT>
<FONT COLOR="#000000">I thought about adding another proxy or (free-space) manager, at which every </FONT>
<FONT COLOR="#000000">free box registers itself on parsing. If any meta data changes, it reports </FONT>
<FONT COLOR="#000000">the change of its size to the proxy/manager, which takes care of any </FONT>
<FONT COLOR="#000000">restructuring.</FONT>
<FONT COLOR="#000000">If I understood you correctly, this is somewhat similar to your approach </FONT>
<FONT COLOR="#000000">except for the proxy? Anyway, the placement of offset tables is a difficult </FONT>
<FONT COLOR="#000000">field and I would say, that the mp4 file mechanism has its advantages. </FONT>
<FONT COLOR="#000000">Although in this case, they are a bit inconvenient and make me hesitate from </FONT>
<FONT COLOR="#000000">implementing write support.</FONT>
<FONT COLOR="#000000">Cheers,</FONT>
<FONT COLOR="#000000">jochen</FONT>
<FONT COLOR="#000000">On Saturday 16 September 2006 01:27, Brian Nickel wrote:</FONT>
<FONT COLOR="#000000">> On Fri, 2006-09-15 at 14:26 +0200, Jochen Issing wrote:</FONT>
<FONT COLOR="#000000">> > Wow, I haven't heard of it before. Can you tell something about how you</FONT>
<FONT COLOR="#000000">> > did the write support? Do you use the skip/free boxes as buffers and</FONT>
<FONT COLOR="#000000">> > reallocate the boxes in case of new data exceeding the free-boxes?</FONT>
<FONT COLOR="#000000">> ></FONT>
<FONT COLOR="#000000">> > Well for my part, I did read support and still need to do some</FONT>
<FONT COLOR="#000000">> > restructuring for a full write support. Because writing a tag into an</FONT>
<FONT COLOR="#000000">> > mp4file can require to rebuild the whole offset table - something that</FONT>
<FONT COLOR="#000000">> > has actually nothing to do with metadata, but who cares...</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> I actually just found out about that yesterday when I was fretting for</FONT>
<FONT COLOR="#000000">> hours about why on earth files were getting corrupted when I attached</FONT>
<FONT COLOR="#000000">> inline pictures. I fixed that at about 2 in the morning and it's in</FONT>
<FONT COLOR="#000000">> subversion now.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Basically, here is what I do:</FONT>
<FONT COLOR="#000000">> I have every box I use able to render its own content. If the box</FONT>
<FONT COLOR="#000000">> contains children and contains a FREE child or is a META box, it skips</FONT>
<FONT COLOR="#000000">> rendering any FREE boxes and adds a new one on the end at a size to</FONT>
<FONT COLOR="#000000">> avoid a change or a decent padding size.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> When rendering, I try finding the old ILST and slate it for replacement.</FONT>
<FONT COLOR="#000000">> If I don't have an old ILST box, I get the META box, stick the ILST</FONT>
<FONT COLOR="#000000">> inside and slate it for replacement. I do the same thing for META and</FONT>
<FONT COLOR="#000000">> UDTA. Since I know the size of what I'm replacing and the size of what</FONT>
<FONT COLOR="#000000">> I'm adding, I use file.insert to update the block.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> This is the tricky part: If the size change is non-zero I loop up the</FONT>
<FONT COLOR="#000000">> parent boxes, overwriting their headers with the size difference (this</FONT>
<FONT COLOR="#000000">> doesn't affect the file size except for the case of changing from a</FONT>
<FONT COLOR="#000000">> normal to a large size format in the header, in which case we're</FONT>
<FONT COLOR="#000000">> screwed). I then loop through the children of the MOOV box looking for</FONT>
<FONT COLOR="#000000">> TRAK boxes. When I find one, I look recursively for CO64 and STCO boxes</FONT>
<FONT COLOR="#000000">> and have them re-render their contents with the change in offsets.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> Long story short, it takes knowledge of 20 different box types to make</FONT>
<FONT COLOR="#000000">> this dream a reality and STCO is the single greatest flaw in the MPEG-4</FONT>
<FONT COLOR="#000000">> file format. Who on earth puts all their stuff in boxes and then</FONT>
<FONT COLOR="#000000">> memorizes the GPS coordinates of the stuff. You would memorize where the</FONT>
<FONT COLOR="#000000">> stuff is relative to the box you put it in. ASF is glorious compared to</FONT>
<FONT COLOR="#000000">> this monstrosity.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> It's a real pain to figure out, but once you get it, it's not too bad. I</FONT>
<FONT COLOR="#000000">> hope this helps.</FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">></FONT>
<FONT COLOR="#000000">> - Brian Nickel</FONT>
<FONT COLOR="#000000">-- </FONT>
<FONT COLOR="#000000"> jochen issing</FONT>
<FONT COLOR="#000000"> gpg-sig: 0A121BC8</FONT>
<FONT COLOR="#000000"> <A HREF="http://www.mcf-music.de">www.mcf-music.de</A></FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">taglib-devel mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:taglib-devel@kde.org">taglib-devel@kde.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://mail.kde.org/mailman/listinfo/taglib-devel">https://mail.kde.org/mailman/listinfo/taglib-devel</A></FONT>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>