2006-09-28, 16:11 | Link #461 |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
Harukalover: The easiest way was to use "Custom Commandline Options" in Megui (under Zones) and add the AQ switches there. I didn't update my Megui for quite a while, so I don't know whether or not it made its way into the GUI by now. In any case, I think that AQ should be a _must_ for anime encoding.
|
2006-09-28, 16:23 | Link #462 | |
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
Quote:
Considering that AQ has such drastic effects on the encode it really should get an GUI option. Since I am an avid viewer of fansubs as well, I rather that H264 encodes come out best as possible. And for those encoders who may not be proficient with CLI commands and are more comfortable with MeGUI, we lose out on those who can use the AQ option. (This is assuming they don't know how to do the command in the custom cli option). Hopefully MeGUI will make that a button option in future updates.
__________________
|
|
2006-09-29, 05:30 | Link #463 |
Part 8
IT Support
|
As adaptive quantization is not a 'real' feature of x264 (it's only added in as a seperate patch), anime encoding is a very small field compared to the reast of video encoding and none of the MeGUI maintainers watch any anime (as far as I know, that is) - I doubt it will be added.
Of course if you are willing to update the megui code yourself I'm sure they'll gladly take the patch. |
2006-09-29, 07:01 | Link #464 | |
What? I am washed up!
|
Quote:
|
|
2006-09-29, 07:39 | Link #465 |
Mind Wanderer
Join Date: Apr 2006
Location: In front of my computer
Age: 52
|
The purpose of 2-pass encoding is to combine fixed file size, constant quality and variable bitrate.
This means bits are allocated trying to keep the quality constant. As far as I know it runs like this : 1) Perform a constant-quality pass. 2) Adjust quality level according to obtained size. 3) Do next pass. 4) If size if off by too much repeat at step 2. 5) On final pass, dynamically adjust quality level during encode to match closely desired size. So I don't understand how constant-quality and multipass encodes of same size can be significantly different. Maybe multipass does better data analysis ? Could it be an issue with the video architecture not feeding enough future frames to the one-pass encoding ? |
2006-09-29, 08:19 | Link #466 | |||
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
Quote:
Quote:
Quote:
But I believe the most reasonable explanation is through testing both modes out and using your eyes as the final judgement. From what I did see CRF seems to be more of a good way to gauge compression of a show. Then to use that as a fixed size of where to aim on a 2 pass encode.
__________________
Last edited by Harukalover; 2006-09-29 at 15:07. |
|||
2006-09-29, 13:09 | Link #467 | ||||||||||||||||||||||||||||||||||||||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
First off, I don't know the specifics of these encodes, but I'd say in the majority of cases, that the "XviD" version is a downscaled SD resolution (eg. 720x480 > 640x480, 640x352 or 704x400) generic MPEG-4 ASP + MP3 in AVI. I'll refer to these as legacy encodes (you know, like they term old stuff in computing "legacy" ). The H.264 encodes are likely HD resolution (most usually 1280x720), hence the filesize difference. Yes, you can of course have HD legacy encodes, but the filesize wouldn't be as reasonable as the H.264 encode (particularly with higher resolutions, the differences can become more apparent). This is just an assumption based on how the majority of people using H.264 go for same or lower filesizes for same resolution encodes compared to their XviD counterparts. I could be completely wrong, and all these people are simply encoding the same source but the H.264 versions at larger filesizes than the legacy encodes. Basically what I am saying is you might be comparing apples to oranges. Find H.264 and legacy encodes that share the same characteristics (same number of audio channels, same resolution etc.) and then see if the H.264 version is bigger. I think you will find more often than not, the H.264 encode is the same or lower size. There is probably only one or two encoders I know of that release larger H.264 than ASP, but having said that, I'm not exactly actively leeching or encoding so I don't know where the scene stands. Think about it, the whole point of switching to a more efficient codec is usually to lower bitrate requirements (and so filesize). If you choose to stay at the same filesizes you've been using for legacy encodes, then you are still getting higher quality. There is often little or no reason to encode H.264 at (significantly) larger filesizes than ASP, if your ASP was of a good quality to begin with. By the way; AVC, H.264, x264, all essentially boils down to the same thing since AVC and H.264 is the name of the standard, and x264 is an encoder employing that standard. All things being as equal as possible, it's already more efficent than MPEG-4 ASP (XviD/DivX), in how the bitstream is coded (here we are talking that CABAC > CAVLC > modified Huffman). Keeping that train of thought, CABAC can be roughly 10% more efficient than CAVLC, but I don't know about the efficiency gain in CAVLC over Huffman; either way, CABAC is pretty awesome. Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Well my original "arguement" (I guess you would call it that, but I don't care to re-read the thread to see what I actually said, or how it came about) was using VFR and decimating duplicate frames rather than encoding a filtered CFR source (which obviously has temporal and compression artifacts). Sure you can use dup and reduce the amount of bits required to encode adjacent frames (since the ones affected by Dup should be 100% identical), but in my opinion you might as well take the time to create a VFR encode and remove the redundancy altogether as opposed to encoding it (8 bytes + container overheard or whatever). I'm extremely pedantic, yes. As for interests of sanity, well I guess insane people like ourselves are few and far between Of course take that light heartedly; I'm just jokingly a bit. But it does get my back up at times when it seems like people disagree with me over the slightest thing, everyone backs up their friends/colleagues for the sake of it, and it goes on for several longposts before some newb intervenes, flamewars ensue and the thread gets locked. Anyway, good work on the low bitrate encodes, it's nice when you get something to a really small filesize and it still looks half decent, isn't it? H./x264 is interesting because unlike ASP/XviD, you don't hit a wall so early on, you seem to be able to push and push H.264 that bit more, thanks to inloop deblocking and a few other improvements (such as no more B-frame drift). The AAC/Vorbis codecs help recover a few MB here and there also, so that all goes toward lowering those filesizes but keeping respectable quality. Quote:
Quote:
Quote:
You may or may not remember KiSS technologies, the guys that produced those DivX players. Well some time ago they had planned a player called the DP-700, which would have presumably supported H.264 + AAC in MP4. This was the jointly developed player between Nero and KiSS, and obviously this player was a chance for Nero to push it's recode software. KiSS is now a part of Cisco, and as such, the Linksys logo now appears around the KiSS website (so don't be surprised if the KiSS brand is dumped and it becomes a Linksys DP-1600). All this talk about MP4 and hardware made me curious, so I contacted Nils Hougaard; a sales manager at Cisco. Obviously telling this guy that I would like to know if their player would be capable of playing our copyright infringing encodes wouldn't go down awfully well, so I basically said that we (in this instance myself and a few friends) create and distribute original works (hardly) and non-linear editing works (partially true if you count AMVs), and wondered if the said player would be capable of playing these H.264 + AAC in MP4 files. I went on to elaborate on the sort of profiles and levels we tend to deal with right now, nothing else interesting, just a few different tacts at getting the relevant information from him. He replied very promptly, and this is what he said: Quote:
The amazing thing is that these are just 166 or 200MHz ARM CPUs (in before "ZOMG they are specially designed for video, that's why you don't need jiggahurts"). They say the price will be the same or similar to the DP-600. Based on this, I'm not too expectant of it having a Bluray or HD-DVD drive (just a normal DVD drive) since the cost of such a drive would probably mean that they wouldn't sell it at the same price as the DP-600. It may be interesting to point out though, that it does support VC-1 also, meaning that it is capable of HD-DVD or Bluray playback. If this one doesn't have a HD-DVD drive, then it might be worthwhile waiting for one that does. I also read that the design/pin out is the same as the chipset used in the DP-600. So that will help keep costs down and make it a relatively affordable player. Oh yeah, it even plays DVDs. If anyone is remotely interested, check out these links: http://www.sigmadesigns.com/public/P...EM8620L_br.pdf (Info on the Sigma chipset) http://ifa2006.net/linksys-and-ziova...od-hd-players/ (Short video at IFA 2006, God the cameraman is irritating) http://www.hardware.info/en-US/news/...iVXDVD_player/ (Couple of photos and general information) http://www.cdrinfo.com/Sections/News...x?NewsId=13395 (More general information, a little more in depth) Quote:
I don't understand why people go to the trouble of creating ISO spec streams, only to go and put them in a non supported container. If you view the file as a whole, it's only partially compliant (the streams inside are compliant, but strictly speaking the multiplex isn't since it's not defined in the MPEG docs). If someone is now so hell bent on encoding ISO spec stuff (not just for zomg more options, but a genuine dislike of hacky encoding), then give MP4 a try when it suits your requirements. Seriously, what detriment does MP4 do to you if all you are encoding is a H.264 video with AAC sound? None; plus you now have wider compatability, because more applications and/or hardware are likely to support H.264 + AAC in MP4, than they are the same streams in MKV. Regardless of what the MKV specs say; MPEG (and the rest of the industry for that matter) would view these files as non compliant. I can store unhacked H.264 and AAC in .zip, but it's still not an ISO compliant multiplex; and who exactly implements such a thing? In my opinion, if you are encoding for mass distribution, it makes sense to use an industry supported format, that will be supported in commercial software and hardware. I understand that some fansubbers, DVD rippers or whatever couldn't care less about leechers in general; but when you are distributing files to tens of thousands of people, you really do touch upon a huge spectrum, from the newest newb to fellow encoders, fansubbers, or whatever you percieve the upper level to be regarding fansub watching people. Some of these might have Nero installed and never heard of MKV or MP4 before; but MP4 will work for them off the bat. I'm sure there are other examples of commercial software supporting MP4. I'm not out to make MKV look bad here, but can you honestly say as many apps support H.264 + AAC in MKV as they do MP4? Even if it comes down to a retort along the lines of the lacking H.264 decoder features (eg. QuickTime only supporting Main); using MKV doesn't make the situation any better here. If you can't play encode X in MP4 in QuickTime (for arguements sake), then you certainly won't be able to play the same file had it been muxed as MKV. Going back to various whack H.264 supporting decoders, it's surprising what effect end users can have on the industry. What am I talking about? Well I guess you would call it supply and demand to some extent. Think back to the DivX players. They basically supported MPEG-4 ASP and the VfW hacks, with MP3 audio in AVI. This little combination seems familliar, doesn't it? Now I could be completely wrong (perhaps DivX went round recruiting prospective SAP manufacturers and talked deals), but these DivX players didn't emerge out of nowhere. They don't even follow MPEG specifications. What I assume happened was the supply and demand I talk about. Everyone was encoding and downloading ASP in AVI encodes, be it fansubs, DVD rips, or big screen movies, and it is that mass distribution which creates a market. Either DivX caught onto this (or it was part of their evil plan all along) and contacted some manufacturers to talk about creating these "DivX" players, or the manufacturers saw a potential market and went to DivX for information of their hacks and to strike up some kind of deal (what with the DivX logo and certification bullshit). The exact same thing happened with MP3 (actually I should have used this as my primary example since it's much more fitting). Everyone's encoding MP3, everyone's downloading MP3, people are getting sued in connection with MP3, and the media is all over MP3. It's small filesize, relatively good quality at the time, and the ease of availability made it the format which was (and still is) on everyone's lips. Then came the portable MP3 player; and now that we have micro HDD's there is a whole influx of MP3 players, some of which do more including video. If people hadn't been encoding and sharing MP3, I don't think the industry would be where it is today. Certainly there wouldn't be half the amount of MP3 players. Supply and demand. If people started encoding and using high profile H.264 on a regular basis, companies would see this and support it, in order to sell their products. Apple would probably want to improve their H.264 encoder too, seeing as they advertise via QuickTime player. But seeing how they don't support MKV, they wouldn't care less if everyone was using MKV with High or Main profile; it's MP4 files which would cause the hassle for Apple, people complaining it doesn't work with suchafile. To be able to advertise people, you need to get them to install your player first, and for people to do that, they need a good reason. A partial H.264 decoder won't cut it. This is part of my reasoning for "promoting" MP4 if you can call it that. The more people that use H.264 + AAC in MP4, means more presence in the industry. That would hopefully lead more fully implemented H.264 decoders, and perhaps people would sit up and listen, produce more H.264/MP4 supporting standalones or portable devices, and generally increase the sense of interoperability. You can of course do the same for MKV, perhaps that is what you would like to do, so I can understand the persistant MKV pimping; you want to raise MKV usage and awareness as much as I do MP4, amirite? You should be able to empathise with where I am coming from too then. Unfortunately for MKV, as good a work as it is by a group of individuals, it's more of an uphill struggle to next to impossible, what with it not being ISO standard (it may mean little to you, but it seems to be a big deal in industry), by MPEG and it's nature; in as much that it is always under development and can store a wide range of different bitstreams (the problem would be implementing the decoders what with patents and stuff). Quote:
Anyway, it's easy to get lost in our own little scene, it's like the outside world doesn't exist; either way MP4 is getting a lot of usage, be it for audio only (AAC), portable videos, or self made rips using Nero Recode (because Joe Average will not know how to use x264 CLI and MKVmerge, or even when presented with a GUI; simply be overwhelmed by the amount of options). As much as you may dislike MP4; you should be greatful for it. Were it not for MP4; shit like WMV and RM would have a bigger piece of the action. Thankfully MPEG was formed to lay the STFU down on their proprietary asses. Quote:
Take one scenario for instance, AMVs. There are some classic AMVs encoded in 2000 or so that are good old CPB MPEG-1, yet someone could go along to animemusicvideos.org right now and download one of those old AMVs and it would be new to them (in as much that they haven't seen it before and it's an "original" work). Now I've made AMVs in the past, my last one was H.264 + AAC in MP4 in October 2005. What's not to say that in a year or two we will have SD H.264 capable phones/games/mediaplayers? Someone could feasibly come along in 2 years, think, "Oh, this is new" and just throw in on the phone to check out whenever; similarly, they might just burn a disc full of AMVs, chuck it in their Linksys 1600 (or whatever) and watch it on their TV. More to the point, and here comes the DivX bitching once again; if we had been using MP4 for ASP from the start like we should have done instead of relying on hacks and AVI; hardware support and interoperability in general would have been much better. It really has been a damaging knock on effect. To come back to the original question, if ASP fansubs had been contained in MP4, then maybe they would work on the new iPod, and they ought to work on those current Archos portable media players too. Quote:
Quote:
Quote:
Quote:
Quote:
The MP4 players don't have that information, for instance max resolution or bitrate; decent players rely on the spec profiles and levels. So you have a scenario where such a player supports HP@L4. That tells you every thing you need to know about the video stream, because the H.264 spec is very detailed. In fact here is an example of the H.264 profiles and levels that I put together for my own reference some time ago. Rather than specifying their own bitrate and resolution constraints, I think it would be ideal if they find the Profile@Level for the codecs in question which is near to their requirements, and just reference to that. It saves the Matroska team a lot of work in the process too. Quote:
Quote:
I used to be completely against the idea of private streams, but AC3 in MP4 would be no more of a "hack" than AC3 in DVD, though I would still be cautious, but in theory if you are playing it in something like CCCP, the available splitters and decoders are in place for it to work (and it does), as for a SAP like I was talking about earlier, then it should work with that too (seeing as MP4 parsing is available and an AC3 decoder is available for DVDs). I don't know if this is a stealth troll; a sneaky "lol MP4 doesn't officially support Vorbis, so lets see if we can break it by putting Vorbis in" but if you want Vorbis, I would advise people gb2/mkv. It's not worth using something not explicity defined that is perhaps negligibly better; my suggestion would to be to use a higher bitrate (in cases where AAC falls behind Vorbis, a small amount of bitrate will bring it up to the level), or use MKV for Vorbis. At least you know Vorbis in MKV has worked for a long time, unlike MP4 where it is perhaps a grey area since no one really does it (they use AAC instead), and somewhat dependant on the player; unlike those players which do support MKV which already know how to deal with Vorbis. Vorbis in MP4 is not supported, it's better to to put it in MKV, otherwise it's a case of one less person using MKV and one more person fucking up standards. This is where you use your judgement and figure that it's better to use MKV rather than do hacky stuff with a standard (which would eventually mutate into a mess like AVI and .DIVX). Quote:
Quote:
We can agree that there are some lame fansub encoders (subme=1 GET), but IMO, there are suckahs in both scenes. Respect where it's due though, I suppose there are less "press butan, receive xvid" encoders in DVD ripping. Did you ever stop and consider the fact that fansubbers generally use TV rips and DVD rippers use DVDs? OH SHI- I should hope DVD rippers encodes are better, otherwise thats a pretty fucking poor show. You want irony? How about DVD rippers that don't want DVD playback, but ethical, "We musn't replace DVDs" fansubbers wanting DVD playback. Whack shit. I suppose if I am going to be tarred with the same brush, that I might as well act that way. "Well I guess we can't expect evil DVD rippers who jump from one format to the next to have any concept of interoperability." (By the way, I thought people knew me well enough by now, but if you didn't realise, this is only intended as light hearted banter). Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Rule number 1) When talking with encoders, never knock their stuff (some people are very sensitive). Quote:
Quote:
Of course there are no written rules for encoding; so it's not like anything would stop you releasing Q0 stuff if you felt that way inclined. Why the fuss with H.264 though, didn't you use huge filesizes before for XviD fansubs? I think what Starks was getting at was that even if you were using the same filesize as the XviD encode, you are still getting significantly better quality and he doesn't understand why you went so far beyond the XviD size with that in mind. The other thing to bear in mind is the raw quality; if it's been quantized at Q20, then it doesn't make much sense to encode it at Q16 for distro, that's only like having a 128kbps MP3 and encoding it at 192kbps. The quality is already gone, all you can really do is filter a bit and encode at a similar quantizer to minimalise any additional loss. I personally don't see a good reason for going beyond Q18 when dealing with crappy TV rips, but each to their own. Quote:
Quote:
Quote:
Quote:
__________________
|
||||||||||||||||||||||||||||||||||||||
2006-09-29, 13:11 | Link #468 | |||||||||||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Character limit reached...
Quote:
Quote:
Quote:
Quote:
Now rather than to touch on this subject, reply to some more stuff and come back to it a bit later, I'll tackle this now, as I have a few interesting things to say. First up, some benchmarks, now I obviously understand there is more to performance than how many MIPS your CPU can do, but this ought to give you an idea of the arithmetic capability (or lack of) regarding the C3. Basically the point I am going to illustrate to Nei is that using 1GHz as a measure of speed is useless. It's a measure of clock speed, yes; but the problem is that some processors do more instructions per cycle, rendering "GHz" as a measure, useless. Take a look at these images. First we will discuss image 1 before moving on to image 2. Image 1 I benchmarked my Nehemiah 800MHz, and compared it to a CPU with a similar score, and some other 1GHz CPUs as a "high anchor". Now from this we can see that an 800MHz Nehemiah core C3 has roughly the same processing capability as a Pentium 2 running at 400MHz. That's damn poor, very damn poor. Also note that Whetstone FPU score is practically half of the P2 400MHz. Now we will move on to the 1GHz C3's. The old 1GHz Ezra core isn't on the list in Sandra anymore, but after some googling, I found a value of 1218 Dhrystone MIPS, and 333 Whetstone MIPS. That makes the 1GHz Nehemiah, approximately 12.5% faster in Dhrystone MIPS and 85% faster Whetstone MIPS than the 1GHz Ezra. If we assume these values scale proportionally with clock speed, underclocking the Ezra to 800MHz would make it 974 Dhrystone MIPS and 266 Whetstone MIPS (though now, 257 Whetstone MIPS for my 800MHz Nehemiah seems like an anomolous result, perhaps it's been scaled back more to allow it to run fanless). As you can see, a 1GHz Athlon and 1GHz Pentium 3 have over double the arithmetic capability of even the 1GHz Nehemiah. When Microsoft say 1GHz, I would assume that they are referring to the equivalent of a 1GHz Intel CPU. As this graph quite clearly shows, 1GHz can mean anything in terms of performance, depending on the CPU. Unfortunately for VIA, this is not a threat to the x2 or Conroe. Let's move on to the second image. Image 2 Now for this one, all I did was change the reference CPUs to discuss this further. In this image, we can see that the 1GHz Nehemiah C3, has approximately the same ability as the Pentium 3 500MHz, in fact they are pretty evenly matched; but as far as Microsoft's and fansubbers suggestions go, your CPU only has half the recommended/required speed. Just because it is 1GHz, doesn't mean it is as fast as any other 1GHz CPU, you can see this quite clearly here. Even an 800MHz AMD Duron doesn't break a sweat against a 1.5GHz Nehemiah; and it was 6 years ago when I bought my first PC and it had a Duron 750MHz CPU (which was awesome, it even overclocked to 900MHz when I did the "pencil in the tracks" trick to change the voltage on the CPU). Wonderful; even VIA's best doesn't match 6 year old technology. Of course I know that these CPUs suck in comparison because they are designed for low power and so on; but still, that sucks loads. With a decent heatsink I can run my A64 3400 fanless (2.2GHz @ 1.0GHz/0.95V), and that would crank 3600 Dhrystone MIPS. Sometimes I wonder if the whole mini-itx shenanigans is just a very clever way of getting rid of 6 year old, surplus CPUs at today's prices... I would have loved to get my Duron 750MHz box up and running, that would have done an awesome job as a webserver; but I have to admit, the small form factor and completely fanless design of the mini-itx box I put together won me over. As for video playback; with MPC or mplayer2, it can just scrape by with a 704x400 generic ASP encode. Most times it's 80-90% CPU, peaking at max CPU which makes it lose sync/drop frames slightly. Quote:
Quote:
Quote:
Quote:
Quote:
Serious, you are running Vista on the equivalent of a Pentium 2 at 400MHz, with onboard video, onboard sound, onboard everything (all draining the CPU). It beggars belief. Quote:
Also in Firefox when you have a good few tabs open, almost constant 100% CPU usage. Quote:
However if you are not using so much bitrate or low quants, then using AQ when it's not required (ie you don't already have a problem with blue skies), may adversely affect the quality. I don't use it much, if at all; but it strikes me as an option that is very subjective, like lumi masking, inloop deblocking, or QPEL (in ASP). I don't mean to come across as trolling, but just beware and test; rather than thinking AQ is autowin. Also, while I'm on a roll, I might as well take this chance to mention that the MPEG-4 ALS (Audio Lossless) reference encoder now has MP4 output. I have encoded some test files, written a bit about it and whatnot at Doom9; so here are the goodies: http://forum.doom9.org/showpost.php?...5&postcount=38 The compression is very good considering it's unoptimized reference software; the speed is a joke (again what with it being reference software). Main thing is we have a working encoder. Haali's splitter seems automatically capable of parsing the ALS in MP4 seeing as it's stored the same way as AAC (not to mention others). All we need now is a directshow decoder At the moment there is just a Winamp decoder plugin.
__________________
|
|||||||||||
2006-09-29, 15:49 | Link #470 | |||||
In exile
Join Date: May 2006
Location: There! Not there! There!
Age: 36
|
Quote:
By funky filesize, I mean stuff that doesn't fit the norm of release sizes by other groups. (Example of XviD being 175MB or 230MB and H.264 being from 120-140MB, 175MB or 230MB.) Anything out of those numbers would likely be considered a "funky" size to most viewers. Quote:
Most fansub groups tell fans not to expect anything from them since it is a free service. I believe we should set down a rule that they shouldn't expect each episode to be exact same filesize or even in close distance of same filesize. It really should be up to the encoder per episode. (Just me ranting, don't take it to be too serious...) Quote:
Though I might still be one of them... but I do believe I have gotten better. And I know I still have a long way to go before I can compare to most fansub encoders. Quote:
(Zero1: I was happy to see that you weren't one of those people and did try to help instead). Quote:
And I don't even want to know how much time it takes Zero1 to type one of those posts...
__________________
|
|||||
2006-09-29, 22:06 | Link #472 | ||
Part 8
IT Support
|
Quote:
Quote:
As to the overhead... it would be an interesting test, especially with simpleblock. Actually, i'm not even sure if vfr works with simpleblock. Softsubs don't because the duration field for each frame goes missing. Will investigate and eventually come crawling back in shame or on a large white horse covered in the skulls of my enemies, whereupon I.... well, you get the idea. |
||
2006-09-30, 03:57 | Link #473 | ||
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
Quote:
Quote:
Now if you're shooting for those "mini-sized" releases which are famous for "they still look good" - in other words, you consciously sacrifice quality for gains in filesize reduction - it's possible that AQ might have adverse effects. My hand-on experience in this field is very limited, because I'm partial towards quality as opposed to low filesizes. But as long as you're not consciously walking on the edge of the bitrate chasm, AQ is a tremendous help and should always be enabled. Therefore, use AQ if you + encode with medium to high bitrates + filter for high-sharpness releases + try to preserve as many details as possible. |
||
2006-09-30, 04:51 | Link #474 | |
essense
|
Quote:
h.264 is great! i want to download more of it but seeds.. gah no one wants to dl more.. For those who bought a dvi cable over their analog isn't that a kicker.. lets spend money on mininal diffrences but not download hd content to make use of it! f yea man... my 2 cents (i feel the hawt hawt flames comming) |
|
2006-09-30, 05:25 | Link #475 |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
I experimented quite a while back with -aq, and yes, it did give better results in flat areas, however... I found that at the bitrates I use, it would significantly reduce the quants for the rest of the show if used at a strength where it would help significantly. For instance, an encode where the quants during high-motion scenes was 22+-4 would jump to 24+-4, with is a pretty significant quality loss.
Here, I'm talking about bitrates around 650-700, which is what I use for my 140 MB encodes. It's quite possible that once you get up to 800-900, -aq could be useful, but in my range, I personally think it makes the overall encode look worse overall. Also, when using TV sources, there is less of a problem, since fine background gradiants etc are often destroyed even in the original raw, so there's no reason not to just smooth away the noise (in which case, the use for -aq is moot). However, I do think -aq is very useful for high quality anime encodes, as mentar has argued.
__________________
|
2006-09-30, 05:32 | Link #476 |
Banned
Join Date: Nov 2003
Location: Hamburg
Age: 54
|
I'd say that -aq is definitely to be recommended for x264 encodes starting at 800 kbit (which effectively means, 170 meg releases class or higher). Below this line, you either have to have a marvellous source or you need to smooth and cut corners anyway ==> not what I was talking about before.
(That's not intended to be fighting words, Quarkboy, really) Since I don't encode below 170 meg releases, I use AQ all the way, and I'm very much aware why. |
2006-09-30, 05:47 | Link #477 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
__________________
|
|
2006-09-30, 08:06 | Link #478 | |
Senior Member
Join Date: Jan 2005
|
[QUOTE=Zero1]Your point being what? That some H.264 encodes are bigger than ASP (XviD/DivX)?[\QUOTE]
I think that is entirely the point. Seeing that AVC files are bigger then the XviD files gives downloader's the impression that AVC isn't as efficient. How the hell are they to know one has been reduced to SD format while the other is in the HD format. Quote:
|
|
2006-09-30, 08:24 | Link #479 |
*yawn*
Join Date: Jan 2003
Location: The sunny side of the Alps
Age: 41
|
Farix: simple - there's not enough users that would benefit from that - most of those that aren't afraid to go for H264 would go for the HD version anyway, and most of the rest don't want to change from XviD/AVI.
__________________
|
|
|