CUDA H.264 vs x264 Speed and Image Quality Benchmarks, discussion [Archive] - Page 3

stanleyhuang

13th July 2009, 05:59

MC bundles MODIFIED version of GPLed software, e.g. mplayer/mencoder and x264. But we cannot find the source codes or related patches anywhere. This is a violation of GPL.

The patch of MPlayer is freely available here (http://www.mediacoder.cn/dl/mplayer_patch_by_stanley.zip). Welcome to improve it.
Yes the bundled x264 is modified, but not modified by me. Actually it's from http://www.x264.nl as I found it's faster than my own build.
In addition, the bundled FFmpeg is from here (http://oss.netfarm.it/mplayer-win32.php) and here (http://ffmpeg.arrozcru.org/builds/)

Ramir Gonzales

13th July 2009, 14:42

After looking at the comparison pics and the amount of time of the encoding to get to this quality, I finally understand why DS doesn't want to react to this thread anymore...:rolleyes:

St Devious

13th July 2009, 14:47

13th July 2009, 14:53

After looking at the comparison pics and the amount of time of the encoding to get to this quality, I finally understand why DS doesn't want to react to this thread anymore...:rolleyes:
Well, we have yet to see a speed comparison at the same level of quality, as suggested by Dark Shikari. Since NVIDIA's encoder doesn't have settings to tune the encoding quality, this should be pretty simple: choose a reasonable bitrate and find the fastest x264 settings that match the quality of NVIDIA's encoder at that bitrate. I'd suggest trying the x264 presets first. I'm sure people will help you tune the settings further once you have found the closest preset.

Sharktooth

13th July 2009, 14:59

also 6mbps is an overkill try a set of lower bitrates like 1,500, 2,500, 4,500...

St Devious

13th July 2009, 15:02

also 6mbps is an overkill try a set of lower bitrates like 1,500, 2,500, 4,500...

ok will do. just covering my bases with all the bitrates :D

Ramir Gonzales

13th July 2009, 15:30

Why is that ?

Of the fact that x264 never had the power to convince the crowd as xvid did, and it's now crystal clear that it never will.

You see the believers (mostly) in this same forum here trying every possible method for us to convince us that x264 is better than the rest, "try this", "try that", "no! that setting is too low", "no! that setting is too high", "no, you still cannot configure the other one as you wish", etc...etc...

Yet the facts are everywhere, if you need quality from x264 it will take you way too much time to get it. Competition will get us what we need, just like the fact that xvid STILL is able to get the same quality (or even better) in the same encoding timeframe.

Sharktooth

13th July 2009, 15:36

@Ramir Gonzales: what you smoked? there's NO WAY on earth and on the universe xvid can deliver the same quality as x264 in the same encoding timeframe. THERE IS NO WAY... at least in the current state of xvid.
Also, x264 new presets are just too easy to use AND there are even several GUIs that are way too easy as well.

St Devious

13th July 2009, 15:37

Of the fact that x264 never had the power to convince the crowd as xvid did, and it's now crystal clear that it never will.

You see the believers (mostly) in this same forum here trying every possible method for us to convince us that x264 is better than the rest, "try this", "try that", "no! that setting is too low", "no! that setting is too high", "no, you still cannot configure the other one as you wish", etc...etc...

Yet the facts are everywhere, if you need quality from x264 it will take you way too much time to get it. Competition will get us what we need, just like the fact that xvid STILL is able to get the same quality (or even better) in the same encoding timeframe.

I'm not sure I agree with you. I'm a firm believer in x264's quality, especially at low bitrates when compared to Xvid. I would rather have the encoding take more time if I can display the final output at a better quality than a encoder that takes less time.

Even though I'm a firm believer in x264, I'm still willing to give the competition a try.

x264 might not have convinced you, but it just might if it was ported to GPU encoding. I'm sure with so many talented people working on it, the day is not far when a quality free encoder works on GPU.

Afterall GPU computing is still in its infancy, with interesting developments CUDA, OpenCL, DirectX Compute happening.

Sharktooth

13th July 2009, 15:40

x264 is faster than ANY cuda encoder if you build 2 PCs with the same budget AND when comparing the encoders using the same features or similar quality (otherwise wont be a fair comparison).
so please, go ahead with tests... you will notice that as well.

Dark Eiri

13th July 2009, 17:04

I've tried encoding a 1080p video (live performance in a stadium with lots of high wide angles and sparks everywhere) with the CUDA Encoder, using MediaCoder, at "Xbox 360" settings (3 B-Frames, Level 4.1, everything else at default, I have no idea if it's possible to get more than 1 ref-frame on this thing), 10 Mbps, just as I encode everyday with x264 (and get awesome quality, by the way), and guess what? It doesn't completely suck!

I mean, it's still highly humiliated by x264 (though x264 encoded @ 2.7 fps, probably bottlenecked by DGDecode or Avisynth/Yadif, and CUDA @ 18 fps, I don't care about speed, quality is my thing), but it's highly watchable. It doesn't have as much fine detail, and some areas are a little blocky, but for the average user, I think it would look fine.

