2005-11-28
- no loop filter to reduce blocking artefacts, H.263 upon which MPEG4 is based had one, and the thing people most often complain about when looking at MPEG4 videos are blocking artefacts, why cant postprocessing filters cover this up? well its much harder to remove multiple overlapping and randomliy shifted bocking artefacts instead of ones which are exactly at a 8×8 grid and only around macroblocks with specific parameters …
- block boundary mirroring for qpel, this is AFAIK needed because there is no deblocking loop filter, if mirroring wouldnt be done then the filter would cross many more edges created by blocking artefacts and create a random mess, mirroring also reduces the number of bytes which need to be fetched for each block, ok but why am i complaining? well its a mess to implement and it forces the encoder to do redundant calculations as each block needs things mirrored differently
- all the startcode avoidance and redundant marker bits, there are really just 2 possibilities, either the stream is undamaged in which case we dont need to search for startcodes unless we try to seek in raw mpeg4 (.m4v NOT .mp4!) or it is damaged in which case the data can contain anything anyway, now if all this mess was for seeking in raw mpeg4 why are there no reliably timestamps? additionally all non-MPEG/ITU codecs work perfectly fine without this startcode emulation prevention thing
- OBMC is in the spec, theres a bit in the header to enable it but oops its not allowed in ANY profile
- IDCT see prevous blog entry
- GMC is very computationally intensive and according to some documents from the JVT the only reason why there is any quality/compression gain at all is that the motion vector for skiped macroblocks is the GMC vector where without GMC it would be (0,0) now simply changing that to the predicted median vector should make the tiny gain GMC has dissapear
- a single set of fixed vlc tables, why? its just silly, several fixed sets or variable ones stored in a global header would mean very little additional complexity IMHO at least
- short header format (=every MPEG4 decoder must support simple H.263)
- different motion vector prediction in bframes, why? using the same as in P frames would be simpler and very likely higher quality
- no intra macroblocks in b frames
- macroblocks in B frames must be skiped if they where skiped in the last P frame, thanks to this idiotic idea encoders must check all b frames before they can mark a MB in a P frame as skiped
- no macroblocks with 4mv and dquant at the same time, requires special handling in the encoder and no advantage at all, h.263 demonstrates how to do it correctly
- all the “flash” animation multi object stuff in MPEG4
- dquant is limited to +-2 so encoders must somehow convert the ideal QP values from lumimasking/… to ones which dont change too much between MBs
- QP is limited to either even or odd values in b frames, yeah poor encoder must decide which it wants, cant have both, hmm and according to the comments in ffmpeg more code is needed for working around all these arbitarray mpeg4 QP limitations about then the actual QP selection needs
RSS feed for comments on this post.
TrackBack URI
Sorry, the comment form is closed at this time.
Hi Michael :)
some additional missed points in MPEG4, IMHO:
= you can’t change the VOL header along the sequence. In particular, no adaptive qpel switching, or quant type switching.
= Reduced resolution (could have been a good idea, but it’s a miserable failure.)
= no pure field coding (unlike MPEG2). Oh, and supporting field MB is a mess too.
= no adaptive VLC tables
= some oddness in the (Run,Level) codes
= RVLC bwahaha
= 4-warp points sprite: not used. Unreadable spec.
= Mesh coding and facial animation ?! gee…
Now, fortunately, there are some also good points in mpeg4.
Comment by skal — 2005-11-29 @ 11:04
Hi Skal
> some additional missed points in MPEG4, IMHO:
> = you can’t change the VOL header along the sequence. In particular, no adaptive qpel switching, or quant type switching.
yes, or qpel&quant_type should be rather in the VOP header, also keep in mind that switching things in the VOL header is tricky if the VOL header is stored only in a specific single place like in .mp4
[…]
> = no pure field coding (unlike MPEG2). Oh, and supporting field MB is a mess too.
hmm, i do like the lack of field coding, actually i wouldnt mind if there where no interlacing support at all :-)
[…]
> = 4-warp points sprite: not used. Unreadable spec.
i think though i might be wrong (too lazy to look at the spec now) that the 4-wrap point sprite is used in some part of mpeg4 just not for GMC, and yeah the “GMC equations” are scarily obfuscated
[…]
another missed point is the motion vector coding, the per picture fixed number of LSB bits is hmm not so optimal, not to mention annoying for rate distortion during ME
Comment by Michael — 2005-11-29 @ 12:03
“hmm, i do like the lack of field coding, actually i wouldnt mind if there where no interlacing support at all”
Well, what am I supposed to do with all my interlaced content then? :-) I tried creating a 60fps MPEG4 using both quicktime and nero and both accepted it and then happily quantized time by x2 and I ended up with a 30fps file. Besides, I’m not sure my machine would even play back a 720x480x60fps MPEG-4 file…
Comment by Jim Leonard — 2005-11-29 @ 20:38
About interlaced content, heck, I’m so disappointed it hasn’t disappeared from the world yet with the moronic 1080i standard. You would have thought that by now people learned a few lessons.
In regard to Jim’s last comment, I thought I’d mention that my machine (Athlon 64 3200+) plays 640x480x60fps mpeg-4 asp (without quarter pixel which of course makes performance much worse) very well with the libavcodec decoder, with performance in very intensive parts avaraging around 30% cpu time usage, but in avarage, almost always less than 20%.
Comment by Shy — 2005-12-21 @ 03:03
I hate the fact that the aspect ratio is so widely ignored with mpeg4 but so widely used in mpeg 2. When converting between formats data ether has to be lost or just made up.
Comment by Greg — 2006-07-25 @ 14:10
I, too, am disgusted that interlacing isn’t going to die. Interlacing was FINE back when TV was invented, as it allowed for a higher resolution image while using less bandwidth. (Analog NTSC signals fit well within a 6MHz chunk of spectrum). But now, with the (extremely slow) migration to digital TV, there isn’t really a need to carry interlacing across. I noticed that my 720p HD locals are using 60fps (59.94fps, actually), which can handle movie telecine just as well (better, actually) as 29.97 interlaced video.
The biggest reason for needing to prevent “Start code simulation” is for when you are jumping in midstream, like when you tune in an HD channel. Before you can start decoding, you need to find a proper TS packet start code. If there are fake instances of it in the stream, it just makes it take longer to start decoding streams while you search.
Comment by Coderjoe — 2006-07-28 @ 21:08
[…] or Xvid. (Advanced codec developers may be interested in reading Michael Niedermayer's opinion on "why MPEG4-ASP sucks".) Likewise, you should get better quality using MPEG-4 ASP than you would with MPEG-2 codecs. […]
Pingback by DeServ – Info » MPlayer/MEncoder – Manual traduzido online – Completo — 2009-12-19 @ 00:16
skiped -> skipped ?
Comment by roger — 2011-06-10 @ 17:58
block boundary mirroring for qpel, this is AFAIK needed because there is no deblocking loop filter, if mirroring wouldnt be done then the filter would cross many more edges created by blocking artefacts and create a random mess, mirroring also reduces the number of bytes which need to be fetched for each block, ok but why am i complaining?
Comment by http://autoloansarticles.com — 2013-05-08 @ 06:26
I hate the fact that the aspect ratio is so widely ignored with mpeg4 but so widely used in mpeg 2. When converting between formats data ether has to be lost or just made up.
Comment by игровые аппараты — 2013-05-15 @ 09:50