The H.264/AVC/MPEG4 discussion thread

[Mentar]

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.

[Harukalover]

Originally Posted by Mentar

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.

Yeah that's the only way to do so in MeGUI from what I found.

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.

[checkers]

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.

[SirCanealot]

Originally Posted by checkers

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.

You'd be VERY, VERY suprised...

[Musaran]

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 ?

[Harukalover]

Originally Posted by checkers

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.

Hmm... I always believed that anime encoding was a rather large field in video encoding. Just look at how many avisynth filters are made specifically just for anime. But again if MeGUI developers are not interested in anime encoding at all then I guess they won't be seeing AQ as a high priority to add in.

Originally Posted by checkers

Of course if you are willing to update the megui code yourself I'm sure they'll gladly take the patch.

Well if I learned how to code I probably would take a shot at it. But at the moment I'll leave it to the developers and just hope on it. (Since they do it for free it's up to the developers)

Originally Posted by Musaran

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 ?

Well from what I understand CRF doesn't decide on distributing bits between highly complex scenes and low complexity scenes as well as a two pass encode would. Also I have read that a 2 pass encode will decide better on the optimum quantizer to use for I-frames.

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.

[Zero1]

Originally Posted by mog08

you missed my point, Zero1. I wan't talking about watching AVC coded videos. i was refering to x264 encoding.

Chevalier 1 XviD AnimeYuki 172.6 Mb
Chevalier 1 H.264 AnimeYuki 231.5 Mb

Kemonozume 1 - XviD version AF-F & Y-F 233.3 Mb.
Kemonozume 1 - h264 version (HD) AF-F & Y-F 233.1 Mb.

Night Head Genesis 1 - XviD version Ureshii 174.8 Mb
Night Head Genesis 1 - h264 version Ureshii 247.8 Mb
Night Head Genesis 2 - XviD version Ureshii 174.8 Mb.
Night Head Genesis 2 - h264 version Ureshii 247.8 Mb.

Coyote Ragtime Show 6-7 - h264 version AnimeYuki 345.8 Mb
Coyote Ragtime Show 6-7 - XviD version AnimeYuki 341.6 Mb.

Honey & Clover II 2 - XviD version C1Anime 174.7 Mb
Honey & Clover II 2 - x264 version C1Anime 249.7 Mb

this is the reason why H.264 has not yet taken over anime fansubs.

Your point being what? That some H.264 encodes are bigger than ASP (XviD/DivX)?
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.

Originally Posted by mog08

why use it if it doesn't beat XviD?

It does beat XviD, and has done for something like 2 years at a guess. However it's not a failing of the codec if the filesizes are larger due to a) the encoder wanting to use more bitrate, or b) using a higher resolution.

Originally Posted by mog08

I can't say for sure but 50-90Mb is usually enough for a 23-25min anime episode.

Different animes, sources and/or whatever can differ vastly in "required filesize at a set quality". Some videos simply need to have large filesizes. There is also the problem of people's perception. What you view as good quality, or myself might be totally different. I encoded .hack/Roots (704x400) at 57MB some weeks ago, and it's what I would call only just releasable (no major problems as such, but the quality wasn't just up to release standard). Unless I was under specific constraints or requests, I would have gone in at the next reasonable filesize, which by the looks of things would have been 86MB. The legacy version I encoded of the same file required 115MB to look decent (even then, it's probably still lower quality than the H.264).

Originally Posted by TheFluff

What? If I understand you right, it's the complete opposite: you have to pay licensing fees to use patented MPEG technology - usually a fixed sum per "distributed implementation" or something like that. The only reason things like XviD or x264 can get away with using said patented technology without paying anything is that there's not really anyone worth suing, and even if there was the legal situation is unclear, especially since many of the developers are not US residents.

That's right, I know about the licensing fees, of course, but I was grabbing at straws as to why a company would pay said fees, buy the standard and implement some MPEG technologies, but not implement something that is free and available. I guess it comes down to "If we implement MPEG-stuffs, people will buy our products". I just wondered aside from the additional business and sales they would generate from implementing MPEG in their (insert name of device), if there were any other rewards or perks.

Originally Posted by TheFluff

What (again)? As far as I can tell, Nero's way of implementing it is in NO WAY supported by the standard, and is reliant on the splitter being capable of making sense of the attached custom user data. MKV's chapters, on the other hand, are actually a part of the standard (and said standard not being issued by an industry consortium has no relevance whatsoever - a standard's a standard, and Nero's way of storing chapters is NOT standard).

BTW, if you want to use the full potential of MKV chapters, like the ordered chapters stuff (different parts of the video residing in different files but being played as if it were in one), nested chapters etc. you have to hand-edit a rather large-ish XML file, but if you just want the standard jump-to-this-timestamp chapters, you can use the tried and trusted Ogg chapters format (also used in OGM), which looks like this

