Poll - War of the Containers

[Coderjo]

You see the difference between the bold marks? If you read my post again you'll find that I said that MP4 is the industry standard.

Oops. I guess I read too fast or something. You also didn't say MP4 is the industry standard, just that it is the standard container for H.264 video. You are entirely correct about MKV not being an industry standard, though.

[trythil]

Containers - .MKV & .MP4 - Better than .AVI \ What's that?
What, no inbetween option? :roll:
I'm not too fussed on what mkv has to offer, but mp4 files seem to be better quality than avi files at the same size.

What the heck does that mean?

I can mux the same video and audio streams into both a Matroska and MP4 container. Those files will therefore have the same quality.

The size difference is something around 6.7 kilobytes for a 2 minute video -- in favor of the MP4 container. In other words, the size difference is pretty much meaningless in the context of video and audio

for AMVs. Overhead does become an issue when you start talking about encoding movies.

I don't think the difference between MKV and MP4 is still that amazing, though I don't have a suitable source here to check -- I deleted my 700 MB Gattaca encode, so I'll have to re-make it to try that out.

[Orwell]

Containers - .MKV & .MP4 - Better than .AVI

I would say its better most of the time, though while AVI I can play back unless its corrupted, sometimes I've come across MP4 files that regardless of configuration and codec they just will not work for me.

Video codec - h264 - I'm all for quality

- as long as someone else is working towards it. If its fine, good enough for me, nothing I've worked on really demanded it.

Audio - 2.0

How does .1 work? I don't really care how I here the audio, two channels and minimal static is good enough for me. The thing that annoys me in audio is the fact that I can't understand what the hell their saying sometimes.

Subtitels - I kareoke song all the time

I prefer them almost whenever possible, irregardless of language, though if added I would prefer them in a MKV container, or as a separate file.

[Melanchthon]

I'm not too fussed on what mkv has to offer, but mp4 files seem to be better quality than avi files at the same size.

What the heck does that mean?

It was kind of a general statement, wasn't it?

What I mean is that the AMVs I have in mp4 are either smaller than avi files that look and sound similar to the mp4s, or look better (or are at a higher resolution) without being much larger. I don't have enough mkvs to be able to offer an opinion on whether or not it's better than avi.