CUDA Deinterlacer (Advanced options) does absolutely nothing. I guess it's not a complete feature yet. It would be really nice to see CUDA decoding and deinterlacing in a free encoder too.

It's still really crappy for SD content, though. x264 @ 2 Mbps looks transparent for the most cases, CUDA @ 2 Mbps looks just as bad as Youtube. I guess the smaller the frame size, higher is the complexity (since the bitrate needed for "transparency" doesn't really scale).

roozhou

13th July 2009, 17:05

stanleyhuang

13th July 2009, 17:05

stanleyhuang

13th July 2009, 17:09

@St Devious
If you need fast encoding for x264, you should first try to speed up your decoding

This is only true when converting a 1080 movie to a low-res (say 480x272) H.264, in such case, decoding becomes bottleneck.
If you doing 1080 to 1080 transcoding, decoding will never be the bottleneck on a quad-core.

roozhou

13th July 2009, 17:10

But if we take the GPU-based video filtering into account, the results may also differ, as GPU is far better at jobs like down-scaling, deinterlacing and other visual enhancements than doing encoding.

Yes, but GPU doesn't have to do everything. Let GPU do decoding, scaling and deinterlacing while keeping CPU doing encoding.

stanleyhuang

13th July 2009, 17:13

CUDA Deinterlacer (Advanced options) does absolutely nothing. I guess it's not a complete feature yet. It would be really nice to see CUDA decoding and deinterlacing in a free encoder too.

CUDA-based deinterlacer and other video filters will soon be available. We are just working on this part. These will not only limited to CUDA encoder. You will be able to use the filters with any encoders including x264.

roozhou

13th July 2009, 17:18

CUDA-based deinterlacer and other video filters will soon be available. We are just working on this part.

Will it work in DGAVCDecNV's way or accept unprocessed frames from main memory and output processed frames to main memory.

Personally I prefer the second way because we can insert the filter into any place of the filter chain.

stanleyhuang

13th July 2009, 17:33

Will it work in DGAVCDecNV's way or accept unprocessed frames from main memory and output processed frames to main memory.

Personally I prefer the second way because we can insert the filter into any place of the filter chain.

The process is quite straightforward. Uncompressed frames (currently only YV12 or i420) are transferred from main memory to GPU memory, a certain CUDA kernel downloaded to GPU and processes the frames (in dozens, for better parallelism and less overhead), and the processed ones are read back to main memory. As a CUDA kernel can't do really much, this process may repeat if several filters are to be applied.

Dark Eiri

13th July 2009, 17:35

CUDA-based deinterlacer and other video filters will soon be available. We are just working on this part. These will not only limited to CUDA encoder. You will be able to use the filters with any encoders including x264.

Now that's interesting! Will it be nVidia's deinterlacer or a custom made one?

stanleyhuang

13th July 2009, 17:37

Yes, but GPU doesn't have to do everything. Let GPU do decoding, scaling and deinterlacing while keeping CPU doing encoding.

Porting decoder to CUDA is not less sophisticated as porting an encoder, not mentioning there are so many different formats to decode.

roozhou

13th July 2009, 17:40

The process is quite straightforward. Uncompressed frames (currently only YV12 or i420) are transferred from main memory to GPU memory, a certain CUDA kernel downloaded to GPU and processes the frames (in dozens, for better parallelism and less overhead), and the processed ones are read back to main memory. As a CUDA kernel can't do really much, this process may repeat to if several filters are to be applied.