Correct; I didn't mean to come across as suggesting Nero was in any way standard, you and I both know they are stored in user data. It wouldn't be half as bad if Nero applied for it to become standardised (as far as I know, companies may expand the standard and apply to have it approved, and eventually make it into the spec as an amendment and/or addition, hence MP4 being an open standard). What I meant to say is that although using Nero style chapters is non spec and IMO not good; it's more likely to be supported in hardware or software as a whole than MKV and it's chapters. What we need, or should be doing is creating BIFS scripts for the chapters, a better method would be that mp4box can take the Nero chapters and automatically generate the BIFS script so that Nero chapters are interpreted and converted to spec compliant chapters. The only thing that I would question with spec compliant chapters is MPEG-4 Systems support. Since chapters effectively come under systems (and so menus etc.), I wonder if popular software like Haali's splitter would read the spec chapters already (I suppose it depends to what extent he has implemented systems). If however you are encoding for PC playback and nothing else, then as much as it pains me to say (I see Nero as the new DivX here to some extent, mangling standards), non spec chapters wouldn't really matter, since non whack software reads them (such as Haali (and in turn, CCCP) and Nero). But enough splitting hairs, I see where you are coming from. Yes, those large XML chapters are the ones I was referring to.

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...

Well at least you would get a somewhat consistant quality and only use as much filesize as you need, as opposed to something hitting CRF 18 at 140MB + audio and so padding to get it to 155MB + audio (or whatever), or just missing a filesize, eg CRF 18 at 180MB + audio and lowering the quality to hit 172MB including audio. Of course you may get people bitching why is one episode bigger than another, or why don't they fit nicely on a CD/DVD. It would be interesting to see how it goes down.

Originally Posted by checkers

aac.96kbits sbr (sounded better, honest zero1!!)

