AMVs encoded in h.264?

[Zero1]

Hate to double post, but this was posted and I didn't see it (No edit button )

First off, I want to make it clear that this isn't intentional flaming, I just feel that some things need to be clarified since H.264 information is still relatively low.

Even though the processing power may be higher, my 1 GHz can play back AVC, if it doesn't shoot up over about 1200kbps, that is (which is great for all those Quicktime trailers that I transmux to MKV, since QT7 is terrible at decoding on my setup). Even without CABAC enabled, it can provide quality similar to current XviD encodes with a bitrate at least 200kbps lower (with comparable filtering, anyway).

Why not try MP4? It is the native format after all It makes no sense to me placing H.264 + AAC in MKV when you aren't using any of MKV's special features.
H.264 + Vorbis I could understand, if audio quality is crucial, or if you wanted to use SSA softsubs with an embedded font, but MP4 offers all the basic features of MKV and some more, and vice versa.

Another thing too is that MP4 is effectively more newb friendly. I mean to look at a MKV file without any tools whatsoever, it could feasibly contain any audio or video format (within reason of course), whereas to look at MP4 you know it's going to be ASP or AVC, which makes troubleshooting and deciding what decoder you need infinately simpler.

To me it would be just like putting MPEG1 into AVI, completely pointless.
MP4 also has lower overhead

There will be people reading this thinking I am a MKV troll lol, this is not correct. I appreciate the flexability of the format, but why not just use the native container where you don't require any special features?


As for bitrate reduction with CABAC, it's largely bitrate dependant and complexity of course. It can shave off ~10% in normal cases or up to 25% in high bitate areas. 200kbps is a bit misleading, unless you are talking about using 1500kbps for the average bitrate. CABAC isn't going to save 200kbps on a 300kbps encode and 200kbps on a 8000kbps encode, it scales (I know you know this, but just clearing up for people).

Is there any way to check bus size?

Try Sisoft Sandra, even the free version has a ton of info modules and benchmarks, I'm sure you could find out from that.

