x264 and Intel's Media Engine / Sandy Bridge [Archive] - Page 2

LoRd_MuldeR

26th December 2010, 22:15

Commercial usage is perfectly fine for GPL'd software. The license clearly says that you are allowed to use the software for any purpose, explicitly including commercial purposes.

Moreover commercial development/distribution and OpenSource are not necessarily contradictory. Just think about commercial Linux distributions, like RHEL.

Last but not least, the authors of x264 could decide to continue the development of their software under some CloseSource license at any time, because they own the copyright.

However they certainly do not have to do this in order to be able to license their software commercially. And there's absoloutely no indication of such a plan at this time.

(I think the "commercial" license of x264 is more related to patent issues and/or support contracts. Something that is important for companies who use x264 in their products)

J_Darnley

26th December 2010, 22:46

The commercial license for x264 just frees companies from releasing all code they link with x264 as GPL. Each company that wishes to do this must obtain a license. It explicitly does not cover the AVC patent license. All useful code changes will be committed as GPL into x264 therefore letting everyone use them.

tl;dr LURK MOAR

deadrats

26th December 2010, 22:59

Last but not least, the authors of x264 could decide to continue the development of their software under some CloseSource license at any time, because they own the copyright.

see i'm not entirely sure that they do. as i understand it, x264 was originally created by someone else and then the two lead developers took ever and continued development. it's also my understanding that x264 was originally released under the gpl and the terms of the gpl dictate that any derivative work also be gpl'd.

lastly, my view of gpl'd software has always been that once it's gpl'd it's the same as being put into the public domain, copyright laws do not allow one to take something out of the public domain, not even whoever put it there in the first place.

http://www.gnu.org/licenses/gpl.html

i interpret the gpl to mean that you are not permitted to take a gpl'd product and release it under an alternate licensing scheme, not even if you're the person who gpl'd it in the first place.

i'm interested in hearing DS' take on this...

kieranrk

26th December 2010, 23:04

Copyright owners can license code however they like. All the copyright holders were contacted and agreed to the commercial licence.

LoRd_MuldeR

26th December 2010, 23:54

see i'm not entirely sure that they do. as i understand it, x264 was originally created by someone else and then the two lead developers took ever and continued development. it's also my understanding that x264 was originally released under the gpl and the terms of the gpl dictate that any derivative work also be gpl'd.

lastly, my view of gpl'd software has always been that once it's gpl'd it's the same as being put into the public domain, copyright laws do not allow one to take something out of the public domain, not even whoever put it there in the first place.

http://www.gnu.org/licenses/gpl.html

i interpret the gpl to mean that you are not permitted to take a gpl'd product and release it under an alternate licensing scheme, not even if you're the person who gpl'd it in the first place.

i'm interested in hearing DS' take on this...

If all copyright owners, i.e. all people who contributed code (that is still used), agree, then the code can be released under a different license, of course. This still applies, even if the software was released under the GPL before. So the authors could decide to move to a CloseSource license, if they wanted to. Still in that case all the code that had previously been released under GPL would remain under the GPL. So even if the "main" development would continue under a ClosedSource license, anybody could simply take the last GPL'd version of the software and continue using it as-is. You would even be free to start your own development (fork) from that version - under the restrictions of the GPL. And to make this clear again: Offering a software under a commercial license doesn't require or imply that the software is going to be CloseSource. And currently there is absolutely no indication that the x264 developers have any plans for moving to a CloseSource license. So what is the point of all this off-topic discussion please ???

b66pak

27th December 2010, 02:48

when money was invented the platonic love was gone...so anything is possible...
_

Dark Shikari

27th December 2010, 03:03

you know, it seems i owe you an apology, all this time i was reading various posts you made as well as some of the things you had written in your "diary of an x264 developer" and a lot of what you said struck me as absurd. now it all makes sense.All is forgiven :)

on the topic of gpu accelerated encoding, is one of the reasons you have claimed that for any given number of threads a cpu will be faster because with the cpu you can use 8 bit and 16 bit int's and with cuda (and it's brethren) you have to use 32 bit int's minimum?This is one of the reasons that GPUs tend to have less advantage than one would otherwise expect. The real problems are more obnoxious than that; this is just a reason why the raw performance gain is lower.

Note some of this has changed recently; ATI added an instruction to do a SAD of 4 8-bit integers, for example.

is it also safe to assume that bulldozer, with it's 2 128 bit alu's per core, will be THE cpu to get for x264 encoding?"2 128-bit ALUs per core" doesn't seem to be a very big selling point to me, considering that the i7 had 3!

2 more quick questions: you recently signed a licensing agreement with pegasys and reading some of the press releases it seems that you created a parallel "commercial friendly" license under which you licenses x264 llc (that is the name of the commercial variant, is it not?). does this not violate the spirit, if not the letter, of the gpl?

i know many companies consider the gpl an "infectious" license, but doesn't the gpl explicitly forbid taking gpl'd code and making closed source? does it not also require that any derivative work also be gpl'd?

by creating a parallel licensing scheme haven't you a) created a derivative that's not gpl'd, b) opened the door for companies to create derivatives that are not gpl'd, c) opened the door for companies to close source the x264 code they license from you, d) and perhaps most importantly open the door for a company to make some simple changes and try and claim copyright to that, a claim that they could use to prevent you from making similar changes to the gpl'd version of x264?

