The H.264/AVC/MPEG4 discussion thread

[Nei]

Originally Posted by DryFire

Why are you even running Vista on that? You should use someting like Windows 2000 or maybe linux.

This is pretty much beyond the point. I have this box set up as triple boot Linux/XP and am also running Linux in Virtual PC and that doesn't influence h.264 playback ability a bit.

[Nicholi]

This is a result of decoding with an AMD K6-II 400MHz machine using CoreAVC and Overlay Mixer with the file [Arienai]_Starship_Girl_Yamamoto_Yohko_-_20_[ae159232].mp4

User: 2109s, kernel: 102s, total: 2212s, real: 2249s, fps: 15.9, dfps: 15.6

A machine half as slow as your "1GHz" C3 and almost a decade in age. Decoding at about 3/4'ths the framerate your test showed. Lets reiterate.

AMD K6-II
400MHz...
Approximately eight year old CPU, has MMX and 3DNow!
~16fps
Definitly has no Vista capability

vs

VIA C3
Allegedly 1000MHz
Pretty new technology, amirite? ~2004-2005 at least I would estimate, since you haven't said exactly what model you may have but we do know the clockrate
~21fps
Reported by random hosers to run Vista

Let the data sink in for a few seconds.... This is what everyone has been trying to point out to you, that you have an incredibly underpowered CPU. Which I'm guessing is only barely running Vista at best.

If I were testing with an AMD K7 Athlon 800MHz, I have no doubt it would have decoded this sample flawlessly with CoreAVC, and maybe even ffdshow. As well as run Vista on it because we all know Vista on slow CPUs makes them faster. You are right, no one is going to care about incredibly slow CPUs that can't decode H.264. Likewise no one is going to care about someone who just bought a recent incredibly slow CPU that can't decode H.264. Especially when said person says "but zomg it can run VISTA and has internet capabilities!"

Just for shits and giggles, here is the same test except using no renderer (Null), so it is essentially straight AVC decoding.

User: 1695s, kernel: 2s, total: 1697s, real: 1722s, fps: 20.7, dfps: 20.4

I'm just blown away at how crappy your CPU is....really.

[Quarkboy]

In light of this interesting discussion, and as the source of the offending fansub (starship girl yamamoto yohko 20), I would like to amend Arienai Fansubs' Policies:

Our encodes should be playable on any ^Intel, AMD, or PowerPC based^ 1 GHz or faster processor.


Sorry. Frankly, I didn't know such a processor even existed that would run any windows system. I suggest you watch the episodes on Youtube (since some kind soul is uploading them).

[Nei]

I'm sorry for mentioning the object which I used for testing, I did not mean to make this a subject of the discussion, nor to "blame" you for anything, Quarkboy. (Although you did shoot me down with the switch from XviD to h.264 only in the middle of the series ) Much on contrary, I appreciate you fansubbing it.

[Quarkboy]

Originally Posted by Nei

I'm sorry for mentioning the object which I used for testing, I did not mean to make this a subject of the discussion, nor to "blame" you for anything, Quarkboy. (Although you did shoot me down with the switch from XviD to h.264 only in the middle of the series )

I didn't take any offense. And you probably have the know how to reencode the file to xvid to view full framerate yourself.

[Starks]

I believe that the VIA C3 lacks basic MMX and SSE.

[checkers]

The via line of chips are optimised very extensively for lower power consumption and temperature. While after these I'd guess media playback would be close behind, the fact remains you are using a CPU which is hardly used by anyone and is therefore not even a target for those who write the decoders - substandard performance is what you trade for whatever advantages such a CPU has.

[ender]

Originally Posted by Starks

I believe that the VIA C3 lacks basic MMX and SSE.

AFAIK, all C3s support MMX, and depending on the model either 3Dnow or SSE (but not both at once).

[Starks]

Originally Posted by ender

AFAIK, all C3s support MMX, and depending on the model either 3Dnow or SSE (but not both at once).

*Checks VIA C3 specs again...*

I stand corrected.

[Harukalover]

In order to get this topic back alive. (That C3 thing stopped all the discussion...) I'll bring back something from a few pages back that I believe didn't get much exposure.

Originally Posted by TheFluff

On the other hand, there are ALSO shows that need at least 200 MB to reach CRF 18 under the same conditions. So, what Eeknay says. There are no universal "good sizes". Personally I'm beginning to think encoding everything as CRF 16-18 or so and ignoring fixed filesizes is a good idea, but of course that has drawbacks...

I'm wondering what you believe the drawbacks are.

Personally I see going for a fixed CRF instead of a fixed projected filesize would be the better way to go. It seems to me that most of the people who download H264 releases are looking for the highest quality encode. By limiting quality by using projected filesizes that aren't meeting the need of a reasonable CRF (16-20 would I believe be reasonable but that's up to the encoder and the viewer's ability to detect video quality differences), we are instead not providing the highest possible quality in our H264 encode. (Though I will say that there are series that stay at a reasonable CRF at a set filesize)

Of course I understand there are those that are aiming for more compression with H264. But my personal view is that those who are encoding with H264 should be aiming for the best quality possible and not a fixed filesize.

This I think especially goes for those that are doing dual releases. (Meaning one XviD release and one H264 release.) Groups that are doing only H264 may want to stick to the projected filesize only for the leechers sake.

[Mentar]

The best answer to the famous question "which quant should I use for hi-quality" which I can remember came from Myrsloik in #darkhold on chatsociety:

"What happened to using your eyes?"

Personally, I'm against constant quants simply because it effectively REDUCES quality, especially if you use adaptive quantization (which is not used by default in recent x264 builds, but which is key to high-quality anime encodes, especially of DVD sources). There ARE parts which simply don't need 16-18. Just like there are parts which profit alot from even lower ones.