But like I said, the perceived difference between avis and mp4s might be as much down to the fact that editors who encode in mp4 know what they're doing and why. As an average AMV downloader, I'd go for an mp4 over an avi because I think they look better (less blocking, mostly... twitching walls and skies bother me once I notice them). That is more of a codec issue than a container issue, true, but h264 is more suited to mp4 than it is avi (last time I read up on the subject, anyway. It's been a while).

[trythil]

I'm not too fussed on what mkv has to offer, but mp4 files seem to be better quality than avi files at the same size.

What the heck does that mean?

It was kind of a general statement, wasn't it?

No, it didn't make any sense, as quality isn't really a function of the container. A Matroska file with an AAC audio stream and an x264-encoded H.264 video stream will look and sound the same as an MP4 file with the same audio and video streams, because the streams are the same.

The choice of container could make a difference in quality if you're worried about overhead and are trying to hit some size goal, but really there's not much else involved.

[Melanchthon]

A Matroska file with an AAC audio stream and an x264-encoded H.264 video stream will look and sound the same as an MP4 file with the same audio and video streams, because the streams are the same.

I never compared Matroska and mp4, but whatever. I'll stop arguing. You're the one who knows about this; I just have an opinion.

Sorry if this comes across as passive-aggressive or something. I'm just saying that I'll leave this topic alone for the moment.

[Zero1]

Are you ready for a longpost(tm)?

For some time it seems that .MKV and .MP4 are getting more and more common. My question is' do you even use the added options?

Would you use the subtitels to kareoke a sond, or wont even bother to enabel the stream?

Yes. A remaster I made a while ago makes use of chapters and softsubs. Not that chapters are terribly useful in an AMV, and few people will know how to watch the softsubs (CCCP users will be fine, also those of you that have VSfilter installed), but since I was encoding spec compliant H.264 + AAC in MP4, well I might as well make use of these features since they are there, no?

Do you use the 5.1 audio stream or not?
And do you think that h264 is common enough to destribute without too many people complaining that they can't open it?

Yes, If I had audio in 5.1, I would use it. I mean why not? people with stereo speakers can still hear it, it's a no lose situation. Concepting a short AMV, or just kind of an editing gimmick, I was considering having 6 mono tracks in premiere and splicing the sound effects (think of a car screeching round the corner, engine sound starts at rear speakers and pans to front). The LFE (subwoofer channel) would kick in when the door of the car was opened to hear some of that bad ass bass.

As for being able to playback H.264; it's now or never. There are a number of viable ways of playing it back as covered in my guide. One particular method I mention, the CCCP is the easiest, most fool proof (if you have a clean, codec pack-less system) way of getting H.264 + AAC to play back on popular players such as Media Player Classic or Windows Media Player 7/8/9/10.


Containers - .MKV & .MP4 - Better than .AVI[/b]
MKV and MP4 are better than AVI for various reasons, as far as MPEG-4 Visual (Simple and Advanced Simple Profiles, ie XviD and DivX) and H.264 are concerned.

The first reason is compatibility, or rather compliance.
There are a number of dirty hacks required to store and playback XviD and DivX encodes in AVI. Why is this? It's because XviD and DivX are able to make use of a feature called B-frames, which require a previous and future frame, in order to be decoded. To cut a long and technical story short, AVI does not know what B-frames are, and Video for Windows (the "interface" the codecs use) can only handle parsing of one frame at a time (one frame in, one frame out). This means that it cannot "read ahead" to get the frame it needs to be able to decode the B-frame.

One workaround for this is to create a lag, a "B-frame decoder lag" which you might have seen before. To decode the contents of a B-frame, you need to know what the I and P frame contains. A normal coded sequence (how it is encoded and stored) might look like I P B B, and the display sequence is I B B P. Since VfW can only read one frame at a time, it cannot do this normally. What happens is that it reads the I frame and doesn't output anything (just the B-frame decoder lag message), then it stores that frame in a buffer and moves on to the next frame, which is a P frame. It decodes and stores this, but now displays the I frame from before. This way the decoder now has the I and P frame in it's buffer and is able to decode the B-frame.

The other workaround, called packed bitstream is truely evil. It boils down to hacking two frames together, and introducing "dummy" frames, called N-frames, or N-VOPs. So how does this work? Well remember that I told you VfW cannot decode two frames at once? Well it can't, so another way around it is to force 2 frames through at once. The correct frame order is of course, I P B B, but what happens now is that the B-frame gets packed together with the P frame, so that when the encoder has decoded the I frame, it moves on to decode the P-frame, and the B-frame gets forced through with it (kind of like a stowaway), this means that by the time the decoder has read the I frame and the P frame, it also has the B-frame which it is able to decode and show for the next frame. Now if we are packing the frames together, that means there will be less frames in effect, right? Yes, this is where N-VOPs come into play. These are the dummy frames, or place holders. They do very little apart from keeping the correct framecount. The packed bitstream would now look like I PB B N. Note that the PB frame counts as one frame.

The second reason is audio.
AVI is pretty poor from an audio point of view, in what formats it can contain. Most people are stuck with MP3 in their AVI files. It's not just the fact of being stuck with MP3 as a viable method either, it's the fact that you have to use a constant bitrate, since AVI does not officially support variable or average bitrate. MP3 as you all know is hugely popular, but is now a very old standard, and there are higher quality compression methods out there now, such as Vorbis and AAC. Both of which are said to be in the region of 30-40% more efficient than MP3 (understand that LAME is a very tuned MP3 encoder, so the percentage is likely to be lower). While it is possible to hack AAC into AVI, it is pointless when there are formats that officially support it without any problems.

The third reason is capabilities.
With new containers come new capabilities. MP4 and MKV are both capable of multiple audio tracks, chapters, softsubs and anamorphic resizing (anamorphic is a source encoded at an irregular aspect ratio, that gets stretched to the right aspect ratio on playback). In addition MKV also supports the direct muxing of DVD subpictures (subtitles) (you can also do this in MP4, but it is breaking specs, so use MKV for DVD subtitles). MP4 also has menu support and multiple video tracks. MP4 is also capable of some simple Flash (swf) stuff, 2D and 3D rendering (think interactive games) and is also streamable. With multiple audio and video tracks, there is now more than one way to be creative. How about two AMVs synced to the same track that the end user can switch between, or how about dual audio for a song that is released in more than one language? (Rammstein fans ahoy). Or how about multi editor projects with menus and chapters? I know chapters would be very much appreciated. On top of all of this, MKV and MP4 are also a lot more efficient than AVI, meaning that you get to spend more data on the actual video, rather than an inefficient method of storage.

PS: AVI is about 16 years old now (it made it's debut in Windows 3.11 IIRC), time to move on.


Video codec - h264 - I'm all for qualty, and ready to run it
Hell yeah, this is my kind of thread.
I'm all for quality, and have been running and encoding with it for over a year now. Even in it's early stages, x264 (a H264 encoder) was significantly better than XviD (a MPEG-4 Visual, or MPEG-4 ASP encoder), so much so that the XviD team decided to cool off with XviD development and help out with x264 (at least sysKin was, don't know what he's up to these days, I know he comes here sometimes though). The exact reasoning is that x264 can go much further than XviD for the same amount of effort. That says a lot in my opinion. XviD is awesome, no doubt. And it won't die out, or at least it shouldn't die out. It is, after all a part of the MPEG-4 standard, as is H.264. MPEG-4 ASP (or XviD/DivX as people commonly refer to it as (those are just the encoder names by the way)) should co-exist with H.264, particularly for portable devices where CPU and battery power is limited. MPEG-4 ASP is a better choice for such devices in my opinion. I wouldn't be entirely surprised if it co-existed to the extent that it's still with us in 3 or 4 years time as H264 is maturing, rather than it fading out altogether like previous MPEG-4 encoders did (ie DivX 3.11 etc).

H.264 is probably more common than people give credit for at the moment, there is certainly nothing to lose. You see H.264 is the buzzword right now, along with HDTV and HD-DVD. H.264 will be massive throughout the industry, as is MPEG-2 (though MPEG-2 is so huge through DVB and DVD, it has a way to go just yet). The encoders and decoders are mature and stable enough to be considered a viable method. It's now or never. Speaking of HD-DVD, I'm certainly looking forward to playing my H.264 + AAC in MP4 encodes (without transcoding or quality loss) on my shiny new HD-DVD player that I will inevitably end up getting.

H.264 is an incredibly detailed standard, and features a whole load of improvements over MPEG-4 ASP (XviD etc. etc.) On some fansubs I encoded, I find I am able to encode with a 20-30% lower bitrate on average. Numbers may not mean much to you, but for example I encoded Gundam X (640x480, 23.976fps, 24 mins) at 172MB with x264, when for XviD I would have aimed for a total of 233MB. Other tests were Kamichu (640x352, 23.976fps, 27 mins) at 115MB which looked pretty damn decent, and Itsudatte My Santa (704x480 anamorphic, 23.976, 29 mins) at 140MB.

The amount of improvements and new features in the H.264 standard over MPEG-4 ASP is crazy; and x264 will only continue to get even better. I know the developer (pengvado) has a nice todo list of tweaks and improvements that we can look forward to.

You know the other great thing about H.264? It's become sort of a fresh start for video coding in general. People are starting to move away from AVI, now that they are educated and see why AVI is not a good choice anymore, and this means that there are less hacky videos being distributed and the general consensus is that people "want to do it right". At least in fansubbing, a lot of people have moved to MKV or MP4 (though I do wish people who use H.264 + AAC would stick to MP4, and this is great. I will certainly suggest MKV or MP4 to people who want to get into H.264, but I would more strongly recommend MP4 since it's the native container. MP4 to H.264, is like what MPG is to MPEG1. In my opinion, putting H.264 + AAC in MKV (especially when you aren't using any of MKV's nice features to warrant it) makes about as much sense as putting MPEG-1 or MPEG-2 in AVI for the sake of it. I have nothing against MKV, but if you are going to use it, make it worthwhile and use Vorbis audio, if not and you prefer to use AAC, then stick with MP4. It will be spec compliant and help raise awareness. Raising awareness is half the battle, when people are more interested in MP4, hardware manufacturers and software developers will take more notice, implement the fun stuff like menus (and hopefully a MP4 menu authoring suite, hand scriping them is hell, I speak from experience), and we will have an interoperable, next generation standard to replace MPG.

Interoperability? Yes, you know how MPG works on practically everything? Well MP4 can be that way too, it just requires the masses to help make it that way through using it and showing that the interest and market is there.

H.264 has huge potential, along with MP4. Easy and compatible methods of playback exist. It's time to jump on the bandwagon and start reaping the benefits.


Audio - 5.1 VS 2.0 - Both
I say both, because audio CDs are almost exclusively stereo (perhaps some mono ones exist, I don't know), but you would certainly have a hard time finding all your favourite music in 5.1. I wouldn't outrule the use of 5.1 either, I mean why the hell not? Even stereo users can hear it (as I said before) so you don't lose any functionality.

As for where does the .1 come from, that's easy. 5.1 refers to the speaker setup, you have two front, two rear and a centre speaker (5 speaker). The .1 refers to the LFE (low frequency, or subwoofer) channel, that is optional, and doesn't really offer a great deal to the experience, just a dedicated channel for extra bass. Also, bass is non directional. You can theoretically put a subwoofer anywhere in the room and you cannot tell where the sound is coming from, unlike normal speakers.


Subtitels - I kareoke song all the time
I don't really karaoke all the time, but I would consider it just for completeness or making use of a feature at no extra cost to anyone except myself. Softsubbed karaoke can get a bit too complex to display in realtime (think the fancy fansub stuff) so in that respect it's a bad idea. However basic subtitles add almost nothing extra to the playback requirements, and provide something to sing along to, or a translation or editors comments if you so wish. Hardsubbed karaoke is also nice, but people would probably prefer not to see it (it can ruin the video unless it's softsubbed and you can turn it off)

I'm simply asking to know if its worh the trouble to add fetures like dual audio and kareoke subs, and if most people can play h264.

Thanks for answering, comments are always welcome.

Well you don't have to add these features; I mean it's fine to use H.264 in MKV or MP4 if you are just making a basic encode, with no extra features. But if people get some little enjoyment out of being able to watch an AMV with the audio in it's original or translated language, or they like to see the lyrics, why not? It's all about entertainment after all. The thing you must always remember though, is that no matter how many features and cool stuff you add, what really matters is a good concept and high amount of effort.

Unfortunately I suck in the concepts department, so I stick to encoding fansubs and chatting to other editors about encoding or offering my thoughts.

So again, is there any need to bother putting 5.1 stream and enlarging the filesize by something that no-one uses.

With AAC, you can get very good quality 5.1 at ~224-288kbps, which isn't bad when you think of the bitrate you will save by using H.264. Also if you use this as your only audio stream, it mean it always gets used (You do not have to have a seperate 2.0 and 5.1 track, a 5.1 only works fine).

I don't see any advantage in MKV for AMV's - I don't need menus, chapters, multiple audio and subtitle tracks or streaming, and I don't believe that it'll be supported by the industry.

Fair comment. The only reason I would use MKV for an AMV would be if I used Vorbis, but the gap between Apples AAC encoder (iTunes) and Vorbis is very little, perhaps even non existant (the average score at HydrogenAudio's recent public listenting test was a 6% difference in score, but Vorbis used on average 7% more bitrate...)

XivD and DivX use hacks to fit this into the AVI format. The AVI x264 codec also has to rely on hacks to work.

Indeed. The frame lag with H.264 in AVI can get crazy. Encoder side it induces a 1 frame lag for B-frames, 2 for B-Pyramid, and decoding side, whatever the number of max consecutive B-frames are. That's some serious potential lag! (And huge AMV desync, bwahaha).

In addition, ADV/AN's podcast uses the MP4 container, although they seem to name the files .m4v for some reason.

Wow, that's odd... M4V is usually the extention given to MPEG-4 Visual elementary streams (such as a raw XviD encode)

I'll definitely have to offer an x264 version of my next video, probably in an alternative container like OGM.

I'll die sideways if you release an OGM :\ Please use MP4 or MKV :/

The size difference is something around 6.7 kilobytes for a 2 minute video -- in favor of the MP4 container. In other words, the size difference is pretty much meaningless in the context of video and audio.

Only that much? Last video I transmuxed out of curiosity landed me something like 33.3MB > 29.9MB, though it was a psuedo (read bullshit) 119.88 fps file, which obviously has a ton of N-VOPs owing to the extra junk added to make it 119.88fps (those extra frames are just N-VOPs, or nothing frames) and some N-VOPs from it being a packed bitstream. DivX killed my inner child.

Vorbis audio, for instance.
(Yeah, you can do that with MP4, but...)

... It stores it as a private stream, ie like an attachent, or user data. That is it's stored, but not really as an audio stream, just an attachment. So it might play, it might not. Chances are it won't since it's not spec compliant, so better stick with AAC in MP4, or stick with Vorbis in MKV.

I deleted my 700 MB Gattaca encode, so I'll have to re-make it to try that out.

Last transcode I did that was anything like regular (a 175MB XviD encode @ 23.976 fps), came out about 172MB when muxed to MP4. Not a huge difference, but it's a difference I'd rather spend on a higher audio or video bitrate as opposed to an old, inefficient container.

sometimes I've come across MP4 files that regardless of configuration and codec they just will not work for me.

That's odd... I'm not saying all MP4's should play when incomplete, but most if not all of my own encodes do seem to stream correctly and play when partially complete. The other thing to bear in mind is that H.264 being more advanced than MPEG-4 ASP (yes, XviD/DivX, I will drum this into people :p) references multiple frames, therefore there is a higher chance of a section not being playable if you download the MP4 through bittorrent, which doesn't download sequentially.

The thing that annoys me in audio is the fact that I can't understand what the hell their saying sometimes.

This can be attributed to a number of things. One of which is that DVD audio is naturally quieter than say, CD audio. Ever wonder why? There is a reason, this is because the films, originally intended for cinema, are mastered to make the best use of the awesome speaker setups in cinemas, and their huge range. Keeping the average audio volume low means that quiet sounds can be whisper like, and loud explosions are right on the other end of the scale, and you really feel the other end of that scale in a cinema. Unfortunately, home systems are far from being as dynamic as a cinema, and what with DVD audio being mastered as it would be for a cinema, this is why quiet sounds (like voices) are perhaps too quiet. The actual size of the room plays a big part of it too. In this case we need dynamic range compression, or dialog normalization. Unfortunately this is perhaps something that a lot of editors and encoders do not know, or think about.

There is also the possibility that your setup is not quite right; maybe the software isn't downmixing correctly and the 2 left and 2 right channels combined, sound louder than the one center channel (ie it's not normalizing the center).

What I mean is that the AMVs I have in mp4 are either smaller than avi files that look and sound similar to the mp4s, or look better (or are at a higher resolution) without being much larger. I don't have enough mkvs to be able to offer an opinion on whether or not it's better than avi.

I see where you are getting this assumption from. A majority of recent encodes contained in AVI are MPEG-4 ASP (XviD/DivX), and it's highly likely that encodes contained in MP4 (although you can contain MPEG-4 ASP in it also, it's not commonly done) are H.264. H.264 is much more efficient, so you are really comparing H.264 with MPEG-4 ASP here, not MP4 and AVI.

That is more of a codec issue than a container issue, true, but h264 is more suited to mp4 than it is avi (last time I read up on the subject, anyway. It's been a while).

No need to check up on that, H.264 always has, and always will be more suited in MP4 rather than AVI. AVI simply cannot handle the features of H.264, wheras H.264, MPEG-4 Visual & MP4 were designed with the same goals in mind.

[trythil]

The size difference is something around 6.7 kilobytes for a 2 minute video -- in favor of the MP4 container. In other words, the size difference is pretty much meaningless in the context of video and audio.

Only that much? Last video I transmuxed out of curiosity landed me something like 33.3MB > 29.9MB, though it was a psuedo (read bullshit) 119.88 fps file, which obviously has a ton of N-VOPs owing to the extra junk added to make it 119.88fps (those extra frames are just N-VOPs, or nothing frames) and some N-VOPs from it being a packed bitstream. DivX killed my inner child.

Code: Select all

trythil@nevrast ~/vp $ MP4Box -info credited.mp4
* Movie Info *
        Timescale 600 - Duration 00:02:05.041
        Fragmented File no - 2 track(s)
        File Brand isom - version 1
        Created: Sun Mar 19 03:04:56 2006

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: AAC Profile @ Level 2 (0x29)
No streams included in root OD

Track # 1 Info - TrackID 1 - TimeScale 24000 - Duration 00:02:05.041
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 3000 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 672 x 448 - Profile Unknown @ Level 5.1
Pixel Aspect Ratio 8:9 - Indicated track size 597 x 448
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:02:03.840
Media Info: Language "und" - Type "soun" - Sub Type "mp4a" - 5805 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x67
MPEG-2 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

trythil@nevrast ~/vp $ mkvinfo transmuxed.mkv
+ EBML head
+ Segment, size 14366692
|+ Seek head (subentries will be skipped)
|+ EbmlVoid (size: 4029)
|+ Segment information
| + Timecode scale: 1000000
| + Muxing application: libebml v0.7.3 + libmatroska v0.7.6
| + Writing application: mkvmerge v1.5.5 ('Another White Dash') built on Mar 16 2006 23:16:44
| + Duration: 125.000s (00:02:05.000000000)
| + Date: Mon Mar 20 18:50:55 2006 UTC
| + Segment UID: 0x05 0x13 0x5c 0x19 0x4b 0x32 0xe0 0xc7 0xd7 0x40 0x55 0x2d 0x4f 0xe9 0x7c 0xb6
|+ Segment tracks
| + A track
|  + Track number: 1
|  + Track UID: 1307164247
|  + Track type: video
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 0
|  + MinCache: 1
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 1
|  + Codec ID: V_MPEG4/ISO/AVC
|  + CodecPrivate, length 47
|  + Default duration: 41.681ms (23.992 fps for a video track)
|  + Language: und
|  + Video track
|   + Pixel width: 672
|   + Pixel height: 448
|   + Display width: 672
|   + Display height: 504
| + A track
|  + Track number: 2
|  + Track UID: 1148609372
|  + Track type: audio
|  + Default flag: 1
|  + Forced flag: 0
|  + Lacing flag: 1
|  + MinCache: 0
|  + Timecode scale: 1.000000
|  + Max BlockAddition ID: 1
|  + Codec ID: A_AAC/MPEG4/LC
|  + Default duration: 21.333ms (46.875 fps for a video track)
|  + Language: und
|  + Audio track
|   + Sampling frequency: 48000.000000
|   + Channels: 2
|+ EbmlVoid (size: 1024)
|+ Cluster

trythil@nevrast ~/vp $ ls -l transmuxed.mkv credited.mp4
-rw-r--r--  1 trythil users 14359018 Mar 18 22:04 credited.mp4
-rw-r--r--  1 trythil users 14366740 Mar 20 13:47 transmuxed.mkv

trythil@nevrast ~/vp $ bc
bc 1.06
Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
14366740 - 14359018
7722

OK, a little more than 6.7 kB, but still not too bad.

I guess I'd need to look at Matroska and MP4 structures a little more closely to really say much more about this.

[Coderjo]

Are you ready for a longpost(tm)?

longpost is looooooong...

[trythil]

Oh yeah:

Code: Select all

trythil@nevrast ~/vp $ mkvmerge --aspect-ratio 1:4/3 -o transmuxed.mkv credited.mp4