Advantages of OGM over MP4

[gamaD]

Are there any, and what are they?

[Koepi]

There are none if you ask that generally.

What do you want to know precisely?

MP4 as container requires you paying licensing fees. OGM, AVI and MKV are free to use.

Regards
Koepi

[gamaD]

Free vs licenced, exactly what I needed to know. Thanks!

[KpeX]

IMHO it's mainly about what audio format you want to use. If you prefer Vorbis audio, I'd use OGM or MKV (depending on your video/subtitle/chapter options). If you prefer AAC audio, the MP4 container is a good choice.

There iss an abundance of free and open source software available for the MP4 container.

[The Link]

MP4 as container requires you paying licensing fees.

AFAIK there are no licensing fees for the MP4 container.

Regards,
The Link

[Sharktooth]

Originally posted by The Link
AFAIK there are no licensing fees for the MP4 container.

Regards,
The Link
But there are for MPEG4 in general and the .MP4 container is designed for "containing" MPEG 4 streams...

[The Link]

But there are for MPEG4 in general and the .MP4 container is designed for "containing" MPEG 4 streams...
This doesn't contradict to what I said. Or is there a lack of understanding on my side?
MKV and OGG (as a video container) are also mostly used for mpeg4 streams. My comment was just about the container as is.

Regards,
The Link

[Atamido]

MP4 does have the benefit of having an actual specification, something that OGM lacks.Originally posted by The Link
MKV and OGG (as a video container) are also mostly used for mpeg4 streams. A significant portion of the MKV files in existance use RV9 video instead of MPEG-4.

[bond]

Originally posted by Koepi
MP4 as container requires you paying licensing fees.sorry, but thats wrong. you dont have to pay license fees for using .mp4

for example you can already practically place vorbis in .mp4 (yep such a tool exists) and dont have to pay anything to anyone

[Liisachan]

you can embed SRTs very easily to OGM.
maybe you can do the same with MP4, but OGM is easier.

you can use multiaudio very easily if OGM.
OggDS itself can switch multiaudio (this is even better than MKV)
maybe you can use multiaudio with MP4, but not so easily.

OGM is free, and so, there are many tools that support OGM, like VirtualDubMod. Many advantages.

On the other hand, if you need hw support, probably mp4 is advantageous in long run.

[Sirber]

Originally posted by Pamel
A significant portion of the MKV files in existance use RV9 video instead of MPEG-4. That's why I love MKV :D

[Liisachan]

Sirber: i guess that has little to do with this thread.

but that reminds me:

using OGM, you can use VP3, VP62, WMV-VCM, etc as vid, while you cannot use them in MP4 (afaik). That's another advantage of OGM over MP4.

Anyway each format has its own forte.

[Sirber]

Can I mux MP3 in OGG? :confused:

[Koepi]

You sure can. But would be the use of that? When using mp3 (well, at least cbr) as audio track you're better off using avi as container.

Regards
Koepi

[Sirber]

