MPEG-4 Information Thread Discussion

[SeeMoreDigital]

What a great series of posts. Very interesting. Very detailed.

Your comments about b-frames have been put in with ASP information. Is this correct. Is encoding with b-frames supposed to be an Advance Simple Profile implementation only?

This is probably not the place to ask but do you know where we might be able to download some AVC encodes in an MP4 container?

And do you think we will be given the option of being able to generate AVC encodes with or without GMC and Qpel?

Feel free to delete this crappy post at your leisure...

Cheers

[bond]

Originally posted by SeeMoreDigital
What a great series of posts. Very interesting. Very detailed. thanks :)

Your comments about b-frames have been put in with ASP information. Is this correct. Is encoding with b-frames supposed to be an Advance Simple Profile implementation only?other profiles also allow b-frames, but simple profile doesnt

This is probably not the place to ask but do you know where we might be able to download some AVC encodes in an MP4 container?nope :(

And do you think we will be given the option of being able to generate AVC encodes with or without GMC and Qpel?afaik qpel is default in h.264 (not 100% sure tough)
gmc is not available in h.264

Feel free to delete this crappy post at your leisure..feedback is welcome :)

[temporance]

Originally posted by bond
still the correct expression for what we need a player to support is MPEG-4 ASP@L5, if a player is offering this you should be able to play all your MPEG-4 ASP encodes without problemsbond,

Be careful here. To claim to be a DVD player (or CD player) a device has to be put through standardized rigorous tests. These tests are pass or fail and have been a great success for the CE industry. 99.9% of the time, any DVD will play in any player that claims to be a "DVD player", whether it's a $39 Walmart special or a top-of-the-range Sony. This is the sort of simplicity that Joe Public needs.

Things started to get a bit more fuzzy when mp3 came onto the scene. Not all CDs burned with mp3's would play on all the early devices, even though they were clearly marked "mp3". People just accepted this as teething troubles, after all, the fact that the player worked with mp3's was just an interesting bonus feature.

MPEG-4 video is much more complex and offers a variety of compression configurations. MPEG-4 ASP@L5 is a very broad statement to make: what testing has the manufacturer done to justify this claim? Do they have a standardized set of tests that push the corners of the spec?

If a manufacturer is allowed to uses the brand of a large company like DivX or WindowsMedia, this implies that the piece of kit has been approved by that company. They would not risk their good name by allowing their name to be used on any piece of crap player.

Imagine taking your new DivX/DVD player back to the store after a couple of months and complaining "it says MPEG4 ASP@L5, but it won't play this clip". Even if you know that the clip is MPEG4 ASP@L5, how do you persuade the store assistant that the device is not up to spec?

On the other hand, if you've bought into a brand like DivX or WMV9 or whatever, then you have a position of strength. DivX is DivX. WMV9 is WMV9. You can hit those companies hard on forums like this and get your refund or a firmware upgrade.

[bond]

i already wondered that noone finds something discussable in these posts :D

still technically my statement is correct imo, the only things i know of which could hurt interoperability between two mpeg-4 asp@l5 implementations are
1) avi fourccs and hacks/workarounds (with b-frames) -> well blame sucking hardware manufacturers which only support this crap container
2) idct mismatch when using qpel (ok thats the only problem i know of which isnt good enough defined in the specs)
3) another problem could be that xvid currently doesnt limit the frame size, etc... as specified in the specs (but the xvid devs said they will change this after 1.0) - which means the encodes themselves are not 100% following asp@l5

and the divx certification in no way ensures that all "divx" encodes work on all "divx" players
also there are hundreds of "divx" labelled player out there which dont have a divx certification (yes they use it without approval from divxnetworks)...


what i want to point out with these statements is that people should realise that specs are there for a reason, they are there to ensure interoperability
if the specs are not 100% followed -> no interoperability can be ensured
and imo the exisiting problems are definitely not caused by the specs themselves (the only exception is maybe the possible idct mismatch) but simply by the implementations (hacks, etc...)


to sum it up again:
if BOTH the decoder (hardware) AND encoder side follow 100% the specifications made in mpeg-4 asp@l5 AND no crappy container, but a standardised container gets used, than there should be no interoperability problems
easy as that :D (yeah i know its a dream ;) )

[temporance]

3) another problem could be that xvid currently doesnt limit the frame size, etc... as specified in the specs (but the xvid devs said they will change this after 1.0) - which means the encodes themselves are not 100% following asp@l5Do you mean the VBV requirement of ASP? Xvid does not yet respect VBV - this could cause problems in high-action segments of a movie encoded at high bitrate. An xvid encode could cause a "MPEG-4 ASP@L5" compliant decoder to stall (jerky/slow playback) while it recovers from a buffer underflow. I believe DivX is the only MPEG-4 encoder that respects VBV, although the xvid people are working on a VBV rate control for sometime after the 1.0 release. Until this is done, xvid can't really claim to comply to the MPEG-4 profiles (like SP or ASP).