1. The GPL is "infectious" in that if you link GPL software to any software, that software must become GPL.

2. Any copyright holder is free to release their work under any license. Releasing something as GPL does not mean you can't release it as something else too. Many popular software programs are available under multiple licenses: a popular example is Firefox, which I recall is triple-licensed. A popular example of commercially-licensed GPL software is MySQL.

3. Companies are required under our license to (if we ask) give us all of their changes to x264 back to us. Furthermore, they sign over their rights to those changes -- we get co-ownership of them, allowing us to do whatever we want with them -- including release them as GPL along with the rest of x264. This means there won't be proprietary forks. I would not have gotten agreement from the other developers without this promise -- nor would I have supported the plan myself. This is why I consider it in the spirit of the GPL: it still ensures that all improvements make it back to the community, which is what the GPL is really all about.

Note there may be patches we don't release, but only because we don't consider them useful. If someone asks, we'll probably still be happy to go get it anyways. An example is a patch that adds UTF-16 path support for statsfiles, something I consider utterly useless.

lastly, i'm wondering what ide do you use during the development of x264, i'm assuming you use gcc to build the executables but do you use a front end like code blocks or dev-c++? also what, if any optimization options do you use? do you target any specific architecture, simply use -O3, a combination?

thanks.Notepad++ is my "IDE". Optimization options are just the default x264 builds with.

deadrats

27th December 2010, 04:48

"2 128-bit ALUs per core" doesn't seem to be a very big selling point to me, considering that the i7 had 3!

the core i7 has three 128 bit alu's?!? are you sure? i know the P4 had 3 alu's, 2 were double pumped, 1 ran at cpu clock speed and the single pumped one was the one that handled the boolean decisions, such as if/else, case/switch and the like, the double pumped alu's were strictly for math purposes.

i know that starting with the core 2 intel went to a single cycle sse engine and a 4 wide architecture but i thought the biggest difference that the core i7 brought, other than the cache improvements, was that it extended the core 2's ability to fuse 32 bit instructions and treat them as one to 64 bit instructions, i never heard anything about it having 3 128 bit alu's.

to hear amd say it bulldozer's 128 bit alu's are something never before seen in a desktop cpu.

Notepad++ is my "IDE". Optimization options are just the default x264 builds with.

notepad++, huh? that's pretty hard core, kind of like my old linux/unix instructors used make us write our code in vi and point gcc to the saved .c file, lol.

this is going to sound like an amateur question but it's been a while since i built a project like x264 without using make on a linux system, how would i go about building x264 on a vista system just with gcc? i want to run a couple of experiments with various optimization options, just to see what kind of speed up, if any, is possible.

i'm also thinking of using c to pascal, c to fortran and c to basic translators to port the code over to the respective languages, so that i may see a) what it would look like in said languages and b) what the relative performance of a good pascal, fortran and basic compiler would be in relation to gcc.

Dark Shikari

27th December 2010, 05:16

the core i7 has three 128 bit alu's?!? are you sure? i know the P4 had 3 alu's, 2 were double pumped, 1 ran at cpu clock speed and the single pumped one was the one that handled the boolean decisions, such as if/else, case/switch and the like, the double pumped alu's were strictly for math purposes.

i know that starting with the core 2 intel went to a single cycle sse engine and a 4 wide architecture but i thought the biggest difference that the core i7 brought, other than the cache improvements, was that it extended the core 2's ability to fuse 32 bit instructions and treat them as one to 64 bit instructions, i never heard anything about it having 3 128 bit alu's.

to hear amd say it bulldozer's 128 bit alu's are something never before seen in a desktop cpu.

The Core 2 and Core i7 have three arithmetic units: execution units 0, 1, and 5. On the Core i7, 0 and 5 can do SIMD add/sub/shuffle and 1 can do SIMD multiplies. All three can do bitmath and all three can do most scalar operations. I omitted some things they can do (float, etc) that I don't care about for simplicity. Check Agner's site for more details.

this is going to sound like an amateur question but it's been a while since i built a project like x264 without using make on a linux system, how would i go about building x264 on a vista system just with gcc? i want to run a couple of experiments with various optimization options, just to see what kind of speed up, if any, is possible.Download Cygwin or MinGW, use make. You won't build x264 without a configure/make script combo.

imcold

27th December 2010, 13:00

i'm also thinking of using c to pascal, c to fortran and c to basic translators to port the code over to the respective languages, so that i may see a) what it would look like in said languages and b) what the relative performance of a good pascal, fortran and basic compiler would be in relation to gcc.