I hope you aren't being facetious now... To be fair though, have to give you the benefit of the doubt. I guess in some cases good quality ~12KHz could sound better than ringing/flanging ~15/16KHz; but to be honest, I don't think that 96kbps LC-AAC is expecting too much of it (yeah, of course I know it's a codec and not magic, but it is significantly improved over MP3), which brings me to my next question, which HE and LC encoders did you test, also did you try Vorbis? I would have been tempted to drop the audio bitrate a little if I could get away with it, and just ease up to around CRF 20, source permitting.

Originally Posted by checkers

mkv2.sans chapters or other space eating frivolities.

Encoder paradox! You seem to have grasped the concept that for low bitrate encodes, every little counts (even going as far as using MKV v2 to save those valuable KB's), yet in the VFR thread you rubbished using VFR saying:

Originally Posted by checkers

as a point of interest - h264 takes only 8 bytes for encoding a frame that is identical to the previous frame (ffdshow reports it as 9, but that's another story). So in the interests of sanity you are generally better jsut using dup(), which makes almost identical frames identical, rather than dedup(), which actually cuts out almost identical frames for a vfr output.

Is disagreeing with me for the sake of it the new hating DBZ cause it sucks? "Hay guyz, Zero1 said something funny on the interweb and I disagreed, am I cool yet?"
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.

Originally Posted by checkers

So the SAP is where mp4 will be an advantage for anime ep playback. Let's take a step back and look at history though. The two SAP compatible formats around at the moment are *VCD and DVD. Well, DVD authoring has always been a bit of a black art with anything that's not asp/mp3/avi, and it's reasonably rare to do that to watch anime eps. VCD authoring, well I've not known a single person talk about doing this, even when they were cool, but having said this I'm sure people will now come along and tell me how often they did this and how great it is :P. In short, anime SAP playback to date has been of almost zero interest.

SAP hasn't been of interest because authoring is such a pain in the ass. Say I have all my stuff burned on DVD, they might be a mix of AVI, MP4 and MKV files. Obviously I need to transcode these to MPEG-2; not a big deal for the likes of you or myself, or any other encoder reading this thread. If it happens that I have some streams that don't particularly want to play nicely for whatever reason, I may have to demux them, then transcode them. It's just wasted time and effort that I don't have these days. Then when it's encoded to MPEG-2, after having lost even more quality in the process, it's time to burn them. Say I have a 26 ep series, that's 6 or 7 DVDs compared to the original distro which might only be 1 or 2 DVDs (based on common sizes, possibly less with H.264 encodes). So big deal, DVDs are cheap now anyway; but thats probably 5 mins (at best, could be as much as 15 mins if you have an older writer) burning per disc which I could do without, and more discs/clutter which I certainly haven't got the space for. I think the average user would be much more open to SAP playback if it was as simple as inserting a DVD full of fansubs they burned at some point in time and it just works. Even codec retards or people with slow computers could benefit, providing they are intelligent enough to download the release and burn a data DVD.

Originally Posted by checkers

o It's... frowned upon by many encoders

Indeed, but of these many encoders, how many are worth listenting to? There are only a handful that I will entertain, and I really think the majority of so called encoders are probably "press butan, receive XviD" types (I owe TheFluff for that one, it's stuck with me). Just because many encoders say or do something, doesn't mean it's good or correct; we only have to look back on how everyone was using ASP in AVI (and I still maintain that it played a fair part in the mangled state of ASP decoders/software/hardware etc). Of course we have moved on to H.264 now, but isn't GMC and QPEL in ASP still "frowned upon"? It's at least excluded from the "fansub encoding standard" that everyone seemed to follow for those few years. And think now; we have FFDShow (CCCP) and XviD, which are working, non-whack decoders. Why do people still follow these "scene standards"? As I've said before, it's amazing how many people are sheep. There are of course some "scene standards" which have fair reason, such as number of max consecutive B-frames, which is consistant with the DCT drift you can get in ASP. I know at the time people considered GMC too computationally intensive (now that shouldn't be an issue these days should it?), and in my opinion QPEL is questionable, but that doesn't mean to say these should be automatically outruled due to how everyone has just played "follow the leader and don't ask questions".

Originally Posted by checkers

This is of course with the addendum that the SAP supports the codecs in use, which are likely to be h264/xvid, aac/vorbis and hardsub/srt. I doubt many SAPs will play srt subtitles (vobsub is a possibility), vorbis is obviously out of the question and AAC will of course require additional licence fees as it is not part of the spec for either HD-DVD and blu-ray.

What is impossible to tell is the availability of compatible BD/HDVD players and the uptake they will have - time will tell and not much else will

Well just recently I had some interesting news...
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:

Originally Posted by Nils Hougaard

Hello Michael,

Thank you for contacting Linksys and for your interest in our KiSS products.

In addition to your product request I can announce that we will not launch the
so-called DP-700 model, however, we will launch the KiSS 1600 high definition
media player instead. This model will support H.264 and AAC as requested and we
launch the player during November this year.

We will have final product information and specs available during October, but
basically the features will be similar to the once on the existing DP-600 model.
Please check www.kiss-technology.com for details.

I hope this information was what you were looking for and we hope you will
decide on a KiSS 1600 when launched.




Med venlig hilsen/Best Regards

Nils Winkler Hougaard
Sales Manager

Linksys
Slotsmarken 10
2970 Hørsholm
Denmark

For the record, the DP-600 already has MP4 support, so I like where this is going. The only thing that remains to be seen is if there are any whack limitations. This machine will be using a Sigma EM8622L chipset, which is capable of BP@L3 (wtf), MP@L4 and HP@L4 (L4.1 is identical to 4, with the exception that the max bitrate in 4.1 is 50mbps as opposed to 20mbps). As for ASP, they say ASP@L5; but remember, ASP only covers resolutions up to 720x576 officially, HD and above resolutions are covered in stuff like Main and ACE (Advanced Coding Efficiency), and whack stuff like 2048x2048 is in Studio profile. This isn't to outrule HD ASP, you see if they wanted to include the "official" profiles and levels for HD resolutions etc, it would mean they may have to implement other decoding tools also covered by the profile (else it would only be a partial implementation), so unofficially they say 720p ASP is also supported.

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)

Originally Posted by Nicholi

The only reasons I have seen stated, in your opinion, are that it is a standard and interoperability. Which don't seem to go far on their own as TheFluff noted.

If standards or interoperability count for little or nothing; then we may as well go back to VfW (ironic seeing as back in the day people were so intent on using MKV that they resorted to using VfW x264 anyway). So why do we go creating ISO streams if whether something is ISO standard or interoperable doesn't matter? It would be less effort to use Virtualdubmod, encode using x264 VfW and mux some Vorbis or AC3 in and output to MKV. Any MKV fan would condemn that suggestion (I would also, from a point of bastardising H.264), but if following ISO specs doesn't matter, then why would encoding in that way?

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).

Originally Posted by Nicholi

It does mean it has a more likely chance to be adopted by other companies, but as we can see that hasn't gone far in the video domain yet at least. But where does the interoperability arguement really come in?

I have already touched on interoperability just a few paragraphs ago; but that is not my reason for picking out this quote. Outside of fansubbing and DVD ripping, MP4 has a good amount of usage (no doubt a hell of a lot more favourable to WMV, MOV, RM etc); obviously it has the advantage in it's name. People are semi-familliar with it from how well known MP3 is. Any newbtard could probably guess that MP4 is audio or video related just through all the press about piracy and stuff MP3 has got, but if you asked the average non-fansub viewing PC user what an MKV was, they more than likely wouldn't have a clue. This is where people begin on the road to failure; not knowing what MKV is or how to deal with it, they may download a random codec pack and totally fubar their system (I'm sure you've seen that before in #cccp). Also it would be another newb on a forum complaining how MKV is unstable etc. etc. (through their own fault mind you), which amounts to bad press, flame wars and other retarded shit.

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.

Originally Posted by Nicholi

How are H.264 or even MPEG4 ASP .mp4 fansub files interoperable with anything else? They certainly won't be working on any mobile phones or PSPs unless you encode at extremely low resolutions/framerates. Which is what we are talking about here, MP4 for use with anime fansubs.

They aren't interoperable with low powered devices yet for obvious reasons, again whether you used MKV or not does not change the situation (so less of the, "It doesnt work on suchadevice, therefore MP4 is pointless"), it would still not be interoperable. However, as anyone who owns a computer knows, CPU power is always increasing, so these phones/handheld game units/hand held media players could be capable in the not so distant future.

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.

Originally Posted by Nicholi

But anime fansubs are typically going to be starting at Main@3 and up in terms of H.264 at least (but equivalently in ASP), amirite?

Fansubs produced in the last 2 or 3 years are almost exclusively ASP@L5 (ASP only caters for up to SD resolutions, and so 640x480 falls within the upper levels). There are extensions to ASP (as I have touched on before), that may also include one or two new coding tools.

Originally Posted by Nicholi

Strangely alot of them support only AAC and not MP3 (as well as many other things)

Yeah, a lot of things are ASP+AAC or H.264+AAC; same deal with mobile phones and stuff. MP3 should have been put out of commission a long time ago, I think this reflects it a little (when you consider how old ASP is, but due to us using AVI hax, we was stuck with MP3).

Originally Posted by Nicholi

There are other alternatives such as Matroska which can do the same and more, at least on a PC. Just as well the future holds lots of things in store, you don't know any more then I if MKV won't be adopted in just as many MP4 devices.

True, although it's apples and oranges to some extent, MKV vs MP4 is a bit like Beta vs VHS, or Bluray vs HD-DVD; just because it's more flexible, doesn't mean it will necessarily do as well as it should or could do. Look at Bluray, it has a larger capacity, you can't lose on the surface, but due to other factors, it's expected to fail in a big way.

Originally Posted by Nicholi

Lots of hosers never though Vorbis would make it far either, I don't think they had even dreamed of standalone support back then. But now it has a decent amount of standalone players which can play it, and it was also just a patent free opensource format. Wasn't a zomg "industry standard" or had any interoperability really.

I have to admit, I'm surprised it's done as well as it has done, and it deserves it. You know how I hate spending bits on audio, and Vorbis helps reduce the amount of bits required. Vorbis good, vorbis friend. However, implementing an opensource, patent free audio decoder is different from implementing MKV for instance. Vorbis only has to concern itself with it's own raw files (or however it's stored) and decoding the audio. As for video, there are many different codecs, resolutions, framerates etc, not only that, but as far as MKV working, requires a compliant decoder on the other end. Parsing the files is one thing, decoding them is another. There is probably only Theora and Snow which are patent free and opensource which you could implement free of charge. I also wonder if the likes of MPEG or Microsoft would have anything to say on the matter that you aren't storing the encodes in their containers, and basically forbid the decoding of MPEG-* or WMV in MKV.

Originally Posted by Nicholi

I'm not quite sure who you are jabbing at with vague, it seems pretty straightforward to me. It is only a draft at the moment and the main thing I see it completley missing for the "standard"-centric people would be the H.264 levels? Is that the only thing? The minimum bitrate, resolution almost do a valid job of that on their own, but ohnoes it doesn't say! I doubt many current MP4 devices even have such a specific list of what/what not can be played. However a few simple numbers can be added to list the H.264 level to make it less "vague".

I'm not intentionally jabbing at anyone; it's just my humble opinion. If it's to be used in conjunction with the relevant spec of whichever codec, then it could be fine as is, but there are many more factors in a videos complexity than just resolution and bitrate. Don't forget max number of consecutive B-frames, max number of reference frames (which would come under the picture buffer), max framerate (or rather max number of macroblocks per second is the usual measure), max motion vector range etc. Of course it's all relative too. Are these global limits? Obviously a player capable of H.264 @ 4mpbs is likely to be able to handle MPEG-2 at a considerably higher data rate (providing the limiting factor isn't the drive speed; the calculation for max bitrate for H.264 has to consider CABAC time too). Also taking the Home Theater profile into account, I don't think 4mbps as a global limit really works if you are including 720p MPEG-2 in the spec, for example MPEG-2 stream dumps. (I mean hell, 4mpbs SD MPEG-2 doesn't look too great).

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.