Anyway, it's awesome. AFAIK this will be the first stand-alone CUDA video filter. I guess a lot of MeGUI users will switch to MediaCoder if you finish this:)

stanleyhuang

13th July 2009, 17:40

Now that's interesting! Will it be nVidia's deinterlacer or a custom made one?

We are implementing the deinterlacer and some other filters.

roozhou

13th July 2009, 17:41

Porting decoder to CUDA is not less sophisticated as porting an encoder, not mentioning there are so many different formats to decode.

Not CUDA but VP2.

ChronoCross

13th July 2009, 17:47

So you think only GPLed software can have a donation button and have ads on the software's website right? Lots and lots of freewares as well as free softwares in this world are supported by Google Adsense now.

No but I feel that crooks who violate the GPL and LGPL (which you still are) don't deserve to make money off their illegal activities. Besides you made a gui....while it no doubt took a little bit to code a majority of the useful features are provided by third party programs.....so don't try to pretend your some great coding god who deserves any respect.

stanleyhuang

13th July 2009, 17:56

No but I feel that crooks who violate the GPL and LGPL (which you still are) don't deserve to make money off their illegal activities. Besides you made a gui....while it no doubt took a little bit to code a majority of the useful features are provided by third party programs.....so don't try to pretend your some great coding god who deserves any respect.

VERY NARROW-MINDED.
I am never pretending anything or your god and I state clearly the things behind the GUI.
Besides, MediaCoder is not just a GUI which can be written with a little coding and we are implementing something never existed before.

St Devious

13th July 2009, 17:57

@St Devious
If you need fast encoding for x264, you should first try to speed up your decoding
1) Use a fast decoder, e.g. libmpeg2 in ffmpeg/mencoder for MPEG2 or CoreAVC CUDA for H264. Do not use slow decoders like DGmpgdec.
2) No pre-processing, no colorspace conversion. If you have to, there must be something wrong with your decoder or source.

How do I implement libmpeg2 in the avisynth script I had a few posts back ?

This is only true when converting a 1080 movie to a low-res (say 480x272) H.264, in such case, decoding becomes bottleneck.
If you doing 1080 to 1080 transcoding, decoding will never be the bottleneck on a quad-core.

So would the decoding slow down the encoding in the Avisynth script I had ?

Will it work in DGAVCDecNV's way or accept unprocessed frames from main memory and output processed frames to main memory.

Personally I prefer the second way because we can insert the filter into any place of the filter chain.

What is this process we are talking about ?

Anyway, it's awesome. AFAIK this will be the first stand-alone CUDA video filter. I guess a lot of MeGUI users will switch to MediaCoder if you finish this:)

Continued from the above question, Why is this ?

And, How resource intensive is deinterlacing ?

stanleyhuang

13th July 2009, 17:58

Not CUDA but VP2.

At the moment, nvidia still does not allow programming the VP2 but only allows APIs for read-back the decoded frames.

stanleyhuang

13th July 2009, 18:01

So would the decoding slow down the encoding in the Avisynth script I had ?
I don't think it will noticeably slow down encoding on your powerful processor.

And, How resource intensive is deinterlacing ?
I roughly estimate that it's comparable to decoding.

roozhou

13th July 2009, 18:17

How do I implement libmpeg2 in the avisynth script I had a few posts back ?

Use ffdshow + DSS or just use mediacoder and add "-vc mpeg12," to mencoder's commandline. I highly doubt avisynth itself adds additional overhead to decoding. Try playing something in MPC-HC and playing a simple DirectShowSource("xxx") avs script in the same player. You will notice significant higher CPU load with avs script.

So would the decoding slow down the encoding in the Avisynth script I had ?
Yes if your x264 is encoding as fast as CUDA encoder.

What is this process we are talking about ?
DGAVDDecNV's deinterlacing is a part of its decoder. That means you cannot use it separately.

Continued from the above question, Why is this ?
And, How resource intensive is deinterlacing ?
Try nnedi2/eeedi/TDeint in avisynth or mcdeint in mplayer. You will see how slow a good software deinterlacer is.
Currently the best deinterlacer in MediaCoder is yadif. There is an option for mcdeint but MC is not using it correctly.