I doubt you'll go far just by translator, but if you want to see how an encoder in it would "look like" in pascal, there is an encoder written in it already: fevh264 (https://sourceforge.net/projects/fevh264/). Coding style is similar, but compared to x264 it's just a toy. As for relative performance, from my exp.: mpeg1-like decoder (with some assembly) translated from pascal to c was ~5-10% faster; gcc vs. Freepascal/fpc, 32bits. In case of x264, it would be worse (fpc can't inline assembly funcs etc.).

deadrats

27th December 2010, 18:13

fevh264 (https://sourceforge.net/projects/fevh264/). Coding style is similar, but compared to x264 it's just a toy. As for relative performance, from my exp.: mpeg1-like decoder (with some assembly) translated from pascal to c was ~5-10% faster; gcc vs. Freepascal/fpc, 32bits. In case of x264, it would be worse (fpc can't inline assembly funcs etc.).

cool, thanks for the link, i know it sounds silly but back when i was in high school we were taught basic, then fortran, then pascal and even in college the first few comp sci classes were in pascal, including the object oriented ones, then you were taught c. now you go straight to c++, it's probably better, but there were things i liked about fortran and pascal.

7oby

3rd January 2011, 10:05

AFAIK, the Sandy Bridge shipping in January will not have the transcoding engine. You're going to be waiting quite a while.
I justed looked over to Anands latest review regarding the transcoding engine. Quite interesting (also in comparision to CUDA):
http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-2100-tested/9

And it seems to be shipping. Can you elaborate on the status or future of the work with Francois Piednoel (intel)? I read the interesting irc-log.

Dark Shikari

3rd January 2011, 16:04

I justed looked over to Anands latest review regarding the transcoding engine. Quite interesting (also in comparision to CUDA):
http://www.anandtech.com/show/4083/the-sandy-bridge-review-intel-core-i5-2600k-i5-2500k-and-core-i3-2100-tested/9

And it seems to be shipping. Can you elaborate on the status or future of the work with Francois Piednoel (intel)? I read the interesting irc-log.There is no status. Nothing has happened. I haven't talked to him in weeks.

He was the one who told me that the Media Engine wasn't going to be in the first SB release. Apparently he was wrong about that, too.

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

ajp_anton

3rd January 2011, 18:05

"2 128-bit ALUs per core" doesn't seem to be a very big selling point to me, considering that the i7 had 3!
Well Bulldozer cores aren't meant to be comparable to the cores in other CPUs. The "cores" are much smaller, and a similarly sized and priced CPU would have twice the number of cores in BD.
Also I don't know if this helps anything here, but I read that BD is designed to be a high frequency (netburst) type CPU.

hajj_3

3rd January 2011, 18:47

would be nice if intel created parts of their next cpu that hardware accelerate x264 encoding, that would literally be a dream come true, i can't even imagine how quick it could be. Now that x264 has a commercial license available may intel might think about doing this.

LoRd_MuldeR

3rd January 2011, 20:15

hajj_3

3rd January 2011, 21:09

ivy bridge the 22nm version of sandy bridge is out in 2H 2010, lets hope they add support then. Maybe USB3, esata 6gbps, pci-e 3.0 and lightpeak might be in ivy bridge. Esata 6gbps hasn't been ratified yet btw, but is due to soon. I won't be upgrading until desktops with all these technologies are available at a low price.

kosmonaut

3rd January 2011, 21:26

There is no status. Nothing has happened. I haven't talked to him in weeks.

He was the one who told me that the Media Engine wasn't going to be in the first SB release. Apparently he was wrong about that, too.

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

And now with bonus DRM (http://www.engadget.com/2011/01/03/intel-to-launch-insider-movie-service-with-1080p-content-widi-2/)! :rolleyes:

Sharktooth

4th January 2011, 04:52

sarcasm (http://www.youtube.com/watch?v=BxroiTRg7Tg)...

aegisofrime

4th January 2011, 05:35

Maybe you guys can approach AMD this time. Enough hardware sites use x264 as part of their benchmark package to make cooperation with x264 an attractive marketing strategy. :)

Not forgetting all the people out there who use x264 too.

kieranrk

4th January 2011, 05:44

Maybe you guys can approach AMD this time. Enough hardware sites use x264 as part of their benchmark package to make cooperation with x264 an attractive marketing strategy. :)

I've been there...done that. Request went to the head of developer relations at AMD and was ignored.

aegisofrime

4th January 2011, 05:53

I've been there...done that. Request went to the head of developer relations at AMD and was ignored.

Gah >.<

Well, their own loss then. :/

wlee15

4th January 2011, 08:55

The Core 2 and Core i7 have three arithmetic units: execution units 0, 1, and 5. On the Core i7, 0 and 5 can do SIMD add/sub/shuffle and 1 can do SIMD multiplies. All three can do bitmath and all three can do most scalar operations. I omitted some things they can do (float, etc) that I don't care about for simplicity. Check Agner's site for more details.

Download Cygwin or MinGW, use make. You won't build x264 without a configure/make script combo.

I do believe that each Bulldozer floating point/vector cluster has 4 128-bit ALU. Interestingly enough 2 of those units are dedicated SIMD integer units while another is capable of executing IMAC instructions from AMD new XOP instruction set.

deadrats

9th January 2011, 17:49

I'm sick of dealing with incompetent companies like this. Now we have yet another fast-but-terrible hardware encoder -- for free on a popular CPU, nonetheless -- that helps nobody, instead of an accelerated x264.

2 things come to mind:

1) in what way is the fixed function hardware encoder/decoder "terrible"?

the screen shots in the anandtech review are practically indistinguishable from the software encoded screenshots.

2) how is it that x264 can't be modified to benefit from quick sync? i downloaded the intel media sdk and looked through the documentation and it seems intel has made it fairly easy (much easier than via cuda, that's for sure) to access various built in functions, including SAD (which i know you tried to get working via cuda as far back as 2007).

then there's this reality, and i hope this doesn't come off as me trolling or trying to start something:

let's assume that x264, in it's present form, at low bit rates offers much better image quality than the fixed function quick sync version, who cares? you have acknowledged in other posts that once the bit rate is raised the quality difference between encoders starts disappearing.

