<!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>
On Fri, 2006-09-15 at 14:26 +0200, Jochen Issing wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Wow, I haven't heard of it before. Can you tell something about how you did </FONT>
<FONT COLOR="#000000">the write support? Do you use the skip/free boxes as buffers and reallocate </FONT>
<FONT COLOR="#000000">the boxes in case of new data exceeding the free-boxes?</FONT>
<FONT COLOR="#000000">Well for my part, I did read support and still need to do some restructuring </FONT>
<FONT COLOR="#000000">for a full write support. Because writing a tag into an mp4file can require </FONT>
<FONT COLOR="#000000">to rebuild the whole offset table - something that has actually nothing to do </FONT>
<FONT COLOR="#000000">with metadata, but who cares...</FONT>
</PRE>
</BLOCKQUOTE>
I actually just found out about that yesterday when I was fretting for hours about why on earth files were getting corrupted when I attached inline pictures. I fixed that at about 2 in the morning and it's in subversion now.<BR>
<BR>
Basically, here is what I do:<BR>
I have every box I use able to render its own content. If the box contains children and contains a FREE child or is a META box, it skips rendering any FREE boxes and adds a new one on the end at a size to avoid a change or a decent padding size.<BR>
<BR>
When rendering, I try finding the old ILST and slate it for replacement. If I don't have an old ILST box, I get the META box, stick the ILST inside and slate it for replacement. I do the same thing for META and UDTA. Since I know the size of what I'm replacing and the size of what I'm adding, I use file.insert to update the block.<BR>
<BR>
This is the tricky part: If the size change is non-zero I loop up the parent boxes, overwriting their headers with the size difference (this doesn't affect the file size except for the case of changing from a normal to a large size format in the header, in which case we're screwed). I then loop through the children of the MOOV box looking for TRAK boxes. When I find one, I look recursively for CO64 and STCO boxes and have them re-render their contents with the change in offsets.<BR>
<BR>
Long story short, it takes knowledge of 20 different box types to make this dream a reality and STCO is the single greatest flaw in the MPEG-4 file format. Who on earth puts all their stuff in boxes and then memorizes the GPS coordinates of the stuff. You would memorize where the stuff is relative to the box you put it in. ASF is glorious compared to this monstrosity.<BR>
<BR>
It's a real pain to figure out, but once you get it, it's not too bad. I hope this helps.
<PRE>
- Brian Nickel
</PRE>
</BODY>
</HTML>