In the f4f specification that I have it says that there will be one mdat box in an f4f file :
2.13 Media Data box
Box type: 'mdat'
But in an f4f file that I am parsing I find not one but two mdat boxes. It seems that there can be multiple? Is there a newer more accurate f4f file spec somewhere?
Please go through the spec link shared @ http://www.adobe.com/products/httpdynamicstreaming/pdfs/httpdynamicstr eaming_wp_ue.pdf for information about f4fs.
Go to “HTTP Dynamic Streaming file formats” section for an explanation to your problem.
I have gone through the "Adobe Flash Video File Format" spec, which is why I quoted it in my question. In that spec it says that there will be "Quantity : One" mdat box in a file container but this isn't correct. In the link you just sent me it says that the "file format supports an efficient fragment structure that interleaves metadata inside multiple moof boxes and media data in multiple mdats in a single file". So it seems that the first spec is not accurate. Thanks for the additional information.
I have a question on the contents of an f4f file generated by the f4fPackager.
In the file there are 2 tracks, one video, one audio. In looking at the trackFragmentBox contents in the video track there is (as expected) a set of track fragment run boxes.
In one that I'm looking at, the values of the track fragment run box are :
Flags : 00 00 0F
Sample Count : 1
Data Offset : 0x61
Sample Duration : 0x21
Sample Size : 0x686B
Sample Flags 0x02000000
Sample Composition Time Offset : 0x42
What is the offset relative to ? is it the start of the mdat box? or ?
And does the f4fpackager interleave the video and audio samples when it generates the file?
And from the same spec that I sent the link for, in the description of the abst it says that the BootstrapInfoVersion is :
"The version number of the bootstrap information.
When the Update field is set, BootstrapinfoVersion
indicates the version number that is being
In the generated .f4f file the update field is not set for any of the 65 abst boxes. Does this field indicate the moof sequence # that the abst is for?
I sent you a private message but while waiting for a reply I will keep posting my questions - these all come from examining a generated .f4f file and trying to correlate the contents to what is in the spec. I'm wondering if the spec is out of date? Or something is off because in the spec, in reference to the Adobe Mux Hint Sample box (rtmp) it says that the box contains an Adobe Mux Hint Process box (amhp) and that this box (amhp) is mandatory. But in the parsing of the generated .f4f file I find an rtmp box followed not by an amhp box, but instead a skip box. So this amhp is not mandatory?
I can clarify some of the points above :
When the doc / spec mentions a fragment, it is not equivalent to f4f. f4f == segment. An f4f (segment) can have one or more fragments. Each fragment is a groups of four boxes : afra - abst - moof - mdat.
So, each fragment will have one mdat. And an f4f can have multiple fragments, and hence multiple mdat(s).
If I'm correct, audio and video intervleaving is maintained within the fragments.
Essentialy, every mdat box is a TCMessage (if you already knew the FMS video/audio message format).
Offset is the relative position of the mdat within the fragment. A fragment is supposed to be an independent entity that should be capable of playing back on its own (with a supported player). Hence within a fragment, there is no pointer(s) to anything outside a fragment.
A segment (f4f) will maintain the snapshot of all the fragments within it == fragment run tables and segment run tables.
The version number of the bootstrap information is a flag generally useful in live streaming cases. In live case, the fragments/segments keep on getting appended and hence there is a need to constantly 'refresh' the bootsrap file. It is in this process a version flag is maintained to see if the bootstrap file is updated. For VOD cases, I don't think this has much significance.
Hope the information is useful. Thank you !
That is very helpful - thanks! After looking at the generated f4f files I had come to a similar conclusion and it is great to have that confirmed. It would be nice if the spec actually said that because it does not. Is the FMS spec available for download so that if I have other quesitons I can confirm what format is expected? I will look on the site to see if I can find a link to it.
You say that the offset is relative to the fragment - is the Base Data Offset in the track fragment header relative to the fragment's location in the f4f itself? And then the track fragment run's data offset relative to the posiiton in the individual fragment?