when you consider that a single frame of 1080p is composed of over 2 million pixels, at a frame rate of 30fps that's 60 million pixels, it's absurd to encode at bit rates of 10 mb/s, which works out to 6 pixels per bit, something many x264 users seem to be fond of doing. there's a reason that movie studios encode their blu-rays at 30+ mb/s.

as i said, just want to give you the perspective of an end user, i would much rather use the quick sync encoder, raise the bit rate and encode 1080p video at 15 mb/s at almost 100 fps than use x264, use half the bit rate and only encode at 15-20 fps (depending on source) using the ultra fast preset on my x4 620.

i know you're proud of your encoder and i know you have put a lot of work into getting it to the point it is now, but even a blind man can see that software based encoding is a dinosaur, only the most ardent masochist that has a fetish for bit rate starving encodes is going to choose x264 (or even the new xvid rc1 release, a much improved version) and sit through encode times anywhere between 4 and 10 times slower than quick sync.

most will probably realize that a 1.5tb hdd costs less than $100 and that blu-rays can hold 25-50 gigs of data and say "f" it, i'll just crank up the bit rate a bit and be done with my transcode in a fraction of the time.

i strongly suggest that if x264 can't be made to benefit from quick sync that perhaps you rethink your approach and maybe start a new h264 encoder from scratch, using the things you have learned coding x264 to create a quick sync accelerated high quality version of x264.

i know i'm probably going to get flamed for this but mark my words, software based encoders will soon be a thing of the past, intel and amd have cross licensing agreements, after a short amount of time each company can use the other's technology.

within a year amd cpu's will feature amd branded quick sync, by then most major video editing apps should support the technology (cyberlink, arcsoft, adobe, corel and movavi are already on board and there's no doubt pegasys will jump on the bandwagon as well).

stop being obstinate, stop with the "useless pile of" (insert adjective du jour), stop with the "it's useless for x264", stop with the attitude that "my encoder is the greatest and everything else is a pile of crap" and start finding a way to give the end users what they want, you're a professional programmer damn it, program!

deadrats

9th January 2011, 17:59

And now with bonus DRM (http://www.engadget.com/2011/01/03/intel-to-launch-insider-movie-service-with-1080p-content-widi-2/)! :rolleyes:

what "bonus" drm are you talking about?

the content you create using quick sync doesn't automatically have drm, but a content creator using a custom app can encode drm protected content using quick sync.

this is no different than any current app that targets the professional market, i can create a drm protected h264 video right now using microsoft's expression encoder pro (which by the way is a very high quality h264 encoder), you can create drm protected audio streams, vc-1 streams, there's nothing insidious about quick sync, intel is just making sure that a feature the professional market wants is present on their cpu.

if you don't like it, stick with x264, be happy with frame rates of 20 fps for high bit rate hi def content and stop spreading FUD.

ranpha

9th January 2011, 18:38

when you consider that a single frame of 1080p is composed of over 2 million pixels, at a frame rate of 30fps that's 60 million pixels, it's absurd to encode at bit rates of 10 mb/s, which works out to 6 pixels per bit, something many x264 users seem to be fond of doing. there's a reason that movie studios encode their blu-rays at 30+ mb/s.

Why encode at 30Mb+ when you can encode at 10Mb/s and still retain the same quality? Do you like your Blu-ray backups large?

kolak

9th January 2011, 18:44

Gah >.<

Well, their own loss then. :/

Do you think that it's so easy to go to eg. AMD with an offer :)
You can have the best product, but without knowing correct person you will achieve nothing :) There are so many very good solutions which died and so many crap one which got implemented- very common and normal.

Andrew

deadrats

9th January 2011, 20:43

Why encode at 30Mb+ when you can encode at 10Mb/s and still retain the same quality? Do you like your Blu-ray backups large?

this is an absurd question, if you could achieve the same quality at 10 mb/s using x264 as you can with something like cce-hd or blu-code at 30+ mb/s; do you really think that the professional movie studios would spend 40-70+ grand on a per seat license to acquire those encoders? don't you think they would try and save a butt load of dough and use the legally free open source alternative?

furthermore, a blu-ray disk holds up to 25-50 gigs of data and as i said a 1.5tb hdd costs under $100 (i currently have 3 of them), you feel like saving the space for a rainy day?

but perhaps the biggest reason for not bit rate starving an encode is the fact that the math says it's a stupid thing to do:

a 1920x1080p frame has 2073600 pixels, at 30 frames per second that works out to 62208000 pixels every second. at a bit rate of 10 million bits per second (10 mb/s) that's means every bit has to represent 6.2 pixels.

if i remember correctly, with uncompressed video, each pixel is 8 bits, that means that you are using less than 1/48th the bit rate as what the uncompressed source would be.

that's just flat out ridiculous and even more ridiculous is the thought that somehow any encoder at 10 mb/s is going to match the quality of another encoder at 30 mb/s.

download the demo for main concept's cuda powered encoder and run 2 test encodes, at sane bit rates, say 15 mb/s for 1080p, one with said gpu powered encoder and one with x264, i defy anyone to tell me which is which without looking at the water mark main concept places on the video in the demo version.

x264 quickly loses it's quality advantage once you let the bit rate fly.

poisondeathray

9th January 2011, 20:55

