2006-09-23, 21:18 | Link #441 | |
Member
Join Date: Apr 2006
|
Quote:
|
|
2006-09-23, 22:25 | Link #442 |
King of Hosers
Join Date: Dec 2005
Age: 41
|
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
Code:
User: 2109s, kernel: 102s, total: 2212s, real: 2249s, fps: 15.9, dfps: 15.6 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. Code:
User: 1695s, kernel: 2s, total: 1697s, real: 1722s, fps: 20.7, dfps: 20.4 |
2006-09-23, 22:45 | Link #443 |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
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).
__________________
|
2006-09-23, 22:55 | Link #444 |
Member
Join Date: Apr 2006
|
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.
|
2006-09-23, 23:07 | Link #445 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
__________________
|
|
2006-09-24, 01:04 | Link #447 |
Part 8
IT Support
|
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.
|
2006-09-24, 03:31 | Link #448 | |
*yawn*
Join Date: Jan 2003
Location: The sunny side of the Alps
Age: 41
|
Quote:
__________________
|
|
2006-09-27, 08:18 | Link #450 | |
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
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.
Quote:
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.
__________________
|
|
2006-09-27, 12:34 | Link #451 |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
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. |
2006-09-27, 13:44 | Link #454 |
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
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.
__________________
|
2006-09-27, 14:23 | Link #455 | |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
Quote:
And don't forget to enable adaptive quants when you make the final 2-pass. |
|
2006-09-27, 18:58 | Link #456 |
Part 8
IT Support
|
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
|
2006-09-27, 20:49 | Link #457 | ||
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
Quote:
Quote:
Unless MeGUI just uses a set default of adaptive quant on all x264 encodes?
__________________
|
||
2006-09-28, 00:21 | Link #458 | |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
Quote:
|
|
2006-09-28, 13:14 | Link #459 | |
Junior Member
Join Date: Mar 2006
|
Quote:
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] |
|
2006-09-28, 16:05 | Link #460 | |||
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
Quote:
Quote:
Quote:
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.
__________________
|
|||
|
|