x264 + avx support (off-topic discussion)

[deadrats]

Encoding is inherently a SERIAL process with SOME parts that can be done parallel. Seti and folding is all parallel stuff, relatively easy to implement on a GPU.

there's 2 very big problems with your argument:

1) encoding is a "serial" process, huh? how many frames would you say is in the average movie? how many gop segments?

now granted b and p frames, since they are dependent on other frames, would logically have to be processed in a serialized fashion, however a gop segment can be processed on it's own, you can't think of any way to process multiple gop segments simultaneously?

if encoding is "inherently a serial process" then why does x264 have a hard coded thread limit of 128? sounds to me like video encoding can be parallelized pretty efficiently.

you also have to do the ME calculations on every single frame, that certainly sounds like something that can be parallelized fairly easily.

2) for the sake of argument let's assume that video encoding is purely a serial process, that it can't be parallelized at all. are you familiar with BLAST? how about data encryption/decryption? they are both very serialized tasks that run like stink on a monkey on a gpu.

as i said, programmers are stuck thinking about things the way they are taught in school, in CISC x86 terms, i have no doubt that if RISC was the dominant architecture on the desktop the conversation with regards to gpu encoders would be different.

[nm]

This thread should probably be split, but here we go again.

that really depends on what your definition of "high bit rate" is

Well, let's say above 30 Mbps for 1080p24, considering that common sources aren't much higher.

if however you use a good quality cuda encoder, like the one elemental developed for adobe or the main concept developed one found in magix's and roxio and you use a sane bit rate, perhaps 8-12 mb/s for 720p encodes and you use a good high quality clear source, then you will be more than satisfied with the results.

Could you point me to such an encode or maybe even post one? I'd like to see this with my own eyes. The Island trailer or some similar publicly available high-quality source would suffice.

check out this gpu powered mpeg-2 encoder to see what a gpu powered encoder is capable of doing:

http://www.gputech.com/gpeg2/


1920x1080 at 50 fps on a Radeon HD 4870? Doesn't sound that impressive even if the quality is good. FFmpeg seems to run at 30 fps on a single 2.4 GHz C2D core with default parameters and -qscale 3. I also decoded the source MPEG-2 on the same core.

Any 3rd party quality comparisons?

[deadrats]

This thread should probably be split, but here we go again.

there's no reason for this thread to be split, conversations naturally evolve and often go off into tangents. since i am the OP and i have no problem with this thread going "off topic", i don't see why anyone should care either.

Could you point me to such an encode or maybe even post one? I'd like to see this with my own eyes. The Island trailer or some similar publicly available high-quality source would suffice.

i'm more than happy to post one, link me to the "island trailer" you're talking about and i'll do a few encodes using the main concept cuda encoder included with roxio's software.

i also have some really high quality adult movies, i''l clip a minute or so from the beginning where it's only dialog, post the source and the test encode and you can make draw your own conclusions.

1920x1080 at 50 fps on a Radeon HD 4870? Doesn't sound that impressive even if the quality is good. FFmpeg seems to run at 30 fps on a single 2.4 GHz C2D core with default parameters and -qscale 3. I also decoded the source MPEG-2 on the same core.

30 fps @ 1080p? not on my x4 620, not even close.

[poisondeathray]

@deadrats - benwaggoner's original links for the island trailer are here

http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/The%20Island%20Trailer

There were some other mirrors posted, do a search you might find them

[nm]

i'm more than happy to post one, link me to the "island trailer" you're talking about and i'll do a few encodes using the main concept cuda encoder included with roxio's software.
Here's my copy (http://hattivatti.dy.fi/video/Island_1080p24_lag_51.avi) if you don't feel like clicking all those links at Skydrive.

30 fps @ 1080p? not on my x4 620, not even close.
Ok, a command-line for you to try:

mencoder -ovc lavc -nosound -lavcopts vcodec=mpeg2video:vqscale=3 input.ts -o output.avi


Or with ffmpeg:

ffmpeg -i input.ts -an -vcodec mpeg2video -qscale 3 output.avi


Unfortunately the codec is not threaded very well, so you can only gain ~50% more speed with multiple threads. But ffmpeg-mt or x262 might provide an open source solution to that at some point.

Also watch for slow decoding. It's easy to bottleneck a fast encoder with slow input.

[deadrats]

ok folks, here is a test sample:

http://www.mediafire.com/?az1hxp7a3zc3xdg

and here is the test encode:

http://www.mediafire.com/?r6e35opvb55jmbe

the source is a clip i cut from a legally purchased movie, the name of the site is watermarked on the clip, it's 720p25, 8 mb/s, i think you guys will agree with me that it's a very high quality, crisp, clear source, i made sure that i cut a sequence that doesn't violate this forums rules.

the test encode is a 800x450p25, ~3 mb/s, and for the sake of reproducibility i used media coder 2011 rc1, the cuda encode was done at 52 fps.

i also did the same test encode with x264, ultra fast setting, the encode was done at 54 fps but to me this encode looks like crap, i will be linking to that one in a bit as soon as it's done uploading.

edit: here's the link for the x264 test encode:

http://www.mediafire.com/?wf6821ep0tbb7s1

[RunningSkittle]

...i also did the same test encode with x264, ultra fast setting, the encode was done at 54 fps...

Certainly you must be limited by your decoder...

[poisondeathray]

or maybe bottleneck might be filtering (resize)

[deadrats]

Certainly you must be limited by your decoder...

it's not my decoder, it's the decoder included with media coder, i use MEncoder for the decoding duties.

besides, assuming it was the decoding that was the bottleneck, the cuda encoder is also limited by the same decoder, thus they would both be faster.

regardless, this test was about testing the claim that cuda based encoders have lousy quality, as you can see by this test encode, which anyone can reproduce using the software i used, proves that the quality of a cuda encoder is not necessarily inherently bad.

@poisondeathray:

i used the same resize filter for both test encodes, namely "natural bicubic spline", if x264 is bottlenecked by said filter then so is the cuda encoder, either way the relative performance wouldn't change.

out of curiosity, what kind of performance were you guys expecting out of x264, it beat the cuda encoder by 2 fps, you didn't actually think that x264 was going to smoke a gpu powered encoder, did you? LOL.

also, if anyone wonders why it seems i have such a woody for gpu powered software, the answer is simple really: it's much easier, and cheaper, to upgrade just a video card than it is to upgrade cpu/motherboard/ram to get faster performance with a software based encoder.

of course, i'm still going to upgrade to a SB system as soon as the new chipsets are out (maybe i'll wait a month or two just to be sure there's no other issues) but if SB lives up to it's promises, it may just be the closest thing we have ever seen to a "future proof" cpu in a long time.

[RunningSkittle]

out of curiosity, what kind of performance were you guys expecting out of x264, it beat the cuda encoder by 2 fps, you didn't actually think that x264 was going to smoke a gpu powered encoder, did you? LOL.

Actually yes, so keeps the 'lols' to your self:
The reason we're curious is because x264 can get well over 200fps on ultrafast for SD content (on my q6600 anyway). I assume media-coder is using your nvidia card to decode... which would indeed be a large bottleneck.

make a avisynth script, and use ffms2-mt as decoder. (or a x264 build with ffms2-mt built in)

[poisondeathray]

LOL... I said there is a bottleneck somewhere because both should be much faster for SD encoding... There is a bottleneck somewhere for sure.



also, if anyone wonders why it seems i have such a woody for gpu powered software, the answer is simple really: it's much easier, and cheaper, to upgrade just a video card than it is to upgrade cpu/motherboard/ram to get faster performance with a software based encoder.


Totally agree. But your options are limited for GPU encoding. You can't get much higher compression ratio, or better quality out of the GPU encoder. You can out of software x264.

Now I dare you to try some higher quality source, like the island trailer, or park joy

[deadrats]

Actually yes, so keeps the 'lols' to your self:
The reason we're curious is because x264 can get well over 200fps on ultrafast for SD content (on my q6600 anyway). I assume media-coder is using your nvidia card to decode... which would indeed be a large bottleneck.


actually i think a 'ROTFLMAO' is appropriate right now:

1) media coder doesn't have a gpu powered decoder, it uses either ffmpeg or mencoder, that's one of the reasons i used media coder, it allows me to standardize testing by using the same filters, decoders, etc across all tests and simply use the encoder i want to test.

the only software that i know of that uses a gpu powered decoder is tmpg express (and that's only for mpeg-2 decoding) and cyberlink's espresso, and now that i think about it i think there's one more that uses the same sdk as cyberlink, other than that there are no gpu powered decoders (yes, i know about nueron's software).