Originally Posted by Nicholi

Unless you want to continue explaining why "MP4 is a standard and has tons of interoperability" (complete paraphrasing by a hoser) it is a good choice for fansubs, lets drop it. I see from your last post you are taking it worse then I meant it to be, and your opinions far more then some peoples I do respect. We could at least talk of other things which are MP4 related which I did just learn about.

Sure, if you want to agree to disagree, then that's good enough for me. Really all we are doing is chasing our tails and reposting the same shit eachother says. Anyway, enough of that. Trying reason MP4 with MKV users is like trying to turn Sega fans into Nintendo fans, Nvidia fans into ATI fans or Mac fans into PC fans. Every thing has got it's own little format war. It's just one of those things where both parties have an opinion and eventually it just goes round in circles; and I can't longpost indefinitely. MKV obviously suits your needs (I assume you use Vorbis and softsubs), and to date, MP4 suits my needs (H.264 + AAC). We can leave it at that. The only reason this cropped up is because I am of the opinion that for something that doesn't require any MKV features that you might as well use MP4 and be a) completely ISO compliant and b) a bit more interoperable. But enough, let's leave it be.

Originally Posted by Nicholi

MP4Box has for sometime added support for muxing Vorbis streams. Which is of course compliant in that MP4 allows for non-ISO streams to be muxed and defined as a particular track ID. Now I'm just thinking in terms of how that can lead to just as many problems, or possible advantages. Would that mean muxing Vorbis into MP4 is muxer dependent, or is the track ID something universal for each particular format? I mean that has to be just one of the major drawbacks for lots of people is, no native support of Vorbis in MP4. However if the track ID was a universal identifer and not something arbitrarily chosen by the muxer developer, that would make it pretty easy for Vorbis support in MP4 to be furtherly adopted. If it's not, painful futures await us with MP4 if more muxers become majorly used and are not doing the same thing. Just newbly thinking here.