download the demo for main concept's cuda powered encoder and run 2 test encodes, at sane bit rates, say 15 mb/s for 1080p, one with said gpu powered encoder and one with x264, i defy anyone to tell me which is which without looking at the water mark main concept places on the video in the demo version.

x264 quickly loses it's quality advantage once you let the bit rate fly.

It also depends on the content.

You're probably testing on low quality stuff (or think youtube looks great.)

For example, go look at the park run sequence (or the original SGI film scan is available too), there is a night/day difference between encoders even at 30Mb/s (regular viewing, not even pixel peeping or frame by frame examination) , even with mainconcepts' full featured software SDK encoder (not the gimped versions or even the cuda version)

These GPU encoders have a place, but so far they are not suitable for any type of high quality encoding. They are passable for low quality devices and definitely encode faster on things like dual core laptops than software based x264

deadrats

9th January 2011, 22:07

@savage:

re #1: while the anandtech article didn't test with x264 they did provide uncompressed png's for comparison and quite frankly the quick sync encodes can hardly be called "horrible" (unless you have an anti-intel, pro "your own personal baby that you coded" agenda.

re #2: i don't care how much whiskey you drink, you will never see any test in which x264 encodes a 15 mb/s 1080p video at anything approaching 100fps. the commonly used x264 hd benchmark which takes a 720p mpeg-2 and transcodes it to a 4 mb/s 720p x264 only hits about 40fps, quick sync in a similar test hits 200fps.

re #3: there's nothing that says an app has to use said drm, it's just available so that people can create apps that allow content creators to protect their content. this is nothing new, drm has been around for years, m$ and apple both have offered drm in their encoding apps for years, intel has just decided to to the same with their offering. the video/audio streams don't automatically include drm just because they are encoded via quick sync.

re #4: the proof is in the pudding, try a test encode at blu-ray bit rates using x264 and mc's cuda powered encoder and then come talk to me.

re "flaming DS": not at all, i'm just tired of seeing one excuse after another from him, he rips on gpu powered accelerators, he rips on avx, now he rips on quick sync, well the facts don't support his contentions: gpu powered encoders exist and offer very good quality at realistic bit rates, main concept has 2 gpu powered encoders, a cuda based one and an open cl based one, there is an open cl based gpu encoder for os x, there is an ffmpeg based gpu powered dx9 based mpeg-2 encoder available as a plug in for adobe's products (as well as a vfw plug in), sony has an excellent (albiet slow) gpu powered encoder, all the major players have signed up for quick sync and a look through the docs show that the fixed function capabilities of quick sync are quite formidable, there are functions for sum of absolute differences, sum of square difference, sum of absolute hadamard transformed difference, functions for deinterlacing, resizing, denoising, detail enhancement, color conversion and enhancement, the list is endless, if you can think of it, there's a function for it.

i realize in this forum DS is unto God, that he can do no wrong, but you guys need to look at things objectively and see if the facts support the myth.

shon3i

9th January 2011, 22:26

i realize in this forum DS is unto God, that he can do no wrong, but you guys need to look at things objectively and see if the facts support the myth. No we just use our eyes, thats all.

Second, you comparing two encoders like ferrari and tractor, both can reach speeds of 200km/h, downhill....

weasel_

9th January 2011, 22:51

re #4: the proof is in the pudding, try a test encode at blu-ray bit rates using x264 and mc's cuda powered encoder and then come talk to me.

There is test x264 vs some cuda encoder i dont remember what
Use search ...
U will see how much x264 is better at same bitrate...
Half blind people will see that

There is no hardware encoder that is better in quality-wise then x264

i realize in this forum DS is unto God, that he can do no wrong, but you guys need to look at things objectively and see if the facts support the myth.
And what facts u gave ?

AT REALISTIC bitrate ? hahahaah

What is main point of encoder ?
Keep quality at smallest bitrate posible ...
So compare x264 to that encoders you named at low bitrate and u will see for yourself.
At big bitrate every encoder in world will be good. Shon3i gave good example for tractor and ferrari :)

deadrats

9th January 2011, 23:12

So compare x264 to that encoders you named at low bitrate and u will see for yourself.
At big bitrate every encoder in world will be good. Shon3i gave good example for tractor and ferrari :)

what is this bizarre fascination that people have with bit rate starving their encodes?

a dvd 9 can hold 8.5 gigs of data, blu-ray can hold up to 50 gigs and we have hard drives in the 3 terabyte range, why would you use ridiculously low bit rates for any encode?

it reminds me of that seinfeld episode where kramer is test driving the saab, the needle hits "e" and he and the salesman decide to see how far they can go before they run out of gas and the car stalls.

all i know is that i just priced out a new SB based build, i can get a good motherboard for $125, a 2500k for $180 and 4 gigs of ddr3 for about $100, as soon as i get my tax refund i'm switching to SB and i'll use the transcoding engine that allows me to encode 1080p at 100fps and you guys can stick with the software based encoder and keep telling yourselves that the quality is much better and it's just as fast as quick sync.

when you sober up, the rest of the world will be waiting for you...

weasel_

9th January 2011, 23:18

And what is point of encoder ?
Encoding at same bitrate as source ? :facepalm:

i'm switching to SB and i'll use the transcoding engine that allows me to encode 1080p at 100fps

Great, have fun....