St Devious

13th July 2009, 18:21

Use ffdshow + DSS or just use mediacoder and add "-vc mpeg12," to mencoder's commandline. I highly doubt avisynth itself adds additional overhead to decoding. Try playing something in MPC-HC and playing a simple DirectShowSource("xxx") avs script in the same player. You will notice significant higher CPU use with avs script.

That 1080p source doesn't play for me in MPC-HC, but plays in WMP.

What does "-vc mpeg12" do ?

Still not sure how to use ffdshow + DSS (what's DSS ?) while encoding ?

LoRd_MuldeR

13th July 2009, 18:25

What does "-vc mpeg12" do ?

Force the decoder to MPEG-1/MPEG-2.

Still not sure how to use ffdshow + DSS (what's DSS ?) while encoding ?

DirectShowSource()

BTW: DirectShowSource() will use ffdshow if it's the only suitable DirectShow decoder available or if it has the highest Merit of all suitable decoders.

roozhou

13th July 2009, 18:27

What does "-vc mpeg12" do ?

To set libmpeg2 as the preferred decoder since libavcodec's mpeg2 decoder, which is slower, has higher priority in mplayer/mencoder.

Still not sure how to use ffdshow + DSS (what's DSS ?) while encoding ?
DSS = DirectShowSource

St Devious

13th July 2009, 18:38

Force the decoder to MPEG-1/MPEG-2.

DirectShowSource()

BTW: DirectShowSource() will use ffdshow if it's the only suitable DirectShow decoder available or if it has the highest Merit of all suitable decoders.

To set libmpeg2 as the preferred decoder since libavcodec's mpeg2 decoder, which is slower, has higher priority in mplayer/mencoder.

DSS = DirectShowSource

I see, thank you.

So in my avisynth script
DGDecode_mpeg2source("D:\Videos\1080p25.d2v", info=3)
ColorMatrix(hints=true, threads=0)
#deinterlace
#crop
#resize
#denoise

I replace DGDecode_mpeg2source with DirectShowSource() and the encoder will use ffdshow as If i have set ffdshow to decode MPEG2 ?

Is libmpeg2 faster than libavcodec in there ? And are these two options faster than DGDecode_mpeg2source ?

roozhou

13th July 2009, 18:48

Is libmpeg2 faster than libavcodec in there ?
Yes, I tested on C2D and K8. Libavcodec supports multithreading but it consumes more CPU time than libmpeg2, leaving less available CPU time for x264.
And are these two options faster than DGDecode_mpeg2source ?
Yes, I am quite sure of that, but don't expect too much.

LoRd_MuldeR

13th July 2009, 18:49

I replace DGDecode_mpeg2source with DirectShowSource() and the encoder will use ffdshow as If i have set ffdshow to decode MPEG2 ?

Nope. DirectShowSource must point to the MEPG file (PS or TS), not to the .d2v project file.

Also in addition to an MPEG-2 decoder (e.g. ffdshow), a suitable DirectShow Splitter will be needed for MPEG PS/TS files. I think Haali Media Splitter can do that.

roozhou

13th July 2009, 18:51

Nope. DirectShowSource must point to the MEPG file (PS or TS), not to the .d2v project file.

Also in addition to an MPEG-2 decoder (e.g. ffdshow), a suitable DirectShow Splitter will be needed for MPEG PS/TS files. I think Haali Media Splitter can do that.

MPC's mpeg splitter is just fine, and faster than Haali.

PS. I usually remux PS/TS test samples into mkv.

LoRd_MuldeR

13th July 2009, 18:53

MPC's mpeg splitter is just fine, and faster than Haali.

But MPC's "internal" filters aren't available to DirectShowSource, unless the "external" (standalone) versions are installed/registered.
So he either needs to install Haali's Splitter, MPC's Splitter or a similar one...

(BTW: Another option would be using FFmpegSource instead of DirectShowSource, which saves you from any DirectShow hassle)

roozhou

13th July 2009, 18:57

But MPC's "internal" filters aren't available to DirectShowSource, unless the "external" versions are installed/registered.

There are stand-alone filters (http://www.xvidvideo.ru/component/option,com_docman/task,cat_view/Itemid,11/gid,19/orderby,dmdate_published/) on xvidvideo.ru.

St Devious

13th July 2009, 18:59

Nope. DirectShowSource must point to the MEPG file (PS or TS), not to the .d2v project file.

Also in addition to an MPEG-2 decoder (e.g. ffdshow), a suitable DirectShow Splitter will be needed for MPEG PS/TS files. I think Haali Media Splitter can do that.

thanks, so no need for DGIndex anymore ?

I have Haali set to decode MPEG-TS. IF I don't set it, then what splitter does the MPEG-TS ?

MPC's mpeg splitter is just fine, and faster than Haali.

PS. I usually remux PS/TS test samples into mkv.

That's interesting. Do you use AVIDemux to remux ?

But MPC's "internal" filters aren't available to DirectShowSource, unless the "external" versions are installed/registered.

(BTW: Another option would be using FFmpegSource instead of DirectShowSource, which saves you from any DirectShow hassle)

What's DirectShow hassle ?

What do i need for FFmpegSource ? Does this point to .d2v or the .ts file ?

LoRd_MuldeR

13th July 2009, 19:03

thanks, so no need for DGIndex anymore ?

Nope. DGIndex and DGDecode/MPEG2Source() belong together. DirectShowSource() is unrelated to DGIndex.

I have Haali set to decode MPEG-TS. IF I don't set it, then what splitter does the MPEG-TS ?

DirectShow will use whatever DirectShow Splitter for MPEG-TS is installed on your system (if there's any).

If there's more than one suitable Splitters installed, the one with the highest Merit will be picked.

If no suitable DirectShow Splitter is installed on your system, then DirectShow will simply fail to build the graph.

What's DirectShow hassle ?

With DirectShowSource() you need all the required DirectShow filters installed on your system. At least a suitable DirectShow splitter plus a suitable decoder.

FFmpegSource() doesn't need that. It doesn't use any "external" decoders or splitters. Instead it runs "out of the box". It's still "beta" though...

What do i need for FFmpegSource ? Does this point to .d2v or the .ts file ?

TS file. FFmpegSource() is unrelated to DGIndex.

roozhou

13th July 2009, 19:22

FFmpegSource() doesn't need that. It doesn't use any "external" decoders or splitters, it runs "out of the box". It's still "beta" though...

As I mentioned in previous post, libavcodec's mpeg2 decoder used in FFMS is slower than libmpeg2 used in ffdshow.

St Devious

13th July 2009, 19:32

If there's more than one suitable Splitters installed, the one with the highest Merit will be picked.

Is there any way to check the merit of filters installed on the system ?

If no suitable DirectShow Splitter is installed on your system, then DirectShow will simply fail to build the graph.

What does building the graph mean ?

FFmpegSource() doesn't need that. It doesn't use any "external" decoders or splitters. Instead it runs "out of the box". It's still "beta" though...

I meant, do you need plugin or something for FFmpegSource() to work or some .exe file in avisynth folder ?

LoRd_MuldeR

13th July 2009, 19:37

Is there any way to check the merit of filters installed on the system ?

http://www.softella.com/dsfm/index.en.htm

What does building the graph mean ?

DirectShow connects the source (e.g. AVI, PS or TS file) with the sink (e.g. Video Renderer, Audio Device or Avisynth/DSS) by putting the required Filters in-between.

This is called a DirectShow Graph:

http://img222.imageshack.us/img222/5712/dsgraph.th.png (http://img222.imageshack.us/img222/5712/dsgraph.png)

If DirectShow cannot construct a chain of Filters that connects the Source to the Sink, then building the graph failed.

I meant, do you need plugin or something for FFmpegSource() to work or some .exe file in avisynth folder ?

Nothing is needed, except for the "FFMS2.dll" file, which should be located in your Aviynth/Plugins folder.

That's it. All the required splitters and decoders are "built-in", thanks to libavcodec :)

Myrsloik

13th July 2009, 23:07

That's it. All the required splitters and decoders are "built-in", thanks to libavcodec :)

Not completely true. Haali's splitter will be used (or more exactly the parser part, directly through COM) for mpeg ps/ts and ogg/ogm contents. So make sure to have the latest version installed.