View Single Post
Old 2006-09-29, 13:09   Link #467
Two bit encoder
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 32
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 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

Slotsmarken 10
2970 Hørsholm
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: (Info on the Sigma chipset) (Short video at IFA 2006, God the cameraman is irritating) (Couple of photos and general information) (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 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.
Originally Posted by mog08
I know we shouldn't be looking at CDs nowadays
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 is offline   Reply With Quote