and you guys can stick with the software based encoder and keep telling yourselves that the quality is much better and it's just as fast as quick sync.

:stupid:

LoRd_MuldeR

9th January 2011, 23:21

what is this bizarre fascination that people have with bit rate starving their encodes?

a dvd 9 can hold 8.5 gigs of data, blu-ray can hold up to 50 gigs and we have hard drives in the 3 terabyte range, why would you use ridiculously low bit rates for any encode?

Using bitrates that are too high is a common mistake done in encoder comparisons. As a matter of fact, you can always increase the bitrate until the differences between the competing encoders vanish. That's because at a certain bitrate even the worst encoder in the test will look "transparent" and then it is impossible for any of the other encoders to give better quality. Of course such test is absolutely meaningless! For this reason you must pick a bitrate where the differences between the different encoders are still clearly visible - at least if your goal is to learn something from your test. IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...

(Needless to mention that running the test at an absurdly low bitrate and then concluding that all encoders in the test look "horrible" would be just as meaningless)

deadrats

9th January 2011, 23:50

IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...

that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:

http://www.blu-ray.com/faq/

i do think that you touched on an important thought process, it does seem that x264 proponents are of the mind set that blu-ray bit rates are too high, they forget that uncompressed 8bit 1080p29.97 video uses 119 mega bytes per second, so even a bit rate of 30 mega bits per second is on the low side, x264 users seem convinced that they can drop that all the way to 10 mega bits per second (and lower) for 1080p29.97 video and somehow still maintain the same quality.

just because they can't see the differences using the consumer grade 20 inch monitors coupled to their gaming graphics cards does not mean that the quality is the same, just that they need to look at the math, get their cataracts operated on and lay off the wild turkey.

personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

it's silly, if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1.

mp3dom

9th January 2011, 23:53

Using bitrates that are too high is a common mistake done in encoder comparisons. You can always increase the bitrate until the differences between the competing encoders vanish. That's because at a certain bitrate even the worst encoder in the test will look "transparent" and then it is impossible for any of the other encoders to give even better quality. Of course such test is absolutely meaningless! For this reason you must pick a bitrate where the differences between the different encoders are still clearly visible - at least if you want to learn something from your test.
You're right... it's surely useless to compare a 1080p source at 100 Mbps range.

IMO the typical BluRay bitrates are too high for an encoder comparison. Remember: BluRay was designed with MPEG-2 in mind, so the available bitrates are actually higher than what a good H.264 encoder needs to retain "transparent" quality...
I disagree. Personally I think 40 Mbps can be enough only most of the times. In particular, for sensitive parts (gradients, fine details, subtle grain, fades, all of the above mixed with complex parts etc) if you see the source and then the compressed file (even during playback) you can easily spot the differences if you've a 'trained' eye (and sometimes even an 'eye' is enough :)). The "pro" here is that the final customer doesn't have the master as a reference to see if the problem is on the master or came up after compression.
Probably in this "field" all the encoders have rooms for improvements (I think but above all I wish).
Just as a note: this (http://forum.doom9.org/showthread.php?p=1458884#post1458884) 40 days old "quick" comparison was made with an average bitrate of 35Mbps (with max set to full 40 Mbps). Considering your post, this result would qualify x264 as 'bad' (which, I think first of all, is not true), but anyway clearly demonstrate that even 35Mbps average can be not enough (for both encoders).

personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

I completely agree with you, even if it's true that a lot of times even official BDs have an average bitrate of 15-20 Mbps which (to me) is again low.

deadrats

10th January 2011, 00:17

And what is point of encoder ?
Encoding at same bitrate as source ?

you are absolutely correct, i personally believe that there are only a few reasons to transcode something, like if the source is too dimly lit, the color saturation is off, the source is noisy and you are trying to fix said video or the aspect ratio is wrong and you can't fix it via manipulation of flags.

in these cases the output should equal the input, i.e. size and bit rate in = size and bit rate out.

in all other cases you are better off simply buying another hdd (at $90 for 1.5tb it's quite affordable).

shon3i

10th January 2011, 00:20

The whole point here is efficiency of some standard. I can't understand why then all of these standards and improvements if there is no real difference. H264 is made to be better than MPEG2. Otherwise why not keep Lossless.

Like for example one car spent 8 liters and another spent 15 liters, both driving at 160km/h. And someone then says that is impossible. And all cars need to spent 15 litres and higher to be faster.

that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:What LoRd_MuldeR is want to say is that huge bitrates is reserved in first place for MPEG2 encoders.

LoRd_MuldeR

10th January 2011, 00:29

that is not true, blu-ray was designed from the get go with all three major compression schemes in mind, avc, mpeg-2 and vc-1 as well as a boat load of audio compression schemes:

http://www.blu-ray.com/faq/

I know that in the final spec three formats are allowed (H.264, VC-1 and MPEG-2). Still MPEG-2 is by far the least efficient of those three supported video formats. And in the design of BluRay disc the bitrate (space) requirement was necessarily defined by the least efficient format that was going to be supported, i.e. by MPEG-2.

i do think that you touched on an important thought process, it does seem that x264 proponents are of the mind set that blu-ray bit rates are too high, they forget that uncompressed 8bit 1080p29.97 video uses 119 mega bytes per second, so even a bit rate of 30 mega bits per second is on the low side

So what is the point? Even old MPEG-2 can give decent quality at 20-40 MBit/s for HD content.

If state-of-the-art formats/encoders, such as H.264/x264, have proven that transparent quality can be preserved at even lower bitrates, then THAT is the reference other formats/encoders have to be compared to.

(To give yet another car analogy: If you can choose between a Trabi and a Ferrari, would you pick the Trabi, just because both of them are significant faster than an oxcart? ^^)

x264 users seem convinced that they can drop that all the way to 10 mega bits per second (and lower) for 1080p29.97 video and somehow still maintain the same quality.

Being convinced of something that is a matter of facts seems logically to me ;)

just because they can't see the differences using the consumer grade 20 inch monitors coupled to their gaming graphics cards does not mean that the quality is the same, just that they need to look at the math, get their cataracts operated on and lay off the wild turkey.

personally i think the "bit rate starve" mentality has it's origins in piracy and file sharing, people eager to conserve bandwidth so they try to transcode to as low a bit rate as possible so that downloads and uploads complete faster.

it's silly, if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1.

It seems all your argumentation goes like this: If you have enough bitrate available that you can waste for hiding the weaknesses of a "bad" (i.e. inefficient) encoder, then using the "bad" encoder is bearable, even though with a "good" (i.e. more efficient) encoder you could have retained the same quality at a much lower bitrate or a better quality at the same bitrate.

There's nothing surprising or interesting about that...

(And indeed using DVD-9 with H.264 and a good encoder would have been perfectly sufficient for distributing HD movies, but of course the industry prefers selling new hardware for new disc formats!)

AnonCrow

10th January 2011, 00:52

what is this bizarre fascination that people have with bit rate starving their encodes?Quite simply, because it can be done - or optimally, because it shouldn't be possible. Such as any meaningful application in 256 bytes, or a GUI, a webserver and a graphical webbrowser on a C64.
In the grand scheme of things: from a company perspective, sure, it's cheaper to pump more CPU power and bytes into something, rather than spend a few years optimizing the code.

if you could achieve the same quality level these companies would never have invested millions in hd-dvd and blu-ray technology, they would have stuck with dvd9 and extended the spec to include h264/vc-1
Then they wouldn't have been able to sell more hardware to ignorant consumers.

i personally believe that there are only a few reasons to transcode something, like if the source is too dimly lit, the color saturation is off, the source is noisy and you are trying to fix said video or the aspect ratio is wrong and you can't fix it via manipulation of flags.
All of those can already be changed at runtime in any decent player. If the source is grainy and you want encode a degrained version of it, surely the bit-rate would drop a lot if you were encoding at the same quality ?
What about downscaling the video for various different resolutions, or simply downscaling it from 1080i to 720p if the the source really doesn't have that much optical resolution to begin with ?
Also, you nicely ignored the fact that weasel was somewhat flabbergasted with your ideas. Though I'm sure you were a little too, when Windows 7 was released, and you noticed that it had the same or in same parts even lower system requitements than Windows Vista - ignoring the fact that if eg. MS spent the better part of a decade to optimize it (or really rebuild it from scratch), it'd run happily on a 486 /w 32 MB RAM.
Continuing on the car MPG examples: Any people/companies competing for maximum fuel efficiency must be crazy then, even if they manage an order of magnitude more efficient use of whatever fuel used than a typical car (with a real-looking car).

Disclaimer: no, I'm not a Mac user, I'm an Amiga user

deadrats

10th January 2011, 00:55

It seems all your argumentation goes like this: If you have enough bitrate available that you can waste for hiding the weaknesses of a "bad" (i.e. inefficient) encoder, then using the "bad" encoder is bearable, even though with a "good" (i.e. more efficient) encoder you could have retained the same quality at a much lower bitrate or a better quality at the same bitrate.

you almost got it, you just need to expand on it a bit: if you can eliminate any quality difference between encoders with enough bit rate AND storage is not a consideration thanks to huge hard drives at very reasonable prices AND a hardware based encoder at 4 times the bit rate is 5-10 times as fast as the little darling of the open source community, then why suffer using the much slower encoder?

x264 is the fastest software based encoder when using the "ultra fast" preset, i'll grant you that. be that as it may, using a x4 620, transcoding a 1080p blu-ray rip to a 15 mb/s h264 with ac3 audio mkv i'm lucky if i see 15 fps, tops.

an SB cpu, using the quick sync engine, did a similar test on anandtech at 100 fps and that's without stressing any of the cpu cores.

according to that very same review, a 6 core 12 thread core i7 980x completes the encoding pass of the x264 hd benchmark at 49 fps. downloading the benchmark and examining the test file as well as the benchmark script shows that the source is a 720p mpeg-2 and the encode target is a 4 mb/s 720p h264, no audio with the priority set to "real time".

what does one need to be smoking to conclude that using x264 to encode a 4 mb/s 720 h264 at 49fps (if you'r lucky), with your cpu maxed out and priority set to real time is preferable to using the quick sync engine to encode a 15 mb/s 1080p, with audio no less, at 100 fps?

furthermore, what kind of reality distortion field is needed to believe that an x264 encode, done at 4 mb/s and 720p will somehow be of higher quality than an encode done at 15 mb/s and 1080p?

are all x264 users also mac users?

kolak

10th January 2011, 01:00

Pointless discussion :)

One group talks about encodes which are transparent to the source at very high level, other about something which looks good and is as small as possible (mainly for ripping and sharing over net)

BD was created to give best possible quality for mass consumer (DVD started being not good enough on massive new TVs) and its 40Mbits is good enough to deliver it. It's not overdone, even for x264.

Saying that x264 can achieve the same at 10Mbit as BD at 30Mbit is not true at all.
If x264 can achieve the same transparency at 10Mbit than great- we can put whole series on 1 BD. It also means that other encoders can be improved.

x264 can achieve much more than other encoders at 10Mbit, but it's no near close to transparency, which is achieved on BD discs.
Question is if average consumer does need such a good quality like BD? He could probably live with much lower, but TVs getting bigger and bigger and heavily compressed footage will start being soft, blurred, not detailed.

As deadrats said- don't turn DS into GOD- because he would done almost nothing without all doom9 members- it's their big job for all encodes and reporting any problems and giving suggestions. Many companies have great programmers, but it's lack of testing time, which stops them to make their product better. x264 has biggest testing community ever and free!

Quality wise x264 is as good as pro encoders for BD usage (with some stronger points and some weaker), but in terms of worflow/features/speed lot worse, so none of big studio use it.

In terms of other usage x264 is great and has clear quality advantage, but even so, most of the paid web content is not encoded with x264, but with Carbon Coder, Ateme and other hardware solution mainly because of the workflow.

x264 is an engine- needs GUI and other bits around it to be more popular.

Andrew

LoRd_MuldeR

10th January 2011, 01:12

you almost got it, you just need to expand on it a bit: if you can eliminate any quality difference between encoders with enough bit rate AND storage is not a consideration thanks to huge hard drives at very reasonable prices AND a hardware based encoder at 4 times the bit rate is 5-10 times as fast as the little darling of the open source community, then why suffer using the much slower encoder?

Still the same argumentation of yours: If you don't need/want a "good" (efficient) encoder to begin with, because you are willing to waste enough bitrate so that even a "bad" (inefficient) encoder will deliver decent quality, then indeed you won't benefit from a "good" encoder and the "bad" encoder will be sufficient for your particular needs. Still this does NOT make the "bad" encoder any better or the "good" encoder any worse. It just constructs a scenario where there's nothing for the "good" encoder to gain, because nothing is expected. Most important that argumentation does NOT add anything valuable to the discussion!

x264 is the fastest software based encoder when using the "ultra fast" preset, i'll grant you that. be that as it may, using a x4 620, transcoding a 1080p blu-ray rip to a 15 mb/s h264 with ac3 audio mkv i'm lucky if i see 15 fps, tops.

an SB cpu, using the quick sync engine, did a similar test on anandtech at 100 fps and that's without stressing any of the cpu cores.

With such fancy "speed comparisons" you must be extremely careful! In particular the following two things must be ensured:

(1) Both encodes must come out the same average bitrate. If the one encoder came out at a higher average bitrate than the other one it encoded at a lower compression efficiency and thus had an unfair advantage in the speed comparison.

(2) Both encodes must come out the same visual quality. If the one encoder produced a lower visual quality than the one, it encoded at a lower compression efficiency and thus had an unfair advantage in the speed comparison.

Unless these points are ensured, the FPS numbers are absolutely meaningless. And I'm very suspicious about that :rolleyes:

deadrats

10th January 2011, 01:14

What about downscaling the video for various different resolutions, or simply downscaling it from 1080i to 720p if the the source really doesn't have that much optical resolution to begin with ?

what?!? seriously? if something is transfered from film at 1080i then i'm going to go out on a limb and say that it has more than sufficient "optical" resolution (as opposed to what, anal resolution? LOL), likewise if it's a program recorded from hdtv it will still have enough of whatever you refer to as "optical" resolution.

why would you down rez it to 720p, i'm pretty sure i know what you're going to say, i just really want to read it for myself.

Also, you nicely ignored the fact that weasel was somewhat flabbergasted with your ideas.

le weasel was "flabbergasted" because he seems to have spent to much time worshiping at the x264 alter and stopped thinking for himself. most people react with disbelief when you first pull the veil that has been blinding them away from their eyes.

Though I'm sure you were a little too, when Windows 7 was released, and you noticed that it had the same or in same parts even lower system requitements than Windows Vista - ignoring the fact that if eg. MS spent the better part of a decade to optimize it (or really rebuild it from scratch), it'd run happily on a 486 /w 32 MB RAM.

1) i wasn't surprised, i expected microsoft to use a superior malloc() library, i expected them to rework the thread scheduler and i expected them to gpu accelerate more of the gui, specifically the 2d parts.

microsoft made a number of minor mistakes with vista, like changing the memory management model so that vista assumes that any free ram is wasted ram and caches all available ram as a consequence. win 7 does the same thing but the superior malloc() library is better at allocating and releasing ram as needed.

furthermore vista was the first to feature a fully gpu accelerated gui (for the 3d portions, xp featured partial acceleration), using win 7 leads me to believe that m$ extended that acceleration to 2d surfaces.

in so far as win 7 running on a 486, i don't care how much you optimized the code, if all of it was done using hand coded assembler, it still wouldn't run on an 486 cpu, the windows api, at least the dx parts, have been sse optimized since dx6 (back in the win2k days, modern windows Oses are all 32/64/128 bit hybrids, maybe an embedded version of win 7 could run on a 486 but that's it.