I would think that Vorbis would be stored as a private stream (much like how AC3 is stored in MPEG-2). As for the ID the stream would get, I don't know. As for playback, I would assume that the parser would check the private streams and look at the file header for information as to what codec it is etc.

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).

Originally Posted by Ronbo

On the other hand! If anyone can provide me with a link to an non DVD (network capable) SAP that plays HD (1080i/1080p) H.264/MKV files and is not an MPPC (HTPC) please do so!

If you can hold fire for a couple of months, the KiSS/Linksys 1600 (or DP-1600) ought to fit your needs (has at least a DVD drive and 54mbps WLAN AFAIK). Unless the iTV is using the same chipset as the Linksys 1600, I wouldn't get excited about it.

Originally Posted by Mentar

I can't help myself but point out one hilarious discrepancy

It's evident that most of those people vociferously arguing for .mp4 as the allegedly more SAP-friendly format happen to originate from groups which fancy themselves to be "ethical" fansubbers, as in "stop distribution when licenced", "don't touch DVD material" etc.

Contrary to that, most people supporting the mkv container come from "evil wareZsubber" or "ripping" groups. They on the other hand, care very little about burn-swap-and-forget, and are more concerned about video quality issues.

Talk about ironies

I hope you didn't include me in that sweeping statement; that wouldn't be very fair now, would it?
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).

Originally Posted by Mentar

In fact, many .mp4 releases out there aren't h.264 at all, contrary to what they may seem. Therefore, the evil isn't the container, it is the used featureset and the CPU requirements of the codec.

Can you sauce me on that? I expect ASP in MP4 to be a hell of a lot more unlikely than H.264, because most people would just "press butan, receive xvid/avi".

Originally Posted by TheFluff

Wow, that's either a very good troll, or a really stupid comment. In either case I feel obligated to reply.