and the divx certification in no way ensures that all "divx" encodes work on all "divx" playersUh? Why not? In my experience, a DivX certified encode will play on any DivX certified player. Simple as that. Just like any DVD movie will play on any "DVD player".

On the container issue:

MPEG-4 in AVI is not a "hack" - can anyone tell me why it is? IMHO, the packed B-frame bitstream is a pretty neat engineering solution to a particular problem and works very well for many people including me. DivX Networks (or someone else) will doubtless have written a formal specification of how MPEG-4 [A]SP should be packaged within the AVI file format. So it is standardized, but not necessarily published (although it is widely understood).

You may not like AVI, but it is a very simple and well-supported container. It does its job well. And the "hack" you talk about breaks neither the AVI specification nor the MPEG-4 specification. Please less of the words "crappy container" and "hacks" unless you can justify them! :)

Now VBR audio in AVI: that's a more contentious point and I don't think we should discuss it in this thread. However, the same principles apply: if a third party writes a formal specification explaining exactly how VBR mp3 should be conveyed in their proprietary subset of AVI, then it is no longer a hack, but a proper engineering solution.

Btw: thanks for a nice thread, bond :)

[bond]

Originally posted by temporance
Do you mean the VBV requirement of ASP? Xvid does not yet respect VBV - this could cause problems in high-action segments of a movie encoded at high bitrate. An xvid encode could cause a "MPEG-4 ASP@L5" compliant decoder to stall (jerky/slow playback) while it recovers from a buffer underflow. I believe DivX is the only MPEG-4 encoder that respects VBV, although the xvid people are working on a VBV rate control for sometime after the 1.0 release. Until this is done, xvid can't really claim to comply to the MPEG-4 profiles (like SP or ASP).yep xvid doesnt do that atm (thats also the reason why they removed the divx profiles from xvid again)

so to say xvid doesnt 100% follow the mpeg-4 asp@l5 atm, but syskin said that this will probably be changed after 1.0 is out

Uh? Why not? In my experience, a DivX certified encode will play on any DivX certified player. Simple as that. Just like any DVD movie will play on any "DVD player".yes, as i wrote every encode following the home theater profile should be able to be played back on all divx certified players without problems

but what i meant was more that not all "divx" encodes follow this HTP, and not all mpeg-4 able players, who claim to play "divx", are divx certified

on the other side if a player claims to play mpeg-4 asp@l5 (and some to come chips, like the one from sigmadesigns already use this correct expression), it would be fraud if this isnt true (whereas claiming to be able to play "divx", as most player do, means as good as nothing/ensures no interoperability)
also too few encodes follow the HTP actually to be able to say that the divx certification actually has much practical usage

MPEG-4 in AVI is not a "hack" - can anyone tell me why it is?well some call it hack, some workarounds
fact is many workarounds are required to place mpeg-4 in avi, for example like VOL is repeated in each I frame in .avi (more below ;) )

IMHO, the packed B-frame bitstream is a pretty neat engineering solution to a particular problem and works very well for many people including me. DivX Networks (or someone else) will doubtless have written a formal specification of how MPEG-4 [A]SP should be packaged within the AVI file format. So it is standardized, but not necessarily published (although it is widely understood).well i wouldnt call private workarounds of 1 company/tool provider a specification

the fact is packed bitstream is nowhere meantioned in the mpeg-4 standard, its simply is a private workaround (some might call it hack) to be able to place b-frames in avi (if you search the forum you will find some old posts where people even claimed that packed bitstream actually breaks the bitstream as it is defined in the mpeg-4 standard)
if you take the mp4 container as a reference specification of how mpeg wants a mpeg-4 stream to be placed in a container you will see that things like packed bitstreams, vol in each i-frame aso are not only not specified, but forbidden actually

the next thing would be the delay frames caused as vfw is not able to encode b-frames actually
luckily virtualdub/mod drops them (another workaround to make things work), but basically from what i read such frames in the bitstream would break it

Now VBR audio in AVI: that's a more contentious point and I don't think we should discuss it in this thread. However, the same principles apply: if a third party writes a formal specification explaining exactly how VBR mp3 should be conveyed in their proprietary subset of AVI, then it is no longer a hack, but a proper engineering solution.well again, as far as i know the vbr mp3 in avi hack only works because of a flaw in the m$ dshow splitter. if i remember it right alexnoe or someone else even told me that m$ could even make vbr mp3 unusable in avi if they would published a fixed avi splitter

the point is (call it however you want) mpeg-4 in avi container is full of workarounds
workarounds which are only specified via the tools which do the workaround

see the point is even if it works noone supports alexnoes "specification to place aac in avi", it means nothing on its own
its only the mass-usage of some hacks which forces other tool providers to adopt these hacks/"neat engineering solutions", actually making things worse for other tool providers and therefore hurting interoperability

[RadicalEd]

Until this is done, xvid can't really claim to comply to the MPEG-4 profiles (like SP or ASP).
XviD conforms to the profiles, just not the levels therein. All a profile defines are the tools available for coding, i.e. qpel, gmc, bvops, arbitrary-shape coding, etc. Rate and buffers are the levels' domain.

