Working with MP4 files

Jeremy Noring

unread,

Aug 5, 2009, 5:30:13 PM8/5/09

to

Hi,

What's the best way to read/write an MP4 file containing H.264 in
directshow? And (pardon the n00b question) when someone has an MP4
"mux", does this mean they have a filter that multiplexes elementary
streams into an MP4 container? I see that Geraint has an MP4 demux/
mux set of filters (http://www.gdcl.co.uk/mpeg4/index.htm) but
unfortunately I'm not entirely certain what that means.

Also, does anyone have any information on cross-platform MP4 reading/
writing/editing libraries?

Thanks in advance,

Jeremy

Jeremy Noring

unread,

Aug 5, 2009, 5:38:16 PM8/5/09

to

On Aug 5, 2:30 pm, Jeremy Noring <kid...@gmail.com> wrote:
> Also, does anyone have any information on cross-platform MP4 reading/
> writing/editing libraries?

Just to clarify, what I would really like is something sort of like
the IWMReader/IWMWriter/IWMMetadataEditor interfaces in the WMFSDK,
but for MP4 files. Maybe I'm out in left field, but other than open
source projects like ffmpeg I'm seeing a surprising lack of commercial
offerings in this area.

Chris P.

unread,

Aug 5, 2009, 5:52:16 PM8/5/09

to

On Wed, 5 Aug 2009 14:30:13 -0700 (PDT), Jeremy Noring wrote:

> What's the best way to read/write an MP4 file containing H.264 in
> directshow? And (pardon the n00b question) when someone has an MP4
> "mux", does this mean they have a filter that multiplexes elementary
> streams into an MP4 container? I see that Geraint has an MP4 demux/
> mux set of filters (http://www.gdcl.co.uk/mpeg4/index.htm) but
> unfortunately I'm not entirely certain what that means.

The demux is the splitter, file parser. It will extract the elementary
streams from the file and expose each one on its own pin. The "mux" is as
you said, the filter that composes the elementary streams into an output
file.

> Also, does anyone have any information on cross-platform MP4 reading/
> writing/editing libraries?

The Intel Performance Primatives (IPP) has sample file parsers and muxers.
It's not technically fully cross platform in the sense that you can just
recompile it, but they have implementations for Windows, Linux and OSX.

There is also GStreamer which is a DirectShow like framework that has
builds for Linux, OpenBSD and Windows - although the Windows build is out
of date.

--
http://www.chrisnet.net/code.htm
[MS MVP for DirectShow / MediaFoundation]

Chris P.

unread,

Aug 5, 2009, 6:04:18 PM8/5/09

to

On Wed, 5 Aug 2009 14:38:16 -0700 (PDT), Jeremy Noring wrote:

> Just to clarify, what I would really like is something sort of like
> the IWMReader/IWMWriter/IWMMetadataEditor interfaces in the WMFSDK,
> but for MP4 files. Maybe I'm out in left field, but other than open
> source projects like ffmpeg I'm seeing a surprising lack of commercial
> offerings in this area.

IPP is probably your best bet.

The relevant samples are part of the ipp-samples download.

\audio-video-codecs
\codec
\mpeg4_spl - MP4 splitter - ISO/IEC 14496-14:2001 part 14
\mpeg4_mux - MP4 mux - ISO/IEC 14496-12:2004, ISO/IEC 14496-14:2003
& ISO/IEC 14496-15:2004
\mpeg4_dec - MPEG-4 image decoder for simple and AS profiles
\mpeg4_enc - MPEG-4 image encoder for simple and AS profiles
\h264_dec - H.264 image decoder (main, extended, and high)
\h264_enc - H.264 image encoder

Their UMC wrapper makes it pretty easy to work with.

Jeremy Noring

unread,

Aug 6, 2009, 1:54:19 PM8/6/09

to

> --http://www.chrisnet.net/code.htm

> [MS MVP for DirectShow / MediaFoundation]

Thanks for cluing me in to that IPP stuff; I have it, but didn't think
to look at it. Off the top of your head, is their MP4 implementation
portable? All of this is eventually going to be running on an ARM
processor, so it couldn't have any IPP calls in it to port cleanly.

Chris P.

unread,

Aug 6, 2009, 6:45:44 PM8/6/09

to

On Thu, 6 Aug 2009 10:54:19 -0700 (PDT), Jeremy Noring wrote:

> Thanks for cluing me in to that IPP stuff; I have it, but didn't think
> to look at it. Off the top of your head, is their MP4 implementation
> portable? All of this is eventually going to be running on an ARM
> processor, so it couldn't have any IPP calls in it to port cleanly.

I don't know the answer to that question. I imagine that there are some
IPP calls in the sample code (perhaps not for the parser / muxer) so you
would need an IPP lib for the target platform.

--

Alessandro Angeli

unread,

Aug 7, 2009, 10:33:26 AM8/7/09

to

From: "Jeremy Noring"

> Thanks for cluing me in to that IPP stuff; I have it, but
> didn't think to look at it. Off the top of your head, is
> their MP4 implementation portable? All of this is
> eventually going to be running on an ARM processor, so it
> couldn't have any IPP calls in it to port cleanly.

ffmpeg is LGPL'ed and contains an MP4 parser and muxer as
well as all the codecs. It should compile on ARM (some parts
even have ARM-optimized assembly code), however not using
VC++ but GCC (porting the code to VC++ is a pain because
they use C99 and porting it to VC++/ARM is even harder).

Notice that writing a basic MP4 parser from scratch is
almost as easy as writing an AVI one (that is, 600 lines of
Java code) and writing a muxer is not much harder.

--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm

Jeremy Noring

unread,

Aug 7, 2009, 2:14:07 PM8/7/09

to

On Aug 7, 7:33 am, "Alessandro Angeli" <nob...@nowhere.in.the.net>
wrote:

> From: "Jeremy Noring"
>
> > Thanks for cluing me in to that IPP stuff; I have it, but
> > didn't think to look at it. Off the top of your head, is
> > their MP4 implementation portable? All of this is
> > eventually going to be running on an ARM processor, so it
> > couldn't have any IPP calls in it to port cleanly.
>
> ffmpeg is LGPL'ed and contains an MP4 parser and muxer as
> well as all the codecs. It should compile on ARM (some parts
> even have ARM-optimized assembly code), however not using
> VC++ but GCC (porting the code to VC++ is a pain because
> they use C99 and porting it to VC++/ARM is even harder).
>
> Notice that writing a basic MP4 parser from scratch is
> almost as easy as writing an AVI one (that is, 600 lines of
> Java code) and writing a muxer is not much harder.

I had considered this, and the MP4 mux in Geraint's project is simple
enough, although it doesn't seem to work in VLC for me. That said, I
need robust support for metadata and the audio codec we're using at
this point is unclear, so I'm hesitant to write it on my own. Do you
know of any "MP4 for dummies" resources on the web? I can't stand
RTFM, but if that's what I have to do, so be it.

Would you say it's more or less difficult than writing an ASF muxer?
(the reason I ask is I'm familiar enough with ASF to estimate writing
my own muxer)

Alessandro Angeli

unread,

Aug 7, 2009, 3:50:16 PM8/7/09

to

From: "Jeremy Noring"

> metadata and the audio codec we're using at this point is
> unclear, so I'm hesitant to write it on my own. Do you

The container is mostly codec-independent (the only
difference when you change codec are the codec-specific
fields after the generic codec descriptor in the header).

> know of any "MP4 for dummies" resources on the web? I
> can't stand RTFM, but if that's what I have to do, so be
> it.

I learned from the ISO doc, which is short and easy (but not
well written).

> Would you say it's more or less difficult than writing an
> ASF muxer? (the reason I ask is I'm familiar enough with
> ASF to estimate writing my own muxer)

MP4 is much simpler than ASF (and much much simpler than
MPEG-1/2 PS/TS), more like AVI. After all, it is nothing
more than a rebranded MOV.

Jeremy Noring

unread,

Aug 14, 2009, 12:21:11 PM8/14/09

to

On Aug 7, 12:50 pm, "Alessandro Angeli" <nob...@nowhere.in.the.net>
wrote:

> I learned from the ISO doc, which is short and easy (but not
> well written).

I bought it and attempted to read it--I found it short any cryptic.
Maybe you can clarify a few things for me?

An MP4 file seems to consist of two overall objects--the "moov" and
the "mdat" From what I can see, the "mdat" contains my AV data as
"access units" (so complete frames. or for audio???), and all of the
data is interleaved and time-ordered.

What I'm really unclear about is simply the byte structure of all of
this on disk--the ASF specification at least goes into great detail
how everything is layed out, but I'm really unclear about this w/r/t
MP4. Also unclear to me is the relationships between these structures
(it seems like some of the structures define audio/video payloads,
some deal with clocks, etc.) and the payload data.

> > Would you say it's more or less difficult than writing an
> > ASF muxer? (the reason I ask is I'm familiar enough with
> > ASF to estimate writing my own muxer)
>
> MP4 is much simpler than ASF (and much much simpler than
> MPEG-1/2 PS/TS), more like AVI. After all, it is nothing
> more than a rebranded MOV.

I've never done anything with MOV, so...really the only container
format I have any intimate knowledge of is ASF.

Alessandro Angeli

unread,

Aug 14, 2009, 6:09:50 PM8/14/09

to

From: "Jeremy Noring"

> I bought it and attempted to read it--I found it short
> any cryptic. Maybe you can clarify a few things for me?

Sorry, my reply should have been more explicit. The MP4
syntax is not explained in the MP4 doc, but in the free ISOM
doc (ISO/IEC 14496-12). You can get it from here:

http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html

Here you can find a lot of useful links:

http://en.wikipedia.org/wiki/ISO_base_media_file_format

QuickTime's MOV, Flash's F4V, 3GP, MP4... are all dialects
of ISOM and the respective documents mostly just specify the
layout of the codec-specific structures.

Since ISOM is based on MOV, the MOV specs contain some
useful info to clarify things that are quite cryptic in the
ISOM doc:

http://developer.apple.com/referencelibrary/QuickTime/idxFileFormatSpecification-date.html

Since F4V is nothing more than MP4, the F4V doc can also be
use useful:

http://www.adobe.com/devnet/flv/

> An MP4 file seems to consist of two overall objects--the
> "moov" and the "mdat" From what I can see, the "mdat"
> contains my AV data as "access units" (so complete
> frames. or for audio???), and all of the data is
> interleaved and time-ordered.

The mdat box is totally unstructured. The samples do not
need to be interleaved or ordered, but it's a good idea to
do so for performance reasons. The sample granularity
depends on the codec (in your case, it should be specified
in the MP4 doc: for 'avc1', aka H.264, video it should be an
integral number of NALs while, for 'mp4a', aka AAC, audio it
should an integral number of frames).

> What I'm really unclear about is simply the byte
> structure of all of this on disk--the ASF specification
> at least goes into great detail how everything is layed
> out, but I'm really unclear about this w/r/t MP4. Also
> unclear to me is the relationships between these
> structures (it seems like some of the structures define
> audio/video payloads, some deal with clocks, etc.) and
> the payload data.

Here is an ISOM primer. A basic ISOM file has the following
structure:

ftyp (signature)
mdat (unstructured data)
moov (header + index)
.mvhd
.trak
..tkhd
..mdia
...mdhd (clock units)
...hdlr (major type)
...minf
....stbl
.....stsd (subtype + format)
.....stsz (sample sizes)
.....stss (keyframe flags)
.....stts (sample timestamps)
.....stco (chunk offsets in mdat)
.....stsc (sample offsets in chunks)

The ftyp box must be first, while mdat and moov can be in
any order (put moov first if you want the file to stream
but, since moov also contains the index, it is easier to put
it last).

Notice that, unlike ASF or AVI, header and index are in the
same object and the data object has no framing or other
structure and can not be parsed without the index.

Jeremy Noring

unread,

Aug 17, 2009, 8:47:23 PM8/17/09

to

On Aug 14, 3:09 pm, "Alessandro Angeli" <nob...@nowhere.in.the.net>
wrote:

> From: "Jeremy Noring"
>
> > I bought it and attempted to read it--I found it short
> > any cryptic. Maybe you can clarify a few things for me?
>
> Sorry, my reply should have been more explicit. The MP4
> syntax is not explained in the MP4 doc, but in the free ISOM
> doc (ISO/IEC 14496-12).

Alessandro,

Thanks a ton for the response! It was most helpful. I'll review all
that.

I did find a library that I might go with: http://code.google.com/p/mp4v2/

That said, I think I might need to add some features to this library
to really make it work for me, so I'll still need to know everything
you posted in some detail. And, in general, it's good info. Thanks
again.

jump jack

unread,

Sep 23, 2010, 4:36:07 AM9/23/10

to

I have an MO4 file generated by an Emtec N-100 recorder, which I can't play with an player on PC.

I examined it with Apple tool Dumpster ( ftp://ftp.apple.com/developer/Quicktime/Windows_Tools/Programmers_Tools/Dumpster/Dumpster.zip ) , and it looks like the file totally lacks any header!

http://img580.imageshack.us/i/emtecmp4.jpg/

Any idea if it is possibile to extract both audio and video from MDAT atom?
The only SW able to play the file, Super(C), does not play the sound.

> On Wednesday, August 05, 2009 5:52 PM Chris P. wrote:

> The demux is the splitter, file parser. It will extract the elementary
> streams from the file and expose each one on its own pin. The "mux" is as
> you said, the filter that composes the elementary streams into an output
> file.
>
>

> The Intel Performance Primatives (IPP) has sample file parsers and muxers.

> it is not technically fully cross platform in the sense that you can just

> recompile it, but they have implementations for Windows, Linux and OSX.
>
> There is also GStreamer which is a DirectShow like framework that has
> builds for Linux, OpenBSD and Windows - although the Windows build is out
> of date.
>

> --
> http://www.chrisnet.net/code.htm
> [MS MVP for DirectShow / MediaFoundation]

>> On Wednesday, August 05, 2009 6:04 PM Chris P. wrote:

>> IPP is probably your best bet.
>>
>> The relevant samples are part of the ipp-samples download.
>>
>> \audio-video-codecs
>> \codec
>> \mpeg4_spl - MP4 splitter - ISO/IEC 14496-14:2001 part 14
>> \mpeg4_mux - MP4 mux - ISO/IEC 14496-12:2004, ISO/IEC 14496-14:2003
>> & ISO/IEC 14496-15:2004
>> \mpeg4_dec - MPEG-4 image decoder for simple and AS profiles
>> \mpeg4_enc - MPEG-4 image encoder for simple and AS profiles
>> \h264_dec - H.264 image decoder (main, extended, and high)
>> \h264_enc - H.264 image encoder
>>
>> Their UMC wrapper makes it pretty easy to work with.
>>

>> --
>> http://www.chrisnet.net/code.htm
>> [MS MVP for DirectShow / MediaFoundation]

>>> On Thursday, August 06, 2009 2:51 AM Jeremy Noring wrote:

>>> Hi,

>>>
>>> What's the best way to read/write an MP4 file containing H.264 in
>>> directshow? And (pardon the n00b question) when someone has an MP4
>>> "mux", does this mean they have a filter that multiplexes elementary
>>> streams into an MP4 container? I see that Geraint has an MP4 demux/
>>> mux set of filters (http://www.gdcl.co.uk/mpeg4/index.htm) but

>>> unfortunately I am not entirely certain what that means.

>>>
>>> Also, does anyone have any information on cross-platform MP4 reading/
>>> writing/editing libraries?
>>>

>>> Thanks in advance,
>>>
>>> Jeremy

>>>> On Thursday, August 06, 2009 2:51 AM Jeremy Noring wrote:

>>>> Just to clarify, what I would really like is something sort of like
>>>> the IWMReader/IWMWriter/IWMMetadataEditor interfaces in the WMFSDK,

>>>> but for MP4 files. Maybe I am out in left field, but other than open
>>>> source projects like ffmpeg I am seeing a surprising lack of commercial
>>>> offerings in this area.

>>>>> On Thursday, August 06, 2009 6:45 PM Chris P. wrote:

>>>>> I do not know the answer to that question. I imagine that there are some

>>>>> IPP calls in the sample code (perhaps not for the parser / muxer) so you
>>>>> would need an IPP lib for the target platform.
>>>>>
>>>>> --
>>>>> http://www.chrisnet.net/code.htm
>>>>> [MS MVP for DirectShow / MediaFoundation]

>>>>>> On Friday, August 07, 2009 10:33 AM Alessandro Angeli wrote:

>>>>>> From: "Jeremy Noring"
>>>>>>
>>>>>>
>>>>>> ffmpeg is LGPL'ed and contains an MP4 parser and muxer as
>>>>>> well as all the codecs. It should compile on ARM (some parts
>>>>>> even have ARM-optimized assembly code), however not using
>>>>>> VC++ but GCC (porting the code to VC++ is a pain because
>>>>>> they use C99 and porting it to VC++/ARM is even harder).
>>>>>>
>>>>>> Notice that writing a basic MP4 parser from scratch is
>>>>>> almost as easy as writing an AVI one (that is, 600 lines of
>>>>>> Java code) and writing a muxer is not much harder.
>>>>>>

>>>>>> --
>>>>>> // Alessandro Angeli
>>>>>> // MVP :: DirectShow / MediaFoundation
>>>>>> // mvpnews at riseoftheants dot com
>>>>>> // http://www.riseoftheants.com/mmx/faq.htm

>>>>>>> On Friday, August 07, 2009 3:50 PM Alessandro Angeli wrote:

>>>>>>> From: "Jeremy Noring"
>>>>>>>
>>>>>>>
>>>>>>> The container is mostly codec-independent (the only
>>>>>>> difference when you change codec are the codec-specific
>>>>>>> fields after the generic codec descriptor in the header).
>>>>>>>
>>>>>>>

>>>>>>> I learned from the ISO doc, which is short and easy (but not
>>>>>>> well written).
>>>>>>>
>>>>>>>

>>>>>>> MP4 is much simpler than ASF (and much much simpler than
>>>>>>> MPEG-1/2 PS/TS), more like AVI. After all, it is nothing
>>>>>>> more than a rebranded MOV.
>>>>>>>

>>>>>>> --
>>>>>>> // Alessandro Angeli
>>>>>>> // MVP :: DirectShow / MediaFoundation
>>>>>>> // mvpnews at riseoftheants dot com
>>>>>>> // http://www.riseoftheants.com/mmx/faq.htm

>>>>>>>> On Saturday, August 08, 2009 8:55 AM Jeremy Noring wrote:

>>>>>>>> 96-14:2003
>>>>>>>> les
>>>>>>>> les
>>>>>>>> )
>>>>>>>>
>>>>>>>> Thanks for cluing me in to that IPP stuff; I have it, but did not think

>>>>>>>> to look at it. Off the top of your head, is their MP4 implementation
>>>>>>>> portable? All of this is eventually going to be running on an ARM

>>>>>>>> processor, so it could not have any IPP calls in it to port cleanly.

>>>>>>>>> On Saturday, August 08, 2009 8:55 AM Jeremy Noring wrote:

>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I had considered this, and the MP4 mux in Geraint's project is simple

>>>>>>>>> enough, although it does not seem to work in VLC for me. That said, I
>>>>>>>>> need robust support for metadata and the audio codec we are using at
>>>>>>>>> this point is unclear, so I am hesitant to write it on my own. Do you
>>>>>>>>> know of any "MP4 for dummies" resources on the web? I cannot stand
>>>>>>>>> RTFM, but if that is what I have to do, so be it.
>>>>>>>>>
>>>>>>>>> Would you say it is more or less difficult than writing an ASF muxer?
>>>>>>>>> (the reason I ask is I am familiar enough with ASF to estimate writing
>>>>>>>>> my own muxer)

>>>>>>>>>> On Friday, August 14, 2009 6:09 PM Alessandro Angeli wrote:

>>>>>>>>>> From: "Jeremy Noring"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Sorry, my reply should have been more explicit. The MP4
>>>>>>>>>> syntax is not explained in the MP4 doc, but in the free ISOM
>>>>>>>>>> doc (ISO/IEC 14496-12). You can get it from here:
>>>>>>>>>>
>>>>>>>>>> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
>>>>>>>>>>
>>>>>>>>>> Here you can find a lot of useful links:
>>>>>>>>>>
>>>>>>>>>> http://en.wikipedia.org/wiki/ISO_base_media_file_format
>>>>>>>>>>
>>>>>>>>>> QuickTime's MOV, Flash's F4V, 3GP, MP4... are all dialects
>>>>>>>>>> of ISOM and the respective documents mostly just specify the
>>>>>>>>>> layout of the codec-specific structures.
>>>>>>>>>>
>>>>>>>>>> Since ISOM is based on MOV, the MOV specs contain some
>>>>>>>>>> useful info to clarify things that are quite cryptic in the
>>>>>>>>>> ISOM doc:
>>>>>>>>>>
>>>>>>>>>> http://developer.apple.com/referencelibrary/QuickTime/idxFileFormatSpecification-date.html
>>>>>>>>>>
>>>>>>>>>> Since F4V is nothing more than MP4, the F4V doc can also be
>>>>>>>>>> use useful:
>>>>>>>>>>
>>>>>>>>>> http://www.adobe.com/devnet/flv/
>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>> The mdat box is totally unstructured. The samples do not

>>>>>>>>>> need to be interleaved or ordered, but it is a good idea to

>>>>>>>>>> do so for performance reasons. The sample granularity
>>>>>>>>>> depends on the codec (in your case, it should be specified
>>>>>>>>>> in the MP4 doc: for 'avc1', aka H.264, video it should be an
>>>>>>>>>> integral number of NALs while, for 'mp4a', aka AAC, audio it
>>>>>>>>>> should an integral number of frames).
>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>>> On Saturday, August 15, 2009 11:09 PM Jeremy Noring wrote:

>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I bought it and attempted to read it--I found it short any cryptic.
>>>>>>>>>>> Maybe you can clarify a few things for me?
>>>>>>>>>>>

>>>>>>>>>>> An MP4 file seems to consist of two overall objects--the "moov" and
>>>>>>>>>>> the "mdat" From what I can see, the "mdat" contains my AV data as
>>>>>>>>>>> "access units" (so complete frames. or for audio???), and all of the
>>>>>>>>>>> data is interleaved and time-ordered.
>>>>>>>>>>>

>>>>>>>>>>> What I am really unclear about is simply the byte structure of all of

>>>>>>>>>>> this on disk--the ASF specification at least goes into great detail

>>>>>>>>>>> how everything is layed out, but I am really unclear about this w/r/t

>>>>>>>>>>> MP4. Also unclear to me is the relationships between these structures
>>>>>>>>>>> (it seems like some of the structures define audio/video payloads,
>>>>>>>>>>> some deal with clocks, etc.) and the payload data.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>

>>>>>>>>>>> I have never done anything with MOV, so...really the only container

>>>>>>>>>>> format I have any intimate knowledge of is ASF.

>>>>>>>>>>>> On Wednesday, August 19, 2009 11:50 PM Jeremy Noring wrote:

>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Alessandro,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks a ton for the response! It was most helpful. I will review all

>>>>>>>>>>>> that.
>>>>>>>>>>>>
>>>>>>>>>>>> I did find a library that I might go with: http://code.google.com/p/mp4v2/
>>>>>>>>>>>>
>>>>>>>>>>>> That said, I think I might need to add some features to this library

>>>>>>>>>>>> to really make it work for me, so I will still need to know everything
>>>>>>>>>>>> you posted in some detail. And, in general, it is good info. Thanks
>>>>>>>>>>>> again.

>>>>>>>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>>>>>>>>> A Comparison of Managed Compression Algorithms
>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/71485ecc-2d2d-435a-9c35-3d12b279f9ae/a-comparison-of-managed-compression-algorithms.aspx

jump jack

unread,

Sep 23, 2010, 4:36:18 AM9/23/10

to

http://img580.imageshack.us/i/emtecmp4.jpg/

>>>>>> --
>>>>>> // Alessandro Angeli
>>>>>> // MVP :: DirectShow / MediaFoundation
>>>>>> // mvpnews at riseoftheants dot com
>>>>>> // http://www.riseoftheants.com/mmx/faq.htm

>>>>>>> On Friday, August 07, 2009 3:50 PM Alessandro Angeli wrote:

>>>>>>> From: "Jeremy Noring"
>>>>>>>
>>>>>>>
>>>>>>> The container is mostly codec-independent (the only
>>>>>>> difference when you change codec are the codec-specific
>>>>>>> fields after the generic codec descriptor in the header).
>>>>>>>
>>>>>>>
>>>>>>> I learned from the ISO doc, which is short and easy (but not
>>>>>>> well written).
>>>>>>>
>>>>>>>
>>>>>>> MP4 is much simpler than ASF (and much much simpler than
>>>>>>> MPEG-1/2 PS/TS), more like AVI. After all, it is nothing
>>>>>>> more than a rebranded MOV.
>>>>>>>

>>>>>>> --
>>>>>>> // Alessandro Angeli
>>>>>>> // MVP :: DirectShow / MediaFoundation
>>>>>>> // mvpnews at riseoftheants dot com
>>>>>>> // http://www.riseoftheants.com/mmx/faq.htm

>>>>>>>> On Saturday, August 08, 2009 8:55 AM Jeremy Noring wrote:

>>>>>>>> 96-14:2003
>>>>>>>> les
>>>>>>>> les
>>>>>>>> )
>>>>>>>>
>>>>>>>> Thanks for cluing me in to that IPP stuff; I have it, but did not think
>>>>>>>> to look at it. Off the top of your head, is their MP4 implementation
>>>>>>>> portable? All of this is eventually going to be running on an ARM
>>>>>>>> processor, so it could not have any IPP calls in it to port cleanly.

>>>>>>>>> On Saturday, August 08, 2009 8:55 AM Jeremy Noring wrote:

>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I had considered this, and the MP4 mux in Geraint's project is simple
>>>>>>>>> enough, although it does not seem to work in VLC for me. That said, I
>>>>>>>>> need robust support for metadata and the audio codec we are using at
>>>>>>>>> this point is unclear, so I am hesitant to write it on my own. Do you
>>>>>>>>> know of any "MP4 for dummies" resources on the web? I cannot stand
>>>>>>>>> RTFM, but if that is what I have to do, so be it.
>>>>>>>>>
>>>>>>>>> Would you say it is more or less difficult than writing an ASF muxer?
>>>>>>>>> (the reason I ask is I am familiar enough with ASF to estimate writing
>>>>>>>>> my own muxer)

>>>>>>>>>> On Friday, August 14, 2009 6:09 PM Alessandro Angeli wrote:

>>>>>>>>>> From: "Jeremy Noring"
>>>>>>>>>>
>>>>>>>>>>

>>>>>>>>>> Sorry, my reply should have been more explicit. The MP4
>>>>>>>>>> syntax is not explained in the MP4 doc, but in the free ISOM
>>>>>>>>>> doc (ISO/IEC 14496-12). You can get it from here:
>>>>>>>>>>
>>>>>>>>>> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
>>>>>>>>>>
>>>>>>>>>> Here you can find a lot of useful links:
>>>>>>>>>>
>>>>>>>>>> http://en.wikipedia.org/wiki/ISO_base_media_file_format
>>>>>>>>>>
>>>>>>>>>> QuickTime's MOV, Flash's F4V, 3GP, MP4... are all dialects
>>>>>>>>>> of ISOM and the respective documents mostly just specify the
>>>>>>>>>> layout of the codec-specific structures.
>>>>>>>>>>
>>>>>>>>>> Since ISOM is based on MOV, the MOV specs contain some
>>>>>>>>>> useful info to clarify things that are quite cryptic in the
>>>>>>>>>> ISOM doc:
>>>>>>>>>>
>>>>>>>>>> http://developer.apple.com/referencelibrary/QuickTime/idxFileFormatSpecification-date.html
>>>>>>>>>>
>>>>>>>>>> Since F4V is nothing more than MP4, the F4V doc can also be
>>>>>>>>>> use useful:
>>>>>>>>>>
>>>>>>>>>> http://www.adobe.com/devnet/flv/
>>>>>>>>>>
>>>>>>>>>>