Sorry for this OT, but I always thought I was "forced" to vorbis with OGG container :(

[RadicalEd]

Originally posted by Liisachan
using OGM, you can use VP3, VP62, WMV-VCM, etc as vid, while you cannot use them in MP4 (afaik). That's another advantage of OGM over MP4.

It is theoretically possible, but your point stands in that no tool to do so has been produced as of yet.

[Sirber]

What about OGMTools?

[Liisachan]

Originally posted by RadicalEd
It is theoretically possible, but your point stands in that no tool to do so has been produced as of yet. You can use them in OGM from the very beginning--actually any VCM codec is usable. Any muxeres will do, like VDM, OggMux, or ofcos GraphEdit. I made (VP3+Vorbis).ogm already in 2002...

You can also use VBR MP3 in OGM (you can use it in AVI too, but thats Nandub's hack and generally not too advisable), plus you can safely use AC3 too. And, altho it might be slightly buggy, you could use DTS too... So there are a lot of things that OGM can but MP4 can't. On the other hand there are a lot of other things that MP4 can but OGM cannot. So which is better? is a meaningless question. It depends on what you want to do.

[Koepi]

RadicalEd meant that it is possible to do all this with mp4 too (which I don't think is advisable: it's not in the standard afaik), there are just no tools supporting that.

Regards
Koepi

[Liisachan]

oh, i see. Sorry, RadicalEd, thax Koepi.
Speaking of which, Apple Lossless seems to be apple's own format which is put in MP4.

[stephanV]

Originally posted by Sirber
Sorry for this OT, but I always thought I was "forced" to vorbis with OGG container :(

There is a difference between OGM and the Ogg container. OGM is a hack of the official Ogg container and not supported by Xiph. So yes, for Ogg you are right, but for OGM you are not.

[DAvenger]

OGM is not a hack. It's a DirectShow implementation of Ogg. Full 100% specs compliant.

[stephanV]

from here (http://xiph.org/container/ogm.html)

So, what's the problem?

The problem is that the DirectShow filters are an extension to the Ogg Multimedia Framework that lies outside of the Ogg specification. So, while it is certainly useful, it's not really 'Ogg.' Ogg is a trademark of the Xiph.Org Foundation, and it's used to delineate between 'within the specification' and 'outside of the specification.'


also:

Aren't you going a little overboard with this? OGM is useful.

If it weren't useful, I wouldn't be talking about this! The problem is that people could be convinced that OGM is Ogg, when it isn't. This has already shown itself, and it's a bit distressing.


if an unspecified extension to a format isnt a hack anymore, i dont know what is. OGM is certainly NOT within the specification of Ogg, Ogg is not intended for MPEG4 or anything else but theora.

[Latexxx]

Please note that Ogg specs ( ftp://ftp.rfc-editor.org/in-notes/rfc3533.txt ) don't say anything about only limiting to vorbis/theora. Though it could be that ogm thinggy doesn't really follow the standard, but I don't know how strictly it follows the standard.

[alexnoe]

OGM is OGG + additional packets + header stuff inside the OGG page data area.

If putting headers in the OGG page data area is not hackish, then SRT/SSA-in-AVI is not hackish either, becausing it's doing exactly that as well :)

Aren't you going a little overboard with this? OGM is useful. Indeed. It nicely demonstrates how some things should not be done. This is important, as one usually learns from errors. So no errors -> no learning :)
OGM is not a hack. It's a DirectShow implementation of Ogg. Full 100% specs compliant.
If OGM is 100% OGG compliant, then you are allowed to take 2 totally incompatible files (i.e. different video codec, audio codec, even audio sample rates), join them with copy /b, and the resulting file has to play. With OGG, this is called 'chaining' and explicitely allowed. So if OGM is 100% OGG compliant, it has to be allowed as well.

[stephanV]

Originally posted by Latexxx
Please note that Ogg specs ( ftp://ftp.rfc-editor.org/in-notes/rfc3533.txt ) don't say anything about only limiting to vorbis/theora.

MPEG4 is not free and therefor has no place in Ogg. As far as i understand it, Xiph decides what should go in Ogg or not. Until now for video only theora is available. (unless I've missed something) Remember that Ogg is more than just a specification, it's also an ideology of providing a *completely* free format. So OGM does not only break the standard, it also breaks the ideology.


So, it's just the name, right?

I wish it were that simple. The biggest problem is that people are using OGM primarily to encode DVD's with DivX video and Vorbis audio. I fear that people might be using OGM, and convince themselves that they're using completely free software, when they're not. After all, 'Ogg' is from Xiph, and Xiph only produces free stuff. DivX and XviD are MPEG-4 variants, and subject to any holds that the MPEG patents have on those technologies.

Again; Nothing wrong with DivX or XviD, they're just not completely open standards. Patents apply. It doesn't mean they're not useful, it just means that you might be getting more than you bargained for on the legal side of things.

[ChristianHJW]

Originally posted by Latexxx
Please note that Ogg specs ( ftp://ftp.rfc-editor.org/in-notes/rfc3533.txt ) don't say anything about only limiting to vorbis/theora.

Thats not the same. The question is, if it is documented and a part of the official Xiph specs, or not.

Though it could be that ogm thinggy doesn't really follow the standard, but I don't know how strictly it follows the standard.

AFAIK Tobias' OGM files are perfect OGG files as long as it comes to standard Vorbis streams in them. Everything else he added is an extension to the Xiph specs, and was never accepted nor intended by them. Xiph clearly stated a couple of times now that they are not interested that MPEG4 video is being placed inside OGG files, mainly for compatibility reasons from their own tools.

OGG is a direct competitor to MP4, MPEG, WMV and RMVB, the 'content distribution formats' as i usually call them, but license and patent free. The main goal for each of them must be to have perfect compatibility and playability, and as such you need to limit the number of possible audio and video streams in those files, otherwise you will have a support nightmare.

AVI, MOV and MKV are different animals, they are 'general use' containers. They can, of course, hold any kind of data and offer a framework and a unified interface ( codec API - still to come for matroska ) allowing people to make codecs of their own, and store their streams in them.

Of course, the same can be done with the 'content distribution formats' also, but the difference is those are not ment to be used for that. Pretty simple IMO, nothing to really discuss about ;) ...

[alexnoe]

You can also use VBR MP3 in OGM (you can use it in AVI too, but thats Nandub's hack and generally not too advisable)Long long time ago i've believed that nonsense as well...if you read and UNDERSTAND the AVI specs, then you'll see that it hardly bends the AVI specs, and that it's ACM which is b0rked and not suitable for AVI...

[SeeMoreDigital]

Notice how I'm not saying anything... Please continue... :D

[Atamido]

Originally posted by DAvenger
OGM is not a hack. It's a DirectShow implementation of Ogg. Full 100% specs compliant. Our friends at Xiph would be inclined to disagree. ChrisHJW is correct in that valid Ogg files are limited to what Xiph says that you can put in them, NOT anything they didn't disallow.

In other news, the 'official' Xiph DirectShow filters that are being developed by Illiminable will support OGM so you don't have to worry about your OGM files disappearing. It is worth noting that this isn't something that the Xiph folks want but rather part of a larger project that the Illiminable folks are working on that requires this support.

One other thing that I would guess is that if you aren't using Vorbis, chances are the overhead would be much lower in MP4 than OGM. I haven't seen any tests to back up this statement, but OGM has notoriously bad overhead. There was recently a mail to a Xiph mailing list about altering libogg to allow larger page sizes, which should decrease overhead, but I wouldn't expect this to be implemented in any OGM creation tools.

[alexnoe]

Mh...the OGG code in AVI-Mux GUI can already create large OGG pages, and it does when demuxing Vorbis-in-MKV to an OGG/Vorbis file.

That's the big advantage if you don't use foreign libs: you can do stuff right :) With the few tests i've done it seems to lower overhead by at least 30% for OGG/Vorbis.

[Liisachan]

Originally posted by alexnoe
Long long time ago i've believed that nonsense as well...if you read and UNDERSTAND the AVI specs, then you'll see that it hardly bends the AVI specs, and that it's ACM which is b0rked and not suitable for AVI...

Oh, well... that has nothing to do with this thread, and I didn't say VBR MP3 was evil nor "not standard-compliant"--I just said 'generally not too advisable' it's not a belief but just a simple fact that VD, AviUtl etc doesnt support vbr, and so quite a few ppl are having trouble with it.

Examples:
(1) When you open AVI with VirtualDub, you know what will happen. A lot of new subbers (especially new timers) have troubles because of that. (They cannot convert VBR MP3 in the AVI raw to WAV properly) As a result the timing in SSA will be messed up.
(2) Also inexperienced encoders will recompress the 'raw' wrongly, without knowing that feature of VD.
(3) Even if you are using VDM in the Nandab-like mode, new subbers may have troubles when previewing movie with subs in vdm by hitting [enter], if the audio is VBR.

So, generally I asked them to use CBR MP3. --This is just 'generally.'
youve got no problems at all if you know (for instance) how to set VDM 'like-nandub' mode.

Specs? Standard? --None of my business ;)
Personally, I use VBR MP3 if I want to. I even know how to put a track that is not Vorbis nor Theora into Ogg.

[alexnoe]

I even know how to put a track that is not Vorbis nor Theora into Ogg.It would take me like 2 minutes to allow that in AVI-Mux GUI for MP3, AC3, DTS and (HE-)AAC, assuming that those formats don't require special headers in OGG... so we're again at the point where we can put everything into OGG :)

[bond]

some things i feel the need to clearify:

Originally posted by Liisachan
maybe you can do the same with MP4, but OGM is easier.the mpeg-4 standard defines its own text-based format to be placed in .mp4 (mpeg-4 part 17), (like xiph atm works on its own sub format for .ogg too)
so there is no point in placing .srt in .mp4
still, and thats the big downside of .mp4: there is no tool existing which lets you do this actually (but i know that two different parties working on such a tool already :) )
for example you can do it with videolan, but its not fully spec compliant atm, so dont use it!

OggDS itself can switch multiaudio (this is even better than MKV)
maybe you can use multiaudio with MP4, but not so easily.hum,
1) of course you can use multiple audio streams in .mp4 (you can even use multiple video streams, and even multiple control "bifs" tracks (meaning multiple menus or multiple animation streams for example...)
2) its very easy to create such files, mp4ui can do it, mp4box, 3ivx, quicktime, aso... i would say there are more tools existing which can do it, than ones which cant

OGM is free, and so, there are many tools that support OGM, like VirtualDubMod.as pointed out before .mp4 is also free. you dont have to pay licenses for using it
you have to pay licenses for using mpeg-4 video, but that goes for matroska and ogm too (if you place mpeg-4 in them)

Originally posted by Koepi
RadicalEd meant that it is possible to do all this with mp4 too (which I don't think is advisable: it's not in the standard afaik), there are just no tools supporting that.the mpeg-4 standard (as i pointed it out in my faq) defines how to place non-mpeg streams in .mp4. so this is indeed covered by the standard and there exist at least 4 tools i know who make use of it already practically

still there exists no multipurpose tool, like virtualdub, which lets you place any stream in any container supported (if vdm would support .mp4 it would also be possible to place all vfw streams in .mp4 as its the case with .ogm or matroska, still of course it doesnt...)
basically .mp4 has a similar system than .avi, using, for private streams, something like private fourccs (and things like "DX50", "XVID" are private fourccs) too

[stephanV]

Originally posted by bond

the mpeg-4 standard (as i pointed it out in my faq) defines how to place non-mpeg streams in .mp4. so this is indeed covered by the standard and there exist at least 4 tools i know who make use of it already practically

The real question is: would a MP4 implemenatation of one company automatically support the implemented private streams of another?

If yes, then thats ok.
If not, then private streams are pretty useless.

[ChristianHJW]

Originally posted by stephanV The real question is: would a MP4 implemenatation of one company automatically support the implemented private streams of another? .. this is only possible if the implementation of these streams is follwing a well defined set of rules, and this requires an underlying framework, just like what VfW, DShow or Quicktime are. And of course Gstreamer, but i may be accused of vapourware talk for saying that, so i better shut up ....

[SeeMoreDigital]

Originally posted by stephanV
The real question is: would a MP4 implemenatation of one company automatically support the implemented private streams of another?

If yes, then thats ok.
If not, then private streams are pretty useless. What... Oh you must mean in the same way every companiies AVI implementation can be automatically read read anothers!

If that were the case, then every AVI player/filter, muxer, parser, etc, would be able to read all the different types of subtitle implementations, have anamorphic signalling detection, playback of every audio stream type that can be muxed into AVI etc, etc...


Cheers

[alexnoe]

What... Oh you must mean in the same way every companiies AVI implementation can be automatically read read anothers!
If it is a real AVI implementation, then yes

[SeeMoreDigital]

Originally posted by alexnoe
If it is a real AVI implementation, then yes Well I guess all we need now is, a list of all the "real" AVI implementations and a list of all the "hacked" AVI implenentations...

Can anyone oblige?

[stephanV]

Originally posted by SeeMoreDigital
What... Oh you must mean in the same way every companiies AVI implementation can be automatically read read anothers!

If that were the case, then every AVI player/filter, muxer, parser, etc, would be able to read all the different types of subtitle implementations, have anamorphic signalling detection, playback of every audio stream type that can be muxed into AVI etc, etc...

Cheers [/B]

The two main AVI-splitters (MS and Gabest') can read all AVIs muxed by AVIMux GUI (which is the bext, most advanced muxing program for AVI out there). Do not suggest otherwise. That some non-directshow players do not fully support AVI is their fault, not AVIs. What a program allows to mux or not has got nothing to do with this either, as a muxer does not need to read AVI-files (it primarily needs to read streams, although this can be avi-files of course) and therefor should only support whatever it needs to mux. A muxer can only go wrong if it muxes something it isnt allowed to mux or muxes it in the wrong way. But that again would be a faulty implementation.

However, your comparison is wrong. What might happen in the future with MP4 is that you have *fully* spec compliant file (with private streams), and a *fully* spec compliant splitter (which doesnt happen to support those private streams) and you're still not able to play your file back, at least not the way you wanted.

There's a difference between faulty implementation and breaking interoperability.

But i don't know if I'm right about this, thats why i asked. I don't see what AVI has to do with this. I believe this thread was OGM vs. MP4.

[SeeMoreDigital]

Well personally I think the use of "private streams" in MP4 is a great idea!

So if a large company like Apple wants to create and keep their "lossless audio .m4a" implementation "private" for use with their own player, then that's up to them!

However, the use of "private streams" makes it possible for clever people (many of whom reside on this forum) to create their own MP4 implementations and share them with others... I see nothing wrong with this!

[Sharktooth]

When there will be a programmable container i will move from AVI to it...

[SeeMoreDigital]

Originally posted by Sharktooth
When there will be a programmable container i will move from AVI to it... We could do with somebody like Alex to do for MP4 what he's done for AVI...

Unfortunately, such development activities often get taken for granted and yield little or no financial reward :(


Cheers

[bond]

Originally posted by stephanV
The real question is: would a MP4 implemenatation of one company automatically support the implemented private streams of another?

If yes, then thats ok.
If not, then private streams are pretty useless.thats exactly the same issue as with private .avi fourccs:
lets ask they other way round: do AVI "implemenatation of one company automatically support the implemented private streams of another"?
by default: NO
Divx5 uses the DX50 or DIVX fourcc and 3ivx uses 3IV2, their streams are not interoperable by default because of this, so to say they indeed use different "private" ways of storing their streams in the avi container
(still most decoders nowadays are able to support a whole bunch of fourccs, but this wasnt the case some years ago and still isnt the case on hardware players)

avi fourccs are private, as "mp4 fourccs" are private...

if i decide to use "theo" as fourcc in .mp4 for storing theora in there, and all the other decoders support "theo" than there will be interoperability between different implementations (as its the case with mpeg4 in avi today), if it will not be supported than there will not be interoperability (as it was the case with mpeg4 in avi some years ago and still is the case on hardware players)
if 3ivx decides to support vobsubs in .mp4 as stored in their by nero recode2, there will be interoperability, if not than nero will be the only one to support it. if divxnetworks decides to support the XVID fourcc in avi than there will be interoperability, if not than...

avi fourccs are private, as "mp4 fourccs" are private...

the only difference is that the mpeg-4 .mp4 standard defines that mpeg-4 part2 streams in .mp4 have to use "mp4v" as "fourcc" (and not DIVX or 3IV2 or XVID or whatever) and the avi defining document doesnt

see if a company is an asshole, it could place a mpeg-4 part2 stream in .mp4 by not using "mp4v" but for example "divx" instead and make their files not interoperable with other spec compliant implementations


to sum it up:
placing private streams in .mp4 is the same as placing private streams in .avi (like divx5 or xvid are private streams in .avi!) from the labelling of the streams point of view.
from the technical point of view there are till now no flaws known for .mp4 having troubles storing specific streams, like its the case for .avi with b-frames or vbr audio streams, but maybe they exist (who knows what coding technologies will exist in 5 years, making .mp4 outdated by than, as .avi is outdated today)


also as an example: to my knowledge .vob files are basically .mpg files, carrying ac3, dts and vobsub as private streams in them, as defined by the mpeg-2 standard


huh, long story, i hope its clear now :D

[stephanV]

Originally posted by bond
thats exactly the same issue as with [b]private.avi fourccs:
do AVI "implemenatation of one company automatically support the implemented private streams of another"?
by default: NO
Divx5 uses the DX50 or DIVX fourcc and 3ivx uses 3IV2, their streams are not interoperable by default because of this, so to say they indeed use different ways of storing their streams in the container
(still most decoders nowadays are able to support a whole bunch of fourccs, but this wasnt the case some years ago and still isnt the case on hardware players)

It is not the same, and you are not addressing my question. This is not an MPEG4-decoding compatibility issue, i couldnt care less if 3ivx uses a different fourcc from DivX in AVI. My question lies not in the decoding side (that would also be stupid, why should On2tech support decoding for XviD?) but on the splitting side.

What ever is stored in AVI can always be retrieved if both muxer and splitter are spec compliant. The fourcc is nothing more than an identifier to choose the decoder required. However, the avi-splitter will *always* give me the fourcc, it is up to me to have the right codecs installed then. No one ever has had to adapt the avi-splitter so it would spit out VP6.2 or Huffyuf or anything.

My question was: if I mux Ogg Vorbis in MP4 with Nero's muxer (assuming muxing is done spec compliant), will the 3ivx splitter (again, assuming it is spec compliant) automatically deliver me an audio pin to which i can connect the Vorbis decoder? Or would 3ivx have to write specific support for this?

The answer would be a simple: "Yes, specific support has to be written." or "No, a spec compliant splitter will also correctly render private streams without specifically having to implement them."

[bond]

i am indeed adressing your question, i didnt talk about decoding, but about how streams are stored in a container and the way streams are labelled is a part of this and in avi it is done the same way as in mp4: by four privately defined consecutive letters

and yes the 3ivx splitter will pass this four letter info automatically and any decoder supporting this four letter "fourcc" can connect to it without the 3ivx splitter having to be specifically modified to support this
still whether a splitter has to do this? whether it has to pass any four letter stream indication? sorry, i dont know whether this part of the the playback procedure is defined in mpeg-4.
is this defined in the avi specs? whether its mandatory that any avi splitter has to pass this info always? alexnoe can surely answer this :)

edit: i mean i also can imagine a company writing their own .avi splitter, which is only able to connect to their own decoder, outputting only their own fourcc...
simply because the default windows .avi splitter passes all fourccs, making it connectable to all decoders, doesnt mean that this behaviour is mandatory for any avi implementation


anyways, from my point of view: i dont want .mp4 to become a multipurpose container, having everyone put their stuff in their as they wish
basically everything needed for powerful multimedia files is defined in the mpeg-4 standard itself, people should follow these standards instead of using private streams, for the interoperabilities sake :)

[yaz]

Originally posted by bond
...i also can imagine a company writing their own .avi splitter, which is only able to connect to their own decoder, outputting only their own fourcc... yep ... such avis are existing, u musn't burn your imagination :-) just think of the 'avi impovements' making possible to store infos like chapter-points in avi. for such 'avi's u need the splitter/renderer of that 'company' otherwise u got only a mess.

anyway, stephanv is also right, to a certain extent. all this mess u talk about is coming from the decoder side. say, u can wrap a video stream of many different kinds into an avi (without harming any specs issue!) but it needs its own decoder even if it states 'i'm an mpeg4 compliant stream'. we all know this 'discrepancy.'

imho, this whole container business gets relevant only if it gets out of the 'private environment'. i mean, anybody can implement a software environtment perfect for playback of his/her files whatever container it has. although it's problematic but possible even for mp4. the real mess coming up when these files are to be 'spread', 'streamed', 'broadcasted' or sold.
another point to be considered are the hw-players. what are they really capable of when they state any kinda 'compliancy'? are they really implemented the standard/specs or just some solution(hack?) of some companies ?

the bests
y

[stephanV]

Originally posted by yaz
yep ... such avis are existing, u musn't burn your imagination :-) just think of the 'avi impovements' making possible to store infos like chapter-points in avi. for such 'avi's u need the splitter/renderer of that 'company' otherwise u got only a mess.
Unspecified extensions to a format are not within the format itself anymore. Those are not AVIs, those are files kinda like AVIs. I don't know of any program that can mux chapters in AVI (or something like AVI) though. Stuff like VBR audio and subtitles in AVI are not really extensions to the AVI-format. They only make use of things that were already there, like ffctype txts for subtitles.

Anyway, you see the same difference between MPEG4 and MS-MPEG4: although they are not completely different from each other, there are distinct differences which cause incompatibility. So these AVIs which you are talking about, are not really AVIs.


imho, this whole container business gets relevant only if it gets out of the 'private environment'. i mean, anybody can implement a software environtment perfect for playback of his/her files whatever container it has. although it's problematic but possible even for mp4. the real mess coming up when these files are to be 'spread', 'streamed', 'broadcasted' or sold.
This is very true of course, everything I create is 100% inter operable with my own system. No one else ever gets to play my files, so why would i worry about hacks or incompatibilities with certain players? Issues like interoperability are only important for companies or if you want to play your files on stand alones; who's gonna use AC3 in MP4 if no stand alone player supports it?

On the other hand, if i ever got hands on a MP4 file i would expect it to have MPEG4 content in it and not RealVideo with WMA audio. Otherwise, they seriously should consider renaming the container i think ;).

Originally posted by bond
i am indeed adressing your question, i didnt talk about decoding, but about how streams are stored in a container and the way streams are labelled is a part of this and in avi it is done the same way as in mp4: by four privately defined consecutive letters

Not really, you were mainly talking about fourcc's which is not (or i though it wasnt) the main issue. Somehow i always had understood that muxing an MPEG4 stream in MP4 would be different from muxing another kind of stream in MP4. I think this is/was a misunderstanding on my side. In fact, i think you could even see MPEG4 as a private stream in MP4, only the fourcc for the stream is always MP4V (whether it is DivX, XviD or something else). So its mainly the fourcc that is standardized for MPEG4 (and H.264).

Anyway, your last answer was a lot clearer, at least on my side. Thanks.

[bond]

Originally posted by stephanV
Not really, you were mainly talking about fourcc's which is not (or i though it wasnt) the main issue. Somehow i always had understood that muxing an MPEG4 stream in MP4 would be different from muxing another kind of stream in MP4. I think this is/was a misunderstanding on my side. In fact, i think you could even see MPEG4 as a private stream in MP4, only the fourcc for the stream is always MP4V (whether it is DivX, XviD or something else). So its mainly the fourcc that is standardized for MPEG4 (and H.264).well its not only the "fourcc" that its standardised when it comes to placing mpeg-4 streams in .mp4, for example its clear from the standard point of view that you are not allowed to use packed bitstream in .mp4, that you have to seperate the vol from the bitstream in .mp4 (not like in .avi where the vol is placed on every keyframe), aso...
so to say the purpose of the standard is to ensure that there is only one way to store mpeg-4 (but also mpeg-1/2) streams in .mp4, removing all posibilties for incompatibilities (hopefully)