You did well to follow that, I just got a syntax error (unless it's simply getting late now).

Originally Posted by mog08

if you were hungry, after shopping with your lovely imouto who's eager to share a strawberry milkshake with you, would you go to Mcdonald's which is 5 steps away, or would you rather drive 2 blocks for an Italian resteraunt. disagree all you want to if you were to.

I quite like Mc D's milkshakes; but I like high quality video also. Sorry to blow that analogy out of the sky.

Originally Posted by mog08

Why no softsubbing? scripts might be stolen. some things have to be hardsubbed in the first place. no perfect image? buy the original DVDs. Softsubs suit hentai animes better.

Scripts can still be "stolen" if they are hardsubbed, it just requires more time (and effort I guess, but having never done it, I can't say so truthfully).

Originally Posted by Starks

I hate how long the transition from Xvid to H.264 is taking... I also hate the sloppy manner in which conformist encoders are misappropriating bandwidth and filesizes in the dual releases... It looks so foolish.

Now that you mention it, it has been a while. I guess not everyone is ready for the awesome.

Originally Posted by Starks

I'm sick of Xvid and H.264 encodes being released together and sharing a common filesize (like 175MB) and I'm also sick of the stubbornness of certain encoders who stupidly choose to make the Xvid release the smaller and the H.264 the larger of the two releases.

At the time of reading this, I just knew it was bound to upset someone.
Rule number 1) When talking with encoders, never knock their stuff (some people are very sensitive).

Originally Posted by Alizar

Not everyone shares the same standards, either for visual or audio quality. So if you want to do smaller encodes, feel free. I don't see anyone stopping you.

I have a sort of rule of thumb. It's not something that I sat and thought up one day, but thinking about it, it's more or less just an observation of my encoding habits. For one off stuff like my own AMVs, I'll go all out for quality. More or less max settings, and I may aim for something around CRF 16-18 (of course it depends a bit); similarly with series that haven't been licensed for ages, and are likely to be unlicensed for ages or not at all (like Gundam X). I guess these would qualify as "keepers" and I would focus mainly on quality. As for stuff like fansubs from TV rips, stuff that easily reproducable, is bound to get licensed, or otherwise replaced by a higher quality version (ie an official DVD), I will aim more for a good trade off. Perhaps in the region of CRF18-20. Low bitrate compression tests are a law unto themselves, they may go from CRF 20-24.

Originally Posted by Mentar

Because there are people like me who actually prefer watching animes _without_ blocking in the dark parts, _without_ ringing around sharp contrasts and still _with_ details in the background animation. In the cases of fansubs you very rarely can go below 170 without losing that (then you need near-perfect video sources, and you usually don't have those).

I think Starks assumes that filesize is proportional to incompetance, "lolol, 350MB fansubs, you must suck".
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.

Originally Posted by Mentar

3) "I want the best version possible, even if it means to wait a little". These are the folks which go for the h264 HD or DVD versions, and they don't care about filesize at all. 340 megs for a h264 mkv encode? No problem. After all, they will generally have downloaded version 2) aswell. Those extremists are around 1 out of 10.

Guess I fall in cat 2, but if I'm doing something specific (like an AMV where the DVD isn't available yet), then I'll go out of my way to find the best quality possible; then I fall in cat 3, in which case, should I not be able to find a raw, I would only be greatful to a minority like yourself even if it goes unappreciated most of the time.

Originally Posted by Mentar

I never see "which version is the smallest" in the channels, but alot of questions "which version is better".

In any case, feel free to do your encodes in whichever format you prefer. But for now, chill and collect some experience before you diss around. It's the anime which matters, not the technology.

Good calls.

Originally Posted by Nicholi

Hell the fansubbers could even get "zomg leet" insider info on how to correctly translate names/places/things. Think of that, fansubbers asking the creators if they can translate a show and also getting protips?! Lawls.

I loled hard, protips from the producers.

Originally Posted by emptyeighty

Just to add to this from my personal experience: When i started helping people with playback problems in #CCCP about six months ago there were about 2-3 people a day with problems. Now there's hardly one in two days in my "shift" (European timezone) - and that is considering CCCP is downloaded an estimated 400.000 times each month. So in conclusion it's safe to say that h.264/mkv/mp4 is ready for the primetime in every way.

Nice stats there. I think we get the idea that H.264 is relatively accepted now what with how dormant this thread has been recently compared to how active the previous one was before the crash. If those two threads were merged, that would be some serious replies/views going on. I've also had quite a few people come to me about H.264 encoding (mostly AMV editors and a few fansubbers); so it's on the rise in general.

[Zero1]

Character limit reached...

Originally Posted by Nicholi

Did you ever use the noodle-like object in your head to wonder why H.264 explicitly did not work on Windows Vista?

Must be a PEBKAC; in the short time of testing some random Vista ISO I found months ago, H.264 worked perfectly.

Originally Posted by Sylf

Sure, we may have left those people who use 450Mhz machine in the cold. But like many people has echoed each other: we're not going to keep supporting 8 year old cutting edge technologies forever.

My RAID card is faster than that. It is surely the time to move on. Hell, when I got my first PC in 2000 it was a Duron 750; since then I've gone through that, a 2600XP, A64 3400 and an A64 4800x2. I don't have a megabux job, and capable hardware is dirt cheap now. I mean for around $400 you can get a Sempron 3100, 256MB RAM with 80GB HDD. It's no powerhouse, but it's certainly capable for fansubs.

Originally Posted by Nei

Vista works fine, but h264 playback is impossible - regardless the operating system.

This is because in video you need to process a certain amount of data in a certain amount of time. If the CPU is not fast enough, it cannot do that and so it lags. As for general Vista usage; it's not time critical, so even if the CPU is too slow, all it means is that stuff will take longer to load. Apart from that there would be very little detrimental effect (perhaps stuff would be idle for so long it would stop responding).

Originally Posted by TheFluff

Via C3? No wonder it doesn't work. That "1 GHz" processor is probably equivalent to a 750 MHz PIII or less when it comes to general performance. For video decoding, it's essentially the moral equivalent of a typewriter. Add in the fact that the video decoders are optimized for Athlons and Pentiums... probably not even CoreAVC is enough.
My only advice for you is "get a real CPU". Sorry I can't help you any further, but that Via C3 is really not what we mean when we say "1 GHz CPU".