[bond]

Originally posted by RadicalEd
XviD conforms to the profiles, just not the levels therein. All a profile defines are the tools available for coding, i.e. qpel, gmc, bvops, arbitrary-shape coding, etc. Rate and buffers are the levels' domain. well i wonder if its possible to seperate profiles and their levels?

[RadicalEd]

A decoder could easily be restricted by profile and not by level. Quicktime does this, IIRC. I suppose it isn't legal to comply to one and not the other as far as the standard goes, so practically it's a moot point. But the two are seperate, at least in definition.

[bond]

did you read the standard or are you guessing?

[SeeMoreDigital]

Talking about 'profile settings', I have to wonder, are they really all that necessary?

I was always a big fan of DivX but never used any of their 'profiles'. Since XviD introduced anamorphic signalling and MP4UI gave me an opportunity to use the MP4 container I now use XviD. However I still don't bother using their 'profile' settings!

I understand the requirement to maintain a specification, this is very important. So why have Mpeg4 codec manufactures been allowed to offer facilities that operate outside the spec?

I also have to wonder whether DivX certification has been a very positive step for Mpeg4. What with it's non consecutive B-VOP and 'locked' S-VOP (GMC) specification!

Cheers

[shark37]

Originally posted by bond
did you read the standard or are you guessing?

BTW, is there any place beside ISO book shop where one can get a copy of ISO 14496-2 paper or at least FCD (Final Committee Draft) 14496-2?

[RadicalEd]

I wish I could see the standard :| but I'm a kid with no $$. That's just info I've gathered along the way. I'm rather confident of its accuracy, of course :p

[temporance]

Originally posted by RadicalEd
XviD conforms to the profiles, just not the levels therein. All a profile defines are the tools available for coding, i.e. qpel, gmc, bvops, arbitrary-shape coding, etc. Rate and buffers are the levels' domain. Yes, you're quite right, RadicalEd, my apologies.

Another factor worth considering is that xvid is primarily a software codec, so the levels-compliance of its decoder will depend on the machine that it is run on. On a 3GHz machine, for example, it might comply with L5 whereas on a 400MHz machine, we might be talking L3.

So, in the software decoding world, levels-compliance is more, well, "soft". That doesn't negate the importants of the levels for hardware decoding and encoders that will be used to produce content decodable on hardware devices.

[CruNcher]

AVC Verification Test Results (http://www.chiariglione.org/mpeg/working_documents/mpeg-04/avc/avc_vt.zip)

[SeeMoreDigital]

And here are the above mentioned 'AVC Verification Test Results' (http://82.2.167.24/Uploaded_Files/Doom9_Forum_files/AVC_Verification_Test_Results_(mht).zip) in HTML (mht) format instead of M$ word. :D

[ac-chan123]

here are some MP4 File Format documents.
-http://www.geocities.com/xhelmboyx/quicktime/formats/mp4-layout.txt
-http://mediaxw.sourceforge.net/files/doc/MPEG%204%20System.pdf

here some links to final draft of MPEG4

-http://le-hacker.org/hacks/mpeg-drafts/is144961cd.pdf (14496-1 Sytem)
-http://ivpl.ece.northwestern.edu/Internal/Standards/Video/ISO_14496-2AMD1.pdf (14496-2 AMD1 Visual)
-http://www.tnt.uni-hannover.de/project/mpeg/audio/documents/ (14496-3 Audio)
-http://www.mp3-tech.org/programmer/docs/ISO_14496-3.pdf
-http://www.tnt.uni-hannover.de/project/mpeg/audio/documents/w2803.html (14496-3 AMD1 Audio V2)
-http://www.itscj.ipsj.or.jp/sc29/open/29view/29n2605t.pdf (14496-5 Software Simulation)

AC-Chan(Robert Vincenz)

[bond]

thanks for the links guys!
i now found the time to merge them into the single threads :)

i also updated the h.264 thread with some updated infos on the available avc implementations and descriptions for some avc features (including cabac/cavlv, loopfilter aso...),
thanks a lot to bobololo for your help!!!

i hope someone finds it useful :)

[ac-chan123]

I have yesterday found the ISO Basic Media Document at ISO. It is at the "freely avaible Documents" section.
http://isotc.iso.ch/livelink/livelink/fetch/2000/2489/Ittf_Home/PubliclyAvailableStandards.htm
-->[url]http://www.iso.org/iso/en/ittf/PubliclyAvailableStandards/c038539_ISO_IEC_14496-12_2004(E).zip

[SeeMoreDigital]

Hi ac-chan123,

Are you learning about Mpeg4/MP4, or something?

You seem to be 'red hot' on finding all this info!


Cheers

[ac-chan123]

No. I read in moment Video Demystefied und other Books for lerning the basics of digital Video, then i write a little dictionary about the audiovisual world in german. But this is only my hobby.