I still haven't played around with the different types of searches, since whenever I did it before it'd crash VirtualDub. I also need to find out if encoding using the VFW with Matroska, pulling the raw .264 out, using MP4Box to place it in MP4, and then putting it back into MKV screws up the frames or whether it handles it correctly, effectively converting it from VFW to ISO-AVC (obviously, ISO-AVC being the way it's supposed to be handled natively, by both MP4 and MKV).

GAH! What the fuck? I apologise, but there is so much wrong with that statement it makes me want to cry. Ok, lets do this bit by bit.

First off, as soon as VfW (ie Virtualdub and AVI) is involved, kiss goodbye to compliance and say hello to missing frames, audio desync and hacks. I am not exaggerating. Kham will vouch for that when he first used X264. Your frame order will be borked, and it's likely that your B-frames will be attached to other frame types, in order to circumvent the one frame in one frame out limitation of VfW.

Using the VfW to encode to MKV, demux the raw, mux the raw to MP4, demux the raw from the MP4 and remuxing to MKV is going to do absolutely nothing except waste your time. I haven't tried it, but I would even guess that the frame order would become more fucked up if anything did happen to it. You might as well encode using VfW directly to MKV, the end result should be no different.

It seems like you want a directshow encode in MKV. The easiest and hassle free way to do this is the X264 CLI which supports direct output to MKV. If you want native encodes, you would really be better off with MP4 since then you really are conforming to the standard.

[Qyot27]

Even though the processing power may be higher, my 1 GHz can play back AVC, if it doesn't shoot up over about 1200kbps, that is (which is great for all those Quicktime trailers that I transmux to MKV, since QT7 is terrible at decoding on my setup). Even without CABAC enabled, it can provide quality similar to current XviD encodes with a bitrate at least 200kbps lower (with comparable filtering, anyway).

Why not try MP4? It is the native format after all It makes no sense to me placing H.264 + AAC in MKV when you aren't using any of MKV's special features.
H.264 + Vorbis I could understand, if audio quality is crucial, or if you wanted to use SSA softsubs with an embedded font, but MP4 offers all the basic features of MKV and some more, and vice versa.

Well, that's just with Quicktime trailers that I don't plan on doing anything special with it, considering those are only in that intermediate form long enough to either casually watch once or twice or decode to and then and/or pipe through TMPGEnc for VCD (since I don't download enough DVD-quality/res content or have the desire to spend a crapload of time encoding to MPEG-2 for DVD).

For the videos I plan on doing, I likely will be using things like embedded fonts and what not. Besides, I've just always liked Matroska.

As for bitrate reduction with CABAC, it's largely bitrate dependant and complexity of course. It can shave off ~10% in normal cases or up to 25% in high bitate areas. 200kbps is a bit misleading, unless you are talking about using 1500kbps for the average bitrate. CABAC isn't going to save 200kbps on a 300kbps encode and 200kbps on a 8000kbps encode, it scales (I know you know this, but just clearing up for people).

I was basing that on my typical XviD encodes, which were generally around 1000-1100kbps, and then the comparable-quality ones with x264, which I could usually fit down to 800-900kbps comfortably without CABAC, not to mention that the x264 encode was at a slightly higher resolution (this was during the period that using CABAC would make my computers lag like no tomorrow since I used Videosoft's 2.2 beta instead of ffdshow). But yeah, I should've chosen the 200kbps wording a bit more carefully.

I still haven't played around with the different types of searches, since whenever I did it before it'd crash VirtualDub. I also need to find out if encoding using the VFW with Matroska, pulling the raw .264 out, using MP4Box to place it in MP4, and then putting it back into MKV screws up the frames or whether it handles it correctly, effectively converting it from VFW to ISO-AVC (obviously, ISO-AVC being the way it's supposed to be handled natively, by both MP4 and MKV).

GAH! What the fuck? I apologise, but there is so much wrong with that statement it makes me want to cry. Ok, lets do this bit by bit.

First off, as soon as VfW (ie Virtualdub and AVI) is involved, kiss goodbye to compliance and say hello to missing frames, audio desync and hacks. I am not exaggerating. Kham will vouch for that when he first used X264. Your frame order will be borked, and it's likely that your B-frames will be attached to other frame types, in order to circumvent the one frame in one frame out limitation of VfW.

Using the VfW to encode to MKV, demux the raw, mux the raw to MP4, demux the raw from the MP4 and remuxing to MKV is going to do absolutely nothing except waste your time. I haven't tried it, but I would even guess that the frame order would become more fucked up if anything did happen to it. You might as well encode using VfW directly to MKV, the end result should be no different.

mkvmerge accepts MP4 directly, and anything that comes from MP4 or MOV is written in MKV's native AVC mode (since mkvmerge no longer accepts h264 in AVI unless it's enabled by the command line). I was going on the impression that MP4Box would correct the problems from the VFW stream when muxing from the raw .h264 to MP4 (I don't remember where I read that; I think it might've been on doom9, but I'm not sure).

After muxing the MP4 to MKV, there was no difference between VirtualDub's DirectShow codec warning when I loaded a file directly transmuxed from MP4 and the same file after it had been cycled through the VFW (via the avc2avi utility on the doom9 page). When I watched them, I didn't notice any audio skew (although the numbers in the VDub warnings were off by a few milliseconds), but like you said that's dependent on B-frames and Reference Frames, but do you have the numbers on the amount of whatever type of frame it takes before it's noticable? I would suspect that the Reference frames would present a problem since I have that set on 16, but I wouldn't know about the B-frames, as I only had that set on 1. Because it is the B-frames and Reference frames that cause the problems with the VFW in the first place, right?

It seems like you want a directshow encode in MKV. The easiest and hassle free way to do this is the X264 CLI which supports direct output to MKV. If you want native encodes, you would really be better off with MP4 since then you really are conforming to the standard.

Well, my problem with the CLI is that I would rather use a GUI, and I don't want the .NET framework anywhere near my computer if I can keep from it (the couple of times I've installed it thus far I seem to remember stuff happening with my configuration that I didn't want). In a perfect world, yeah, I'd jump to the CLI frontends in a heartbeat, but having to choose between .NET and using the commandline (which I really don't feel competant enough to do with a video encoder), I'm kind of stuck between a rock and a hard place. I will switch to encoders that output standard streams permanently after I setup a dual-boot with Linux (hopefully, that'll be within the next month, maybe).

What I would really like on the Windows side is for the VFW interface to have an option to output raw standard streams (or possibly only output raw standard streams, with the basic export from VDub disabled, instead just putting out a placeholder), like the basic ffdshow h264 encoding guide Tab posted back in January. Trick it into thinking it's outputting VFW when it really isn't. I don't even know if that's possible, though.