Indeed. If it's one of the early generation C3's (Ezra core), then those really are miserable (yes, it's worse than you think). I have a VIA C3 also; it's an 800MHz Nehemiah core (Epia-SP) which I use as a fileserver, IRC logging and BT seeding. The nice thing about it, it that it's completely silent. It's fanless, and has one of the quietest notebook HDDs on the market. It is also very low on power, so it doesn't bother me to leave it running 24/7 (as opposed to something like my new rig which is a watercooled Athlon 64 x2 with 5 HDDs. It's a bit of a power guzzler).

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.

Originally Posted by emptyeighty

Also note this screenshot of a C3 800MHz running Vista idle at around 37% CPU usage.

Beat me to it. That is my 800MHz Nehemiah I was talking about. I installed some random Vista ISO (as I may have mentioned before, you kinda forget what you said when you are longposting) a while back just for kicks to see what score it would get. The assumption is that 1.0 is the lowest score Vista will give, and I'm not sure how that 40GB notebook drive scored so relatively well compared to the rest of the system.

Originally Posted by Starks

2. VIA C3 lacks essential instruction sets.

It lacks everything, but it (the Nehemiah core at least) does have MMX and SSE.

Originally Posted by Nei

Isn't the fact just that h.264 isn't as compatible as you initially claimed, and you now try to justify that ?

H.264 is compatible as anything. In fact out of all the video standards, it's probably the one covered most in depth. On the other hand, do you think that when MPEG and ITU began work on H.264 that they took into account that it would take approximately 2 or 3 years to finalise the standard, and consider that people using 6 or 7 year old technology/performance would be wanting to play H.264? As good as they are, they don't have insight into the future, so they create a codec at the time which is highly advanced, which by the time it is finalised, is relatively reasonable playback wise when you consider the advancement in technology made in those 2 or 3 years of development.

Originally Posted by Starks

Nei, why are you even running Vista?

Because it's a 1GHz processor, obviously.

Originally Posted by Nei

Starks, why should I not run Vista? It feels faster than XP, the new security system convinces me, and the updates they have done to Explorer for Windows 6.0 are alone reason enough for me to prefer my Vista install over my XP one.

How the hell can you suffer it? I'm running Windows XP Pro, and I've disabled anything eyecandy related to even get sensible response times; and it's still slow as shit. Is this a C3 on a mini-itx (all integrated stuff), or is this a C3 on a proper motherboard, with a seperate graphics card and whatnot, because on this Epia-SP, the job lot is integrated, and I don't see how it would run Vista smoothly if it can't even run XP in good time.

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.

Originally Posted by Nicholi

I wonder how long it takes a C3 just to open Internet Explorer.

For your amusement I did a unscientific test with IE6 and Win XP Pro. Around 3 or 4 seconds with nothing eating away at CPU time. 38 processes running.
Also in Firefox when you have a good few tabs open, almost constant 100% CPU usage.

Originally Posted by Mentar

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.

Unless something has changed significantly; the AQ patch was added by Haali as an easy workaround for the problem of blue areas like skies not looking at their best. It's a simple patch that bombards blue areas with bitrate/lower quants at the expense of the rest of the image. Now obviously if you are encoding at 350MB/Q16 or whatever, you can't lose since the quality of the surrounding areas will not be reduced enough to affect the quality noticably (say a worst case scenario would cause the quantizer of some blocks to fall to 18/19, it's still very good quality).

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.

[Eeknay]

Unlimited Longpost Works / Bankai!11 / etc etc.

[Harukalover]

Originally Posted by Zero1

Different animes, sources and/or whatever can differ vastly in "required filesize at a set quality". Some videos simply need to have large filesizes. There is also the problem of people's perception. What you view as good quality, or myself might be totally different. I encoded .hack/Roots (704x400) at 57MB some weeks ago, and it's what I would call only just releasable (no major problems as such, but the quality wasn't just up to release standard). Unless I was under specific constraints or requests, I would have gone in at the next reasonable filesize, which by the looks of things would have been 86MB. The legacy version I encoded of the same file required 115MB to look decent (even then, it's probably still lower quality than the H.264).

Very true. But I believe it should be pointed out that many encoders probably would be afraid to do encodes based on what they think it takes cause you may get "funky" filesizes. Viewers will only see that it is a strange filesize and think right away that means it's of bad quality. While the encoder will see that it looks perfect at that size.

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.

Originally Posted by Zero1

Well at least you would get a somewhat consistant quality and only use as much filesize as you need, as opposed to something hitting CRF 18 at 140MB + audio and so padding to get it to 155MB + audio (or whatever), or just missing a filesize, eg CRF 18 at 180MB + audio and lowering the quality to hit 172MB including audio. Of course you may get people bitching why is one episode bigger than another, or why don't they fit nicely on a CD/DVD. It would be interesting to see how it goes down.

I think encoders really should encode to what they feel a episode needs. And not encode just to fit the episode at a projected filesize.

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...)