I've recently had some eyeopener moments when I worked on S4A. For video proofing, I first made some CQ18 encodes and noticed that they came pretty close to the target in filesize. And then I made the proper full 2-pass encodes, and they totally blew away the CQ18. More detail, less ringing and much better dithering especially in the darker parts. For the SAME filesize, of course.

In other words: Multipass >> CQ on same filesizes. So why distribute inferior quality?

About the matter of size: Here, the eyes of the encoder should be the final arbiter, not some prepicked quant based on opinion. I prefer sticking to filesizes which match with a target medium, like DVD or CD, but the decision has to be based on a reasonable realistic size which matches the video source properties (quality, resolution etc). With experience, encoders gain the skill to gauge reasonable target sizes simply by stepping through the source - but if that's too dicey for you, make some test encodes (which could easily be CQ) and choose afterwards. But I really advise against indiscriminate use of CQ for release encodes. It's strictly worse than multipass, and in my eyes a sign of laziness.

[DryFire]

Are you mixing up CQ with CRF? There is a rather noticable difference in filesize.

[Mentar]

Actually, I did (misread the post before in this aspect) - but CRF is basically just CQ with a slight adaptive variation in quants. The underlying problem stays the same.

Multipass > CRF > CQ

[Harukalover]

Yes I probably did speak of CRF a little too hasty. I only know of what it does in theory. I never actually have tried it much at all. I've mostly stuck to 2 pass encodes. (Never really do 3 pass since I barely see any difference whatsoever between the two outcomes)

Perhaps CRF is better to use to find a basic idea of how well the anime compresses. And then to use a bitrate that matches around the size that the CRF gave. I'll try testing the CRF a bit and see how the equivalent 2 pass encode looks compared to it.

[Mentar]

Originally Posted by Harukalover

Perhaps CRF is better to use to find a basic idea of how well the anime compresses. And then to use a bitrate that matches around the size that the CRF gave. I'll try testing the CRF a bit and see how the equivalent 2 pass encode looks compared to it.

Now THAT is a reasonable approach, IMHO

And don't forget to enable adaptive quants when you make the final 2-pass.

[checkers]

sharktooth's x264 builds come with adaptive quant by default - they're what is used in MeGUI or you can download them from the megui update cache (and presumeably elsewhere too): www.megui.org/auto

[Harukalover]

Originally Posted by Mentar

Now THAT is a reasonable approach, IMHO

And don't forget to enable adaptive quants when you make the final 2-pass.

It seems you were indeed right. I test encoded with CRF 18 and then did a equivalent encode with 2 pass (With adaptive quant of course ). The 2 pass did seem much better. Also does seem that CRF might be a great way to test a video's compression capabilities.

Originally Posted by checkers

sharktooth's x264 builds come with adaptive quant by default - they're what is used in MeGUI or you can download them from the megui update cache (and presumeably elsewhere too): www.megui.org/auto

Well I'm not entirely proficient with MeGUI. (I usually stick to the CLI of x264) I did a check in MeGUI and perhaps it's hidden under another name or I'm just blind today but I didn't see any option for adaptive quant sensitivity or strength.

Unless MeGUI just uses a set default of adaptive quant on all x264 encodes?

[Mentar]

Originally Posted by checkers

sharktooth's x264 builds come with adaptive quant by default - they're what is used in MeGUI or you can download them from the megui update cache (and presumeably elsewhere too): www.megui.org/auto

My point was that (at least in the version I use) AQ is a feature which is _disabled_ by default and needs to be manually ENabled first to have it used. I don't use the very latest megui version either - don't know if it has changed there.

[Alizar]

Originally Posted by Harukalover

It seems you were indeed right. I test encoded with CRF 18 and then did a equivalent encode with 2 pass (With adaptive quant of course ). The 2 pass did seem much better. Also does seem that CRF might be a great way to test a video's compression capabilities.



Well I'm not entirely proficient with MeGUI. (I usually stick to the CLI of x264) I did a check in MeGUI and perhaps it's hidden under another name or I'm just blind today but I didn't see any option for adaptive quant sensitivity or strength.

Unless MeGUI just uses a set default of adaptive quant on all x264 encodes?

AQ is a commandline option. You have to set it manually in MEGui and be using a build that has the patch.

There are two settings:
--aq-strength X where X is an integer 0.0 (no AQ) to 1.1 (strong AQ) [default = 0.0]
--aq-sensitivity X where X is an integer 5 to 22 (flatness threshold, low value = AQ rarely triggers except on the most flat surfaces, high value = AQ triggers on almost everythign) [default = 15]

[Harukalover]

Originally Posted by Alizar

AQ is a commandline option. You have to set it manually in MEGui and be using a build that has the patch.

There are two settings:
--aq-strength X where X is an integer 0.0 (no AQ) to 1.1 (strong AQ) [default = 0.0]
--aq-sensitivity X where X is an integer 5 to 22 (flatness threshold, low value = AQ rarely triggers except on the most flat surfaces, high value = AQ triggers on almost everythign) [default = 15]

Err I know... I just only know how to use it in the CLI.

Originally Posted by Harukalover

then did a equivalent encode with 2 pass (With adaptive quant of course ).

Originally Posted by Harukalover

(I usually stick to the CLI of x264)

I only said something since checkers mentioned MeGUI but I don't really see any option for it in MeGUI. Just was wondering whether there even was an option in MeGUI for it or is it under another name.

It's rather interesting to see that has to be set manually in MeGUI though. I wonder whether that will be changed in the future. Since there are probably many encoders who may not know how to use the CLI and are stuck with MeGUI.