View Full Version : Purpose of different containers?
JWFokker
23rd April 2007, 01:40
Most of the h.264 content I see uses a Matroska container, though I have seen a couple Blu-Ray rips in AVI containers. Is there any rhyme or reason to the container choice?
Dr.Khron
23rd April 2007, 01:56
Different containers can hold different video and audio streams. AVI is an older format, and can only hold a few different things. MKV is much newer, and can hold almost anything.
Go read the stickies in the "New and Alternative containers" forum.
christopherw
23rd April 2007, 03:54
I've always been under the impression that with the increase in popularity of larger bitrates and more types of content streams, the AVI container is becoming more and more outmoded and unnecessarily bloated (too much overhead per frame). MKV is more efficient and allows for an easier muxing of various streams, especially multiple subpicture and audio streams, and allows a pretty much platform-agnostic format for playback programs.
... or something like that
AVI is more than a decade old; it's about time it was usurped by a new, faster, better, stronger container format. ;) There's some interesting development with the MPEG-7 format which I'm keeping my eye on, too (abstract metadata storage, indexing and retrieval)
check
23rd April 2007, 06:07
avi isn't more bloated with hd streams, but it is incompatible with all new formats.
It is incompatible with: h264, vfr, aac, ac3/dts or newer incarnations. It also does not support chapters, softsubs or a host of other features matroska does.
PuzZLeR
27th April 2007, 15:46
How does all this compare to the .mp4 container?
(In terms of H.264.)
bob0r
27th April 2007, 17:12
I see it like this:
.mp4 is bound to specs
.mkv is virtually limitless
In a world where specs are dumb, or never uphold, .mkv is the perfect choise!
Dr.Khron
27th April 2007, 18:46
As far as I know, the only reason you should use MP4 over MKV is if your playback hardware requires it. A good example is the Ipod, which also limits the type of streams you can use. My wife re-encodes my MKV files to much smaller MP4s for use on her Ipod.
CruNcher
27th April 2007, 19:27
In my recent (backup) expierience with Blu-Ray H.264 High Profile 4.1 streams i have to say they are totaly unstable in .MP4 and not really more stable in .MKV in terms of seeking the best i found out for now is to let them either in .ts (transport stream, higher overhead) or .mpg (program stream, lower overhead) the created .ts files play fine in Mplayer but the created Program Streams don't :(, it seems as neither Mp4box nor Mp4creator and not even Mainconcepts Mp4 Demuxer can create Blu-Ray High Profile 4.1 stream working .Mp4's (you allways have problems with frame skips and seek problems with different Parser/Decoder combinations) under Windows it's the plain horror.
Manao
27th April 2007, 20:08
CruNcher : what tool do you use to convert to MP4 / MKV ? Because those containers are seekable, so either your demuxer or your muxer is b0rked. Furthermore, calling ts seekable is a laugh. It doesn't have any indexes.
legoman666
27th April 2007, 21:02
avi isn't more bloated with hd streams, but it is incompatible with all new formats.
It is incompatible with: h264, vfr, aac, ac3/dts or newer incarnations. It also does not support chapters, softsubs or a host of other features matroska does.
so all these avi's i have with ac3 audio aren't really there? :P
seems to work just fine for me.
PuzZLeR
28th April 2007, 14:07
It does appear that .mp4 is bound to specs. However, the wide-open abilities of .mkv aren't necessarily a good thing.
I just believe that the "narrow-ness" of specifications is directly proportional to the "wide-ness" of compatibility among decoders.
bond
28th April 2007, 14:41
moved
CruNcher
28th April 2007, 17:12
@Manao
seekability is not the problem (but it's much much faster in ps then .ts or mp4/mkv) but i expierence frame skips and mplayer has major seek problems in all newer builds with Blu-Ray (High Profile 4.1) streams (btw CoreAVC seems to have problems too it's much slower as compared to Cyberlink/Mainconcept with DXVA with this stream, but most probably no real problem but the end of CoreAVC''s Software Efficiency @ such high bitrates (30 Mbit) compared to Hardware accelleration) @ seeking (grey frames and splices distored) under windows not the splices get distored but the decoder just skip the frames when in .MP4 (muxed with Mp4box and Mp4creator also Xmuxer Pro) or in .MKV (Mkvmerge) only muxed in .mpg or .ts (Muxed with Mainconcept decoded with Mainconcept/Cyberlink) it's perfect in those regards so there seem to be some problems here, but it doesn't suprise me because all PRO stuff seems to be enhanced for .evo and .m2ts so if those problems occour with .MP4/MKV seems to be normal (it wasn't made for Blu-Ray Streams ???) but it's anyways a little strange as High Profile 4.1 isn't Blu-Ray specific but those streams seem to make problems for alot of apps.
the errors i get of the muxed H.264 stream in .MKV playing in Mplayer
[h264 @ 00D059E0]error while decoding MB 0 0, bytestream (10)
[h264 @ 00D059E0]top block unavailable for requested intra4x4 mode -1 at 0 16
the raw bitstream looks ok playing in mplayer but as soon as you seek
[h264 @ 00D059E0]top block unavailable for requested intra4x4 mode -1 at 0 0
[h264 @ 00D059E0]error while decoding MB 0 0, bytestream (14683)
[h264 @ 00D059E0]top block unavailable for requested intra4x4 mode -1 at 0 16
[h264 @ 00D059E0]error while decoding MB 0 16, bytestream (74699)
[h264 @ 00D059E0]top block unavailable for requested intra4x4 mode -1 at 0 34
[h264 @ 00D059E0]error while decoding MB 0 34, bytestream (122001)
[h264 @ 00D059E0]top block unavailable for requested intra4x4 mode -1 at 0 50
[h264 @ 00D059E0]error while decoding MB 0 50, bytestream (17135)
[h264 @ 00D059E0]concealing 8160 DC, 8160 AC, 8160 MV errors
MPlayer interrupted by signal 11 in module: decode_video
- MPlayer crashed by bad usage of CPU/FPU/RAM.
Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.
- MPlayer crashed. This shouldn't happen.
It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
gcc version. If you think it's MPlayer's fault, please read
DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
won't help unless you provide this information when reporting a possible bug.
and with an older build (dev-SVN-r21977) it works but @ seek you see this and gray frames with some splice distortions (shortly followed by a good frame and then it continues normaly)
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 0 0
[h264 @ 00BE6030]error while decoding MB 0 0, bytestream (14683)
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 0 16
[h264 @ 00BE6030]error while decoding MB 0 16, bytestream (74699)
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 0 34
[h264 @ 00BE6030]error while decoding MB 0 34, bytestream (122001)
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 0 50
[h264 @ 00BE6030]error while decoding MB 0 50, bytestream (17135)
[h264 @ 00BE6030]concealing 8160 DC, 8160 AC, 8160 MV errors
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 97 16
[h264 @ 00BE6030]error while decoding MB 97 16, bytestream (33723)
[h264 @ 00BE6030]top block unavailable for requested intra mode at 106 50
[h264 @ 00BE6030]error while decoding MB 106 50, bytestream (3311)
[h264 @ 00BE6030]concealing 6578 DC, 6578 AC, 6578 MV errors
[h264 @ 00BE6030]top block unavailable for requested intra mode at 37 16
[h264 @ 00BE6030]error while decoding MB 37 16, bytestream (26403)
[h264 @ 00BE6030]top block unavailable for requested intra mode at 78 34
[h264 @ 00BE6030]error while decoding MB 78 34, bytestream (42956)
[h264 @ 00BE6030]top block unavailable for requested intra4x4 mode -1 at 38 50
[h264 @ 00BE6030]error while decoding MB 38 50, bytestream (2419)
[h264 @ 00BE6030]concealing 6864 DC, 6864 AC, 6864 MV errors
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.