Originally Posted by Zero1

Indeed, but of these many encoders, how many are worth listenting to? There are only a handful that I will entertain, and I really think the majority of so called encoders are probably "press butan, receive XviD" types (I owe TheFluff for that one, it's stuck with me).

Actually I think there are more encoders who are a bit more proficient these days. They've gotten past "press button, receive XviD" and now use avs scripts with random long strings of filters thrown at the video.

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.

Originally Posted by Zero1

... should be automatically outruled due to how everyone has just played "follow the leader and don't ask questions".

I think there's a reason why many do this. Most new-encoders see certain encoders as being very talented and see them as the person to listen to. Now I do agree it's best to test and see instead of following a leader. But many are afraid of what might happen while doing this testing. I think we all saw what happened to a certain person who doesn't follow with everyone else. (Involves H.264 in avi). I believe it's best to let someone learn a bit then to constantly bombard them with insults as I saw by a few involved with that certain person. But now because of that situation I think many new encoders will be even more fearful to not follow the leader.

(Zero1: I was happy to see that you weren't one of those people and did try to help instead).

Originally Posted by Eeknay

Unlimited Longpost Works / Bankai!11 / etc etc.

Indeed. I have to set up a time during my schedule to read a Zero1 post.

And I don't even want to know how much time it takes Zero1 to type one of those posts...

[DryFire]

Wow I started reading the post and have run out of time; hopefully I'll finish the novella by monday.

[checkers]

I hope you aren't being facetious now... To be fair though, have to give you the benefit of the doubt. I guess in some cases good quality ~12KHz could sound better than ringing/flanging ~15/16KHz; but to be honest, I don't think that 96kbps LC-AAC is expecting too much of it (yeah, of course I know it's a codec and not magic, but it is significantly improved over MP3), which brings me to my next question, which HE and LC encoders did you test, also did you try Vorbis? I would have been tempted to drop the audio bitrate a little if I could get away with it, and just ease up to around CRF 20, source permitting.

ya got me! I tried none of them bar AAC-LC, and i only compared the opening song. I'm the oppposite of an audiophile, but I thought it sounded a leedle better in HE format.

Encoder paradox! You seem to have grasped the concept that for low bitrate encodes, every little counts (even going as far as using MKV v2 to save those valuable KB's), yet in the VFR thread you rubbished using VFR saying:

*bang!* ya got me twice! *dies and goes to encoder hell to work on 15mb RV clips*. I think my attitude there comes down to not knowing how to use dedup() very well at the time. I didn't use either on this clip actually.
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.

[Mentar]

Originally Posted by Zero1

Unless something has changed significantly; the AQ patch was added by Haali as an easy workaround for the problem of blue areas like skies not looking at their best. It's a simple patch that bombards blue areas with bitrate/lower quants at the expense of the rest of the image. Now obviously if you are encoding at 350MB/Q16 or whatever, you can't lose since the quality of the surrounding areas will not be reduced enough to affect the quality noticably (say a worst case scenario would cause the quantizer of some blocks to fall to 18/19, it's still very good quality).

The relevant part is not the "quality reduction" elsewhere, but rather the fact that AQ is the only way to have x264 properly render several trouble spot scenes. Blue sky is only a little part of it, much more important are dark spots with detailed structures, especially those with bright hi-contrast spots (like stars in a night sky or in space). Without AQ, you either need to ramp the bitrate to ridiculous levels or live with the ugly hi-quant blurryblocks which it produces otherwise. And say goodbye to any fine dithering of gradients which may still be in the source.

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.

I respect your opinion, but I emphatically disagree. Without AQ, the skewed bit allocation bias of x264 leads to terrible results for anime sources not only in skies, but in most non-flat dark spots aswell - results which according to my experiences at least cannot be properly mended if you insist on a near-1:1 representation. And taking into account that almost all anime has spots like these, I can't stress my recommendation too much to activate AQ for all _high-quality_ anime encodes.

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.

[slayer]

Originally Posted by Eeknay

Unlimited Longpost Works / Bankai!11 / etc etc.

lol excellent post..

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)

[Quarkboy]

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.

[Mentar]

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.

[Quarkboy]

Originally Posted by Mentar

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.

Then we agree! Let us rejoice in the uninamitude!

[Farix]

[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.

Originally Posted by Zero1

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).

So why can't we have an SD format encoded in AVC along with the XviD as well? Why must the AVC encoding be in HD format only? The reason I ask is because I'm one of the 2/3 of Americans who is still stuck with something that is less then broadband (only 1/3 of all household in the US have broadband according to the Broadband Reality Check II), so the size of the file matters greatly.

[ender]

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.

[Schneizel]

How the hell are they to know one has been reduced to SD format while the other is in the HD format.

...the file name?