2006-02-05, 10:56 | Link #261 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
As to your second point, I really don't know of any comparisons between h.264 no cabac no deblocking at lowish bitrates and xvid... The quality might not be too different, depending on the source.
__________________
|
|
2006-02-05, 17:52 | Link #262 | |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Quote:
__________________
|
|
2006-04-01, 14:17 | Link #263 | ||||||||||||||||||||||||||||||||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Unfortunately I missed replying to this thread before it got locked, and since I intend to post here anyway, I might as well catch up. I think it is still somewhat relevant.
Quote:
Quote:
Quote:
As for minimal hardware, this is also hard to specify, since H.264 encodes can vary in complexity in more ways than one (for example number of reference frames, number of B-frames, bitrate, entropy coding method). I won't commit myself, but I will say that my old Duron 750MHz (overclocked to 900MHz ;)) is able to play something like 640x480 H.264 with 5 reference frames (possibly more, haven't tested). An easier way to gauge is that using CoreAVC as the decoder, decoding H.264 requires approximately the same CPU power as decoding an ASP encode with XviD itself (as we found out in this thread earlier (or was it the old one?), and reminded by RaistlinMajere's signature). Quote:
As for your obsession for film grain (which is only a decoder effect, which isn't obligated to be there), H.264 apparently has a feature called FGT (Film Grain Technology, how original(!)). In laymens terms, it sounds as though it does a similar job with video, as HE-AAC does with audio. It cuts the high frequencies (high pitch sound in music, sharp edges/fine lines in video), and reconstructs them on playback. Whilst I'm not a big fan of HE-AAC (it's too destructive to be used for HQ audio IMO, but for low bitrates it's awesome), the actual reconstruction is pretty good, although I did find the midrange was somewhat lacking. Maybe that is a problem of the particular encoder I used. Anyway, check it out here: http://www.lge.com/products/supermul...iew.jsp?id=102 Quote:
By the way, I think that what you say isn't really a view, it's just huge bias. Quote:
I really wish to see XviD and x264 co-exist for a long time, rather than a huge switch to x264 and seeing XviD being forgotten. Remember that with the efficiency that H.264 has, it has higher decoding requirements. This is not suitable for portable devices like mobile phones. The PSP and/or iPod would benefit also, lower CPU usage means longer battery life. There is still a market for XviD (well, MPEG-4 ASP in general). Quote:
In fact, I dug through the archive and found the image: http://img81.imageshack.us/my.php?image=untitled2gr.jpg Quote:
Quote:
What I didn't agree with was the comment that x264 disappoints. For the first time in ages, I have been more than pleased with the encodes I can turn out, or rather the improvement over a same sized encode using XviD, or achieving the same or better quality at a lower size. I think you will find it's the encoders using x264 which is disappointing you. I guess you meant that, obviously, but the first line wasn't very clear. Quote:
H.264 is the name of a video coding standard, it is also called AVC (Advanced Video Coding) because it was a joint standard between MPEG and ITU. ITU call it H.264 (which is consistent with the naming of convention of previous standards like H.261, H.262, H.263), and MPEG call it AVC (Advanced Video Coding), which I believe is a clever gimmick seeing as their audio standard is called AAC (Advanced Audio Coding). The leading open source encoder is called x264 (see www.x264.nl for information). MPEG-4 Visual is the name of an older, well known video coding standard. It may also be referred to as MPEG-4 SP (Simple Profile) or MPEG-4 ASP (Advanced Simple Profile), since the main use of MPEG-4 Visual is for natural rectangular video, despite it having such tools for animation, object based coding etc. The MPEG-4 Visual has a wider scope in general, but H.264 only concentrates on natural video coding, and is much more complex and detailed than the video coding in MPEG-4 Visual. The leading open source encoder is called XviD, there is also a popular commercial alternative called DivX (names I know you will be familiar with), but why pay more for less? (when you can get higher quality, and for free) ;) Both DivX and XviD support MPEG-4 ASP (and SP also since ASP contains all of SP's features). So there you go; H.264 is a video coding standard, and an opensource encoder for this is called x264. MPEG-4 Visual (or MPEG-4 SP or MPEG-4 ASP) is a video coding standard, and an opensource encoder for this called XviD. Quote:
Quote:
How about if people start labelling their MP3's or the audio in their fansubs as LAME or Fraunhofer, or Nero, iTunes, Winamp, 3GP reference or FAAC for AAC? That would cause a bunch of confusion, since Mainconcept and Ateme produce other encoders also (MPEG-2 and MPEG-4 Visual). The fact is that while the encoders might vary in quality and features, they all output the same compliant streams that are playable through capable, compliant decoders, be it hardware or software. Then you get hardware. Since MPEG-4 ASP has effectively been partitioned as DivX and XviD, almost implying that they are different codecs, or somehow incompatible, you get "DivX" players, not MPEG-4 ASP players, but "DivX" players. You might say, "hang on, what about the incompatibilities I've seen", well that's a combination of people using AVI and VfW, and DivX disregarding the specs somewhat, and creating their own unofficial profiles. One of these was due to DivX's half assed GMC decoding implementation which only used to support 1 warp point, if you know XviD, you may know it uses 3. I believe (though I might be wrong) that a compliant decoder should support all the features of a selected profile, that would mean that the DivX decoders and players would be able to decode up to 6 warp point GMC (the maximum available). In other words, if a decoder claims to be an ASP decoder, it should support ALL of the features of ASP fully, and not partially implemented. Again, this goes back to DivX's name and disregard for the specs. Players that are not obligated to decode XviD encodes, because they are made to DivX Networks specifications. That means they are only guaranteed to decode DivX encodes (which means that there is only partial implementation of ASP decoding features). If it was a MPEG-4 ASP player, it would have to play any compliant MPEG-4 ASP stream, meaning that there should be no issue of compatibility between DivX and XviD encodes, barring the fact that they use hacks for VfW compatibility. That would mean (if DivX, XviD and libavcodec decoders follow the spec) that you could use any ASP feature you wanted without worry, be it GMC, QPEL or B-frames. It's an excuse for opensource, since they are only people doing it in their free time, but a company should do things properly, especially when they expect people to pay for their products. In my opinion, since DivX3.11a, the knock on effect of MPEG-4 in AVI has been damaging. Given that DivX 3.11a was a hack, it didn't do or require anything particularly undesirable specs (AVI/VfW) wise (as opposed to ASP which uses B-frames and requiring hacks). Maybe SBC's/Nandub's Low/Fast motion DLL switching was a bit naughty, I don't know, it was before my time :p. Why do I think DivX3.11a had a damaging knock on effect? Well basically (I guess) people was labelling the encodes as DivX, or DivX SBC to differentiate from MSMPEG4 (which I believe is a non standard simple profile implementation). Then comes natural progression, DivX (several versions later) eventually moved to ASP (which means B-frames, yay!). So as not to upset their userbase, they thought it wise to stick with AVI and just develop a hack called packed bitstream, which basically packs P and B frames together so two frames get forced through and read at once, since VfW has a one frame in, one frame out limitation (you need multiple frames to decode B-frames). Even later on down the line, we see the .divx format, which is nothing more than AVI with even more hacks. These hacks are even more evil though in my opinion. Yes, I'm talking about dual audio and menus in AVI. Yes, about dual audio, it is possible with AVI, but the default splitter supplied with Windows does not support it AFAIK (which accounts for like 99% of people using Windows). I think you will probably just get 2 audio streams playing at once. I don't know, and don't care to find out if Haali's splitter has the capability; I'm content with MKV and MP4. IF YOU WANT DUAL AUDIO AND/OR MENUS, CONTRIBUTE TO MP4 AND/OR MKV RATHER THAN WASTING MANPOWER HACKING OLD FORMATS, AND HINDERING THE DEVELOPMENT OF NEWER ONES. But no, they are content to stick with packed bitstreams and/or frame lag, and CBR audio (or VBR if you don't mind a workaround). It's not so much the "hacking" that bothers me, it's that it's counter productive. There are capable, well implemented AND opensource projects out there, that would be grateful for some help. Had people have done things "right" all those years ago, we would be seeing DivX and XviD encodes, no, MPEG-4 ASP encodes in MP4 (no, this isn't an MP4 hoaring, it's just the simple fact that MP4 existed before MKV and would have been used instead of AVI), and the general support (although very, very good even right now) would be much higher. The fact that it's an ISO standard means companies are happy to implement it. I mean just look at the amount of mobile phones that support .mp4, you also have the iPod, and the PSP (which requires some custom atom I believe). This is why I believe it's important to use H.264 as a fresh start. We are already doing the right thing by creating native streams (read: non hacked for VfW), and for the most part people refer to it as H.264. Also some people are using the native container (MP4), and others with requirements that MP4 does not aim to fulfil (due to the intention of interoperability), such as AC3, or the opensource softsub formats, use MKV (one thing I don't get is when people put H.264 + AAC in MKV, and don't make use of a single MKV feature, not softsubs, not even chapters). Sometimes you get AVC thrown in, but maybe that's just a dual standard we will end up living with, think anime; do you call a short series an OAV (original animated video) or an OVA (original video animation)? I'm not a complete specs Nazi, I just dislike the actions of idiot people that makes stuff incompatible. Sidenote: For those of you that dislike the idea of being "confined" to profiles and levels, you will be happy to know that you can encode up to 4096x2304@26.7 FPS and still fall within a specified level (that also translates to 1920x1088@120.5 FPS). So encode freely, and still be "compliant" :D Quote:
Also, now question your target audience. It will generally be people with computers (OMFG WHAT!?) and computer users usually have monitors in the region of 15"-21"; let's say 17" as an average. When I had a 19" monitor, I was still using 1024x768 (and enjoying how everything was OMG HUEG, going from a 14" monitor). Now I am using this 21" flat CRT (same visible area as a 22" CRT supposedly) I have jacked it up a little to 1280x960; sometimes I might crank it up to 1600x1200 or 2048x1536 when video editing with D1 material, but that's rare. What I am saying, is given the average screen sizes and resolutions (remember that although you might be able to use the higher resolutions, you might not be able to do so at a comfortable refresh rate), I'm of the opinion that HD as far as fansubs go (more so current CG series) is exuberant. It's kind of like 5.1 surround a few years back, it's a nice feature that a minority benefited from. Well 5.1 is quite widespread now, but I don't see many people benefiting from HD, unless they have 40"+ monitors. I think that the PAL sizes are good enough balance between a higher resolution and filesize/CPU requirements; take 1024x576 or 768x576 for example (assuming you had a "real" HD source and scaled it down to this) Quote:
A YV12 frame is exactly half the size of a RGB frame. This is because RGB stores 3 values per pixel (one value each for R, G and B), 640*480*3=921600 bytes. YV12 on the other hand, stores the image as 3 planes; you have luma (brightness) and chroma (blue and red). The luma is stored at full resolution (640x480) and the chroma is subsampled, in the case of YV12 this is 1 chroma sample per 4 luma samples; effectively quarter of the resolution. The red and blue chroma planes are stored at 320x240 each. Why is green not stored? Well that's because it can be calculated from the blue and red values :). Pretty clever eh? So how does this translate to half the filesize? Well the luma plane stores 1 value per pixel, the chroma planes also store 1 value per pixel, but remember they are 1/4 of the resolution (320x240). Now we have: Luma (Y)=640*480*1=307200 bytes, Chroma Blue (Cb)=320*240=76800 bytes, Chroma Red (Cr)=320*240=76800 bytes, therefore 307200 + 76800 + 76800 = 460800 bytes (RGB is 921600 bytes). Quote:
Quote:
Quote:
Quote:
One thing I will throw in, is that H.264 Baseline should be patent free (that was the design criteria), whether or not it still is I don't know; but baseline is horribly simple. MPEG has had a say in a lot of the coding tools, or rather standards we have used when you think about it. Quote:
HD-DVD on the other hand, is cheap, and can be produced with some minor adjustments to the production line. You also have the name; everyone is familiar with DVD, even my 80 year old grandparents. Then you have the buzzwords, HD, HDTV. Well Joe Average only needs to put 2 + 2 together to get 4 and realise that HD-DVD is a high definition DVD (or as the average consumer might see it, "better quality"). Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
__________________
|
||||||||||||||||||||||||||||||||
2006-04-01, 14:56 | Link #264 | |||
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Gawd, Zero1, do you HAVE to write a minor novel-sized post when you revive this thread? :P
Another problem with MPEG4 ASP incompabilities is the iDCT - I point interested parties to this page, which gives a pretty good summary. Quote:
Quote:
Quote:
Anyway... it actually seems to depend more on the encoder than on the codec. A good encoder using XviD can beat a mediocre one using x264, even if both are using the same raw. On the other hand, there can be a considerably bigger difference between a good encoder using x264 and a mediocre one using XviD, than if both were using XviD.
__________________
|
|||
2006-04-03, 02:14 | Link #266 |
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
The common fansub viewer doesn't have to *understand* h264 (also you realize when you say MPEG4 that doesn't really mean anything, there are many different parts and profiles), they just have to the means to click and play it. If they learn anything (or form an opinion) about it, that's a bonus.
Also, what's wrong with Nanami-chan? |
2006-04-03, 06:14 | Link #268 | ||
Two bit encoder
Fansubber
Join Date: Jan 2006
Location: Chesterfield, UK
Age: 39
|
Quote:
Quote:
Well as for editing; I quite agree that using XviD VfW and the likes for workraws is much easier than dealing with H.264, but as a final output format, I don't see what is wrong with H.264, or where editability comes into it. Fansubs are for watching, not NLE :/ Besides, if by editing you mean extracting a chunk to send to a friend, both MKVtoolnix and MP4box have sufficient abilities to do such. The only thing lacking from these is a preview window (well you can use vdub to get your times). You know as well as I do that editability and ASP isn't terribly flexible unless you are cutting on Intra frames (which IMO shoots down the arguement of editability, if you want editability use an Intra only codec). Maybe I'm missing something to this editability arguement that sometimes crops up, please elaborate
__________________
|
||
2006-04-03, 09:50 | Link #269 |
Member
Join Date: Dec 2005
|
Has anyone actually tried to encode a true HD broadcast using h.264 into a container that is the same size as a standard broadcast transmission? And what will be the ramifications if we use h.264 broadcasts that have DRM protection as part of its encoding?
|
2006-04-03, 10:18 | Link #270 | ||
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
Quote:
Quote:
|
||
2006-04-03, 10:46 | Link #271 | |
Member
Join Date: Dec 2005
|
Quote:
Yeh, that probably was a confusing question. I’ll try to explain it a little better. HD broadcasts will have up to 4 times as much information to transmit as compared to standard broadcasts. H264 gives them this ability while at the same time allowing them to use their current methods of transmission. In order for us to experience this same benefit we should be able to compress an HD broadcast to one quarter the size using H264 as compared to lets say Xvid. I was just wondering if anyone had actually tried this and was able to get it to work without the use of an H264 hardware based decoder. |
|
2006-04-03, 10:55 | Link #272 | |
Member
Join Date: Jun 2003
Location: somewhere far beyond
|
Quote:
CU, lamer_de
__________________
|
|
2006-04-03, 10:57 | Link #273 |
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
So you're asking has anyone ever re-encoded a HD transport stream to a much smaller file using h264, and if they have, have they managed to play it back without their computer exploding?
EDIT; heh Lamer kinda answered already, but yeah, there are rips out there at 700MB HRHD (960x540) xvid vs the 4GB original MPEG2 TS (file sizes varying on network/res/bitrate etc). No one really uses h264 that much (at least not for "scene"/wide distribution) but I do know a few people who re-encode their episodes to 700MB 720p h264. I personally have encoded a 1080i movie to 720p with a bitrate of around 4Mbit/s and it still looked great. If you keep it at 1080 then I expect 6-8Mbit/s would look good, yeah. |
2006-04-03, 12:10 | Link #274 | ||
Panda Herder
Join Date: Dec 2005
Location: A bombed out building in Beruit.
|
Quote:
Looking at this: http://forum.doom9.org/showthread.ph...t=speed+v+psnr It would seem x264 can still beat Xvid in both speed and quality. I don't know how much faith you put into PSNR and SSIM but it seems like something worth looking into. Though I can't say I've done any tests in this regard. Quote:
|
||
2006-04-03, 15:01 | Link #275 |
Excessively jovial fellow
Join Date: Dec 2005
Location: ISDB-T
Age: 37
|
Speaking of that, CoreAVC finally got released today, after several delays. The "enterprise" edition still isn't out, the website has lots of TM's but little else, the Pro version says "GPU support to be added at a later date" and the features of each version (the latest seems to be 0.0.0.9 alpha) are "subject to change". The Pro version (the one worth investing in, the standard variant is pointless) costs $19.95, and that is supposedly a special 30% off offer.
Meanwhile, libavcodec has gotten a few optimizations to its h264 decoding lately...
__________________
|
2006-04-03, 16:02 | Link #277 |
Member
Join Date: Dec 2005
|
Correct me if I’m wrong but doesn’t a resolution of 1080 take 2 & a half times more processing power than a resolution of 720 using H.264?
Fuji even states that H.264 is more complex compared to former compression methods, and is known for requiring processing power that is approximately 10 times that which is required for MPEG-2. Given this, will software based decoders actually be able to handle H.264 at HD resolutions of 1080 without bogging down our systems or just flat out not working? |
2006-04-03, 16:10 | Link #278 |
Gendo died for your sins.
Fansubber
Join Date: Dec 2005
|
You need a monster of a CPU to do 1080 h264. It would be extremely demanding even with CoreAVC (I did a test with some HD material... slideshow heaven). So yeah, your average machine isn't going to be able to handle it.
|
2006-04-03, 16:13 | Link #279 | |
Translator, Producer
Join Date: Nov 2003
Location: Tokyo, Japan
Age: 44
|
Quote:
If you remember, in the early days of mpeg2 we had the same issues, and hardware mpeg2 acceleration is now pretty standard, even though it's unneccesary for most systems. I think the same thing will happen with h264.
__________________
|
|
2006-04-03, 16:21 | Link #280 |
Member
Join Date: Dec 2005
|
Am I ok with this setup or will I have to upgrade?
Super Alien 12bay tower case w/6 fans Antec 550w Truecontrol power supply 3ghz P4 HT (Intel) Abit IC7 800MHZ FSB Motherboard 1GB DDR Ram PC3200 ATI Radion 9800 Pro 256MB 19” Samsung 995DF Monitor 1-WD 120GB HD (Main) 1-WD 250GB Internal HD 4-Maxtor 250GB Internal HD’s 2-Maxtor 300GB External HD’s 1-Maxtor 500GB External HD 1-TDK 840G Multiformat DVD recorder 1-TDK 440N Multiformat DVD recorder |
|
|