2) i get about 200 fps working with SD content with both x264 and cuda, in test after test, using a x4 620, 4 gigs ddr2 800 and a gts 250, using media coder as the test app, x264 @ 'ultra fast' is for all intents and purposes tied with the cuda encoder, at the same bit rates, with the same number of b frames.

once i start adding filters to the equation however, cuda starts pulling away and if i'm going from a 9800 kbps vob to 4 mb/s avc, @ 480p, with de-interlacing, color correction, denoising and deblocking the cuda encoder lays down a 20-50 fps sustained encoding advantage over x264@ultra fast (x264 slows down to the 130 fps range while cuda stays at about 180 fps).

that's why i laugh when people go on these forums and talk so much junk about gpu powered encoders based on what they heard from someone else, when it's obvious that they never took the time to test it out for themselves.

i have tested it out, i've done more test encodes with more encoders and parameters and more sources than i know what to do with.

[deadrats]

Now I dare you to try some higher quality source, like the island trailer, or park joy

i'm more than happy to but all the links i can find for those sources are really slow, it's going to take 10 hours to download those 2+ gig sources.

doesn't anyone have a link to a reasonably fast server or maybe a different high quality source that i can use?

[mariush]

1) encoding is a "serial" process, huh? how many frames would you say is in the average movie? how many gop segments?


Doesn't really matter, as x264 is not designed to work with just static files on the disk, knowing in advance how many frames it will have to encode and therefore read content in advance. It can also be used for live streaming and other things.

if encoding is "inherently a serial process" then why does x264 have a hard coded thread limit of 128? sounds to me like video encoding can be parallelized pretty efficiently.


Because some parts as I said can be parallelized, like motion search and so on.


you also have to do the ME calculations on every single frame, that certainly sounds like something that can be parallelized fairly easily.
[b]

Yes, it can. However, it may be the case that it's faster to do it on CPU compared to
1. uploading data to video card
2. loading and compiling code into the video card,
3. wait for video card to process data (well wait is a bad word, as this could be async)
4. download the processed data,
5. adapting the processed data to your needs

When you can read ahead let's say 100 1080p frames and queue them in the video card to run something in parallel it may be worth it, but when we're talking about working with a small number of frames, choosing various parameters for each frame so that variable bitrate and other things x264 uses, it may be too complex to be worth it.

[B]
2) for the sake of argument let's assume that video encoding is purely a serial process, that it can't be parallelized at all. are you familiar with BLAST? how about data encryption/decryption? they are both very serialized tasks that run like stink on a monkey on a gpu.


Have a look at AES encrypting on GPU: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch36.html

It's 1.7x faster than using a Pentium 4 cpu and they mention most of the time is spend loading data into the video card as textures. Can you compare a simple aes encryption routine with a very complex video encoder? If this brings so little improvement, can you say with a straight face that x264 would be much better in gpu, while preserving its current quality?

Probably almost anything could be done in GPU but there's a point where you just have to say "it's not worth it". I'm not saying x264 shouldn't use GPU, if some expert programmers can add this to x264 would be great, because maybe in 2-3 years the performance will be there to be worth it, when x264 will become x265.

Right now, with 10 core Intel processors, with 16 core AMD processors coming up, the cpu only performance is good enough.

---------

regarding your dubious selection of content for testing...

Porn movies are filtered and processed, they're not good for benchmarks. I work with erotic content almost on a daily basis doing video processing so I should know.

And the other sample... it looks OK but then you're AGAIN resizing the content.. why the hell don't you leave the source as is and always have to mess with it?
And then why don't you just create a RAW video file on your disk rather than blaming speed of encoder on the resizing...

Why don't you stop "cherry picking" and use some already known test sequences:

http://forum.doom9.org/archive/index.php/t-135034.html

This one has Parkjoy and other test sequences at various resolutions, including a 720p 50 fps one you can use directly without resizing and messing up.

ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/

[deadrats]

@mariush

Doesn't really matter, as x264 is not designed to work with just static files on the disk, knowing in advance how many frames it will have to encode and therefore read content in advance. It can also be used for live streaming and other things.

i wasn't actually talking about x264 specifically, more about the viability of a gpu powered encoder in general.

regarding the "live streaming" objection, "live streaming" doesn't mean "live encoding", the content isn't encoded on the fly, it's just played as it's being downloaded.

thus any programming technique you would use for an encoder that encodes content for local playback can also be used for an encoder that creates content for streaming.

1. uploading data to video card
2. loading and compiling code into the video card,
3. wait for video card to process data (well wait is a bad word, as this could be async)
4. download the processed data,
5. adapting the processed data to your needs

i have seen variations on this objection numerous times and quite frankly it smacks of not thinking things through:

video cards are accessed via the pci-e interface and use very fast gddr3-5 ram, they were designed to render millions of polygons per second and receive gigabytes worth of textures in the process, i somehow doubt that a video card that was designed to run a 3d game at 2560x1920 at 100+ fps will somehow suffer crippling performance hits by having a 1080p video uploaded into it's buffer. furthermore, since the video cards buffers are way faster than the system ram, any performance impact incurred by uploading and downloading data from the video card is offset by the much faster access times the gpu enjoys in accessing it's onboard ram.

When you can read ahead let's say 100 1080p frames and queue them in the video card to run something in parallel it may be worth it, but when we're talking about working with a small number of frames, choosing various parameters for each frame so that variable bitrate and other things x264 uses, it may be too complex to be worth it.

again, forget about x264, i've came to the conclusion some time ago that the way it was coded does not lend itself to porting over to run on a gpu, i'm talking about encoder in general, one built from scratch with gpu acceleration in mind.

and the tactic i would choose would be to launch a read ahead thread, one that analyses the file, segments each gop sequence into a separate array and launches a worker thread for each on the gpu, one for each cuda core, then retrieves the results and concatenates them into a target file.

basically i would treat the video file just like any other type of data stream that i wanted to process, segment it, assign a thread to each segment and let the gpu crunch through the processing.

Have a look at AES encrypting on GPU: http://http.developer.nvidia.com/GPU...ems3_ch36.html

It's 1.7x faster than using a Pentium 4 cpu and they mention most of the time is spend loading data into the video card as textures. Can you compare a simple aes encryption routine with a very complex video encoder? If this brings so little improvement, can you say with a straight face that x264 would be much better in gpu, while preserving its current quality?

talk about biased reporting. if you look through the test setup you will see that the test system used a 3ghz P4 with a 8800gts 640mb, 1 gig of ram, running linux.

using a faster cpu one would expect that both cpu's and gpu's performance would increase and with a newer generation gpu one would expect to see a much bigger margin of victory.

also keep in mind that it was results like these that prompted intel to include hardware aes encryption/decryption in all their cpu's, they realized that there's no way a software encryption/decryption solution can match a gpu powered one so they got their own hardware accelerated solution.

Right now, with 10 core Intel processors, with 16 core AMD processors coming up, the cpu only performance is good enough.

what intel cpu have you seen that has 10 cores and which 16 core amd cpu are you talking about?

intel has no intention of releasing more than 4 core cpu's for consumer consumption, the power requirements would be too high.

that's why they spent 5 years developing quick sync, so that software based encoding could be removed from the equation and that's why they added 256 bit avx for scientific and business applications so that the heavy lifting could be done without needing to go above 4 cores.

you will never, ever, ever, see a 10 core intel cpu on the desktop for consumer consumption, never.

And the other sample... it looks OK but then you're AGAIN resizing the content.. why the hell don't you leave the source as is and always have to mess with it?
And then why don't you just create a RAW video file on your disk rather than blaming speed of encoder on the resizing...

1) it's silly to create a RAW file, the average home user doesn't have access to uncompressed sources nor do they go out and shoot footage with a 40k RED camera, what they have is previously compressed content in the form of downloaded stuff, dvd or blu-ray.

2) the reason for resizing is because it mimics the average users workload, who in their right minds is going to take a 8 mb/s 720p file that they downloaded (either legally or illegally) and transcode it to a lesser bit rate at the same resolution?

if someone is so inclined to do that then they shouldn't be allowed anywhere near a computer because they are just dumb mother flowers.

[Sharktooth]

no, not again... this thread is entitled x264 + avx. what the hell has those last posts have to do with the title?
the discussion is going completely off topic on an argument that was already discussed to death... the only way to get GPU encoding any good is to integrate the GPU itself into the CPU die and have a good amount of cache shared between them. until then it's crap. period.
now lets get back on topic.

[CruNcher]

Still Intel has recalled all the series 6 chipsets that have been delivered so far, even though "only" the 3 GBit/s SATA ports are defective.

As far as I know, most (if not all) shops have stopped selling the effected boards immediately and it will take about 6 weeks for the "fixed" boards to become available.

If you already have one of the effected boards, it will be up to you whether you care about the problem and return the board to the manufacturer or not...

Luckily not everyone cares about that if it has todo with capital LoRd_Mulder


die Ware, die Sie am 02.2.2011 um 18:50 Uhr online bei uns bestellt haben, wurde am 03.2.2011 um 18:00 Uhr an die folgende Lieferadresse verschickt:


no, not again... this thread is entitled x264 + avx. what the hell has those last posts have to do with the title?
the discussion is going completely off topic on an argument that was already discussed to death... the only way to get GPU encoding any good is to integrate the GPU itself into the CPU die and have a good amount of cache shared between them. until then it's crap. period.
now lets get back on topic.

And thats where i thought Fusion (Zacate, Ontario) would shine @ but reviews show it doesn't even support Hardware Encoding @ all


Wait—encode is happening on the processor? We have 80 stream processors in a pair of SIMD engines—why not offload to those in much the same way that Intel involved its EUs in encode acceleration on Sandy Bridge? AMD does have encode acceleration available on its discrete graphics products. But the two SIMD engines on Zacate simply aren’t powerful enough to demonstrate an appreciable benefit. This functionality will be available through the Sabine platform’s Llano APU, so we’ll have to wait until later this year to see how well it works.

[nm]

ok folks, here is a test sample:

http://www.mediafire.com/?az1hxp7a3zc3xdg

and here is the test encode:

http://www.mediafire.com/?r6e35opvb55jmbe

That's not the high quality encode I was after. Blocking/smearing is visible all over the video during playback and it's horrid when freeze-framing. Even x264 --preset veryfast beats it clearly and should be as fast to encode even with MediaCoder since both encoders were bottlenecked by filtering.

This command line gives me 45 fps on a 2.4 GHz Core 2 Duo (T8300):
x264 --preset veryfast --bitrate 3000 --fps 25 --vf resize:800,450,,,,bicubic -o test.264 "test source 8 mbs 720p25.mp4"

If I did these kind of fast encodes for some playback purpose, I'd prefer CQP/CRF encoding over ABR. Can you set the CUDA encoder to constant quantizer mode? If not, how about 2-pass for higher quality?


2) i get about 200 fps working with SD content with both x264 and cuda, in test after test, using a x4 620, 4 gigs ddr2 800 and a gts 250, using media coder as the test app, x264 @ 'ultra fast' is for all intents and purposes tied with the cuda encoder, at the same bit rates, with the same number of b frames.

Tied with quality too? Ultrafast is not really useful in practice. Veryfast is the fastest preset that gives watchable output.

once i start adding filters to the equation however, cuda starts pulling away and if i'm going from a 9800 kbps vob to 4 mb/s avc, @ 480p, with de-interlacing, color correction, denoising and deblocking the cuda encoder lays down a 20-50 fps sustained encoding advantage over x264@ultra fast (x264 slows down to the 130 fps range while cuda stays at about 180 fps).

I'd do it the other way around: filter with the GPU and encode with x264. Better quality and much faster encoding.


all the links i can find for those sources are really slow, it's going to take 10 hours to download those 2+ gig sources.

Have you got them now? No hurry, I'm patient.

[deadrats]

no, not again... this thread is entitled x264 + avx. what the hell has those last posts have to do with the title?
the discussion is going completely off topic on an argument that was already discussed to death... the only way to get GPU encoding any good is to integrate the GPU itself into the CPU die and have a good amount of cache shared between them. until then it's crap. period.
now lets get back on topic.

2 things come to mind:

1) this is my thread, if i don't care if it goes "off topic" (as conversations normally evolve over their courses) then why should anyone else?

2) your crack about gpu encoding is clearly wrong, as i have already demonstrated a high quality gpu encode AND i fail to see how cache size on a cpu/gpu hybrid would affect encoding quality and lastly SB does fulfill your specified conditions, thus i'm concluding that you expect QS encodes to be pretty good.

lastly, the avx/x264 connection has been examined thus there's no harm in people entertaining themselves by discussing whatever they choose.