MP4 encoding questions

[imaginedtruth]

First, I would like to know if there has been any overall decision made if using CUDA helps or hurts video quality when encoding?

Secondly, either paid or free, what is currently the most overall best Windows encoder program for MP4 video?

I have a handful of good quality videos that I need to re-encode to MP4 video (while maintaining compatibility with stand-alone players like a PlayStation 3). I would like to do so with doing multi-pass encoding in order to do the best it can at maintaining the original video quality. I know that any re-encode will cause some quality loss, I just need to attempt at maintaining as much of the original quality possible.

Also, I am curious if any AC3 Dolby Digital audio is supported in MP4 yet or not?

I have done some looking at Handbrake, but that seems a bit overly complicated, especially since the current version does not have a actual PS3 profile anymore.

I'm open to suggestions and advice. Thanks in advance.

[aedipuss]

1) afaik no one has ever said cuda is a quality encoder. fast yes. all the encodes i've ever made with it pretty much sucked.

2) x264. use whatever front-end floats yer boat.

3) if you put it in an mkv container.

try vidcoder, it's a simplified gui for handbrake. or xmediarecode as it does have a ps3 template.

[dragonkeeper]

First, I would like to know if there has been any overall decision made if using CUDA helps or hurts video quality when encoding?

GPU assisted encoding is not ready for prime time, better quality is achieved with CPU alone.

Secondly, either paid or free, what is currently the most overall best Windows encoder program for MP4 video?

IMO ripbot264.

I would like to do so with doing multi-pass encoding in order to do the best it can at maintaining the original video quality.

This is a misnomer, achieving better quality through multiple passes no longer holds true. For h264 encoding, do 2 pass encoding when you are trying to hit a certain file size. If quality is what you are after the better choice would to use constant quality "CQ" Mode at a CRF of 18, (This basicly tells the encoder to encode each frame of the video at a certain level of quality) and set subme to > 6.

Also, I am curious if any AC3 Dolby Digital audio is supported in MP4 yet or not?

Officially no. But i believe there is a way to hack it, this would work on a PC but stand alone devices may have trouble.

I have done some looking at Handbrake, but that seems a bit overly complicated, especially since the current version does not have a actual PS3 profile anymore.

This may be a bit more work than you're ready for if you consider handbrake to be "overly complicated", especially since there are tons of guides to walk you through every step of the way. Generally the as tools get simpler to use you begin to give up quality. But have a look at vidcoder it pretty much a simplified version of handbrake.

[poisondeathray]

ac3 support was officially added to mp4 a couple of years ago, many devices support it now, but some still don't

[jagabo]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

[smitbret]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Quality? Yes. Speed? No. I use CUDA when speed is more important than squeezing the last 10% of quality out of the video. Saying that CUDA is horrible is an exaggeration. It does the job quite well unless you're a pixel peeper. 99.5% of the population will be just as happy with CUDA as a CPU encode. Resolution and bitrate will matter far more than whether you used CUDA or not.

That being said, I do most of my encoding using Ripbot264. It's slightly simpler than Handbrake.

Are you wanting to encode for just the PS3 or other standalone players? I ask, because the PS3 will support multi-channel .aac audio in the .mp4 container but most other players will only support 2 channels. So, if you wanna use Ripbot264, just follow Jagabo's video settings. Convert the native ac3 track to a 2-channel .aac and package it in .mp4 instead of .mkv since the PS3 still doesn't support .mkv. If you are just planning on using the PS3, you could convert the audio to 5.1 channel .aac.

Using Handbrake could be beneficial since it would allow you to keep multiple audio tracks for ultimate compatibility. Use the High or Normal profile and set the output to .mp4 and check the Large File Size box. Use the CRF setting of 18 that Jagabo recommended and check your subme setting in the advanced settings tab. In the audio tab, convert the native .ac3 to an audio track that is .aac 2-channel at a bitrate of 128kbps. Then add a 2nd 5.1 .aac track with a bitrate of 320kbps. Make sure the 2-channel is the first audio track or some players may choke when they read the 5.1 first. You can always select the multi-channel on the PS3 if you want it. You could even add a 3rd audio track as an .ac3 passthru.

[dragonkeeper]

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Im inclined to agree with you, i've tested gpu assited encoding whil it was fast the picture was not very sharp, and in my test video in low light scenes look like it had a Gaussian blur applied. DVD actually looked cleaner than the gpu assisted encodes.

[jagabo]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Quality? Yes. Speed? No.

From a test I just ran on my Q6600 quad core computer (and these results reflect the results of many other tests I've run before): with a Nvidia GTX 460, Mediacoder with CUDA (h.264) encodes DVD rips at about 146 fps. Using x264 CLI that computer (AviSynth, Mpeg2Source, --preset=veryfast, --CRF 18, --ref 2, -- bframes 2) encodes at 147 fps. On my i5 2500K x264 encodes at close to 295 fps. Both the x264 encodes look better than the CUDA encodes (similar settings and similar bitrates).

[smitbret]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Quality? Yes. Speed? No.

From a test I just ran on my Q6600 quad core computer (and these results reflect the results of many other tests I've run before): with a Nvidia GTX 460, Mediacoder with CUDA (h.264) encodes DVD rips at about 146 fps. Using x264 CLI that computer (AviSynth, Mpeg2Source, --preset=veryfast, --CRF 18, --ref 2, -- bframes 2) encodes at 147 fps. On my i5 2500K x264 encodes at close to 295 fps. Both the x264 encodes look better than the CUDA encodes (similar settings and similar bitrates).

I'd like to check out your findings. I'm not much of a CLI guy so how hard would it be to set up similar settings with Handbrake or Ripbot264?

[poisondeathray]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Quality? Yes. Speed? No.

From a test I just ran on my Q6600 quad core computer (and these results reflect the results of many other tests I've run before): with a Nvidia GTX 460, Mediacoder with CUDA (h.264) encodes DVD rips at about 146 fps. Using x264 CLI that computer (AviSynth, Mpeg2Source, --preset=veryfast, --CRF 18, --ref 2, -- bframes 2) encodes at 147 fps. On my i5 2500K x264 encodes at close to 295 fps. Both the x264 encodes look better than the CUDA encodes (similar settings and similar bitrates).

I'd like to check out your findings. I'm not much of a CLI guy so how hard would it be to set up similar settings with Handbrake or Ripbot264?

--preset veryfast means:

--no-mixed-refs --rc-lookahead 10
--ref 1 --subme 2 --trellis 0 --weightp 1

But he said --crf 18 --ref 2 and --bframes 2, so you would either enter that on the commandline override, or dial in those settings in the GUI

Note many of the GUI's are much slower, because they scan/analyse the file, or do other processing stuff like IVTC, demux the file. Sometimes it adds 5-10 minutes before even starting to encode. If you know what you are doing, you can often do things much faster by setting up a script or specifying your own processing. But once the encoding has started, if you are using the same decoder, same settings, same filters, same x264 version etc... the actual encoding speed should be the same on the same hardware setup

[smitbret]

Some CPU/GPU examples:

http://www.behardware.com/articles/828-27/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-st...-and-x264.html

On a quad core CPU x264 with the veryfast preset can render faster and deliver better quality than CUDA.

Quality? Yes. Speed? No.

From a test I just ran on my Q6600 quad core computer (and these results reflect the results of many other tests I've run before): with a Nvidia GTX 460, Mediacoder with CUDA (h.264) encodes DVD rips at about 146 fps. Using x264 CLI that computer (AviSynth, Mpeg2Source, --preset=veryfast, --CRF 18, --ref 2, -- bframes 2) encodes at 147 fps. On my i5 2500K x264 encodes at close to 295 fps. Both the x264 encodes look better than the CUDA encodes (similar settings and similar bitrates).

I'd like to check out your findings. I'm not much of a CLI guy so how hard would it be to set up similar settings with Handbrake or Ripbot264?

--preset veryfast means:

--no-mixed-refs --rc-lookahead 10
--ref 1 --subme 2 --trellis 0 --weightp 1

so you would either enter that on the commandline override, or dial in those settings in the GUI

Note many of the GUI's are much slower, because they scan/analyse the file, or do other processing stuff like IVTC, demux the file. Sometimes it adds 5-10 minutes before even starting to encode. If you know what you are doing, you can often do things much faster by setting up a script or specifying your own processing. But once the encoding has started, if you are using the same decoder, same settings, same filters, same x264 version etc... the actual encoding speed should be the same on the same hardware setup

Unfortunately, I literally know next to nothing about CLI. I can pop those settings into Ripbot or Handbrake, though. Ripbot does the prescan/muxing before you set it up in the queue so I'll try that just for kicks. What is --preset veryfast using for b-frames?..... Never mind, I just looked at jagaboos settings.

[poisondeathray]

3 b-frames by default, but he said he used --bframes 2

When you use the presets, you only have to enter any changes to the defaults

Some of the gui's work by starting with the presets, and then you customize the options, megui does this and I think staxrip does too. I think pretty much all the GUI's do some sort of scanning/analyzing

[jagabo]

Handbrake doesn't support the presets but you can come close setting the individual options. This pages shows the details of the presets:

http://blog.dest-unreach.be/2009/09/08/x264-presets

That page is pretty old. I wouldn't be surprised if some of the preset settings have changed since then.

I usually change reference frames to 2 or 3 and b-frames to 2. That slows the encoder down a little but cuts the bitrate down enough (using CRF encoding) to make it worth the extra time.

You can use the veryslow preset, for example, and get slightly better quality and slightly smaller files. But it will take 10 times longer to encode.

[poisondeathray]

Handbrake doesn't support the presets but you can come close setting the individual options. This pages shows the details of the presets:

http://blog.dest-unreach.be/2009/09/08/x264-presets

That page is pretty old. I wouldn't be surprised if some of the preset settings have changed since then.

I was just going to say there are some discrepancies in those preset settings compared to the modern x264 builds

[jagabo]

Handbrake doesn't support the presets but you can come close setting the individual options. This pages shows the details of the presets:

http://blog.dest-unreach.be/2009/09/08/x264-presets

That page is pretty old. I wouldn't be surprised if some of the preset settings have changed since then.

I was just going to say there are some discrepancies in those preset settings compared to the modern x264 builds

Do you have a more recent reference? Ah, it's in the --fullhelp:

      --preset <string>       Use a preset to select encoding settings [medium]
                                  Overridden by user settings.
                                  - ultrafast:
                                    --no-8x8dct --aq-mode 0 --b-adapt 0
                                    --bframes 0 --no-cabac --no-deblock
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions none --rc-lookahead 0 --ref 1
                                    --scenecut 0 --subme 0 --trellis 0
                                    --no-weightb --weightp 0
                                  - superfast:
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions i8x8,i4x4 --rc-lookahead 0
                                    --ref 1 --subme 1 --trellis 0 --weightp 1
                                  - veryfast:
                                    --no-mixed-refs --rc-lookahead 10
                                    --ref 1 --subme 2 --trellis 0 --weightp 1
                                  - faster:
                                    --no-mixed-refs --rc-lookahead 20
                                    --ref 2 --subme 4 --weightp 1
                                  - fast:
                                    --rc-lookahead 30 --ref 2 --subme 6
                                    --weightp 1
                                  - medium:
                                    Default settings apply.
                                  - slow:
                                    --b-adapt 2 --direct auto --me umh
                                    --rc-lookahead 50 --ref 5 --subme 8
                                  - slower:
                                    --b-adapt 2 --direct auto --me umh
                                    --partitions all --rc-lookahead 60
                                    --ref 8 --subme 9 --trellis 2
                                  - veryslow:
                                    --b-adapt 2 --bframes 8 --direct auto
                                    --me umh --merange 24 --partitions all
                                    --ref 16 --subme 10 --trellis 2
                                    --rc-lookahead 60
                                  - placebo:
                                    --bframes 16 --b-adapt 2 --direct auto
                                    --slow-firstpass --no-fast-pskip
                                    --me tesa --merange 24 --partitions all
                                    --rc-lookahead 60 --ref 16 --subme 11
                                    --trellis 2

from x264 version 0.116.2044.

[poisondeathray]

Do you have a more recent reference?

Not nicely laid out. I just referenced the help file . Besides, things are always changing with x264 development

x264 --fullhelp

jagabo you probably know this already, but to print it out to a text file, that you can read in wordpad (notepad doesn't retain text formatting)

x264 --fullhelp 1>fullhelp.txt

[jagabo]

If you're wondering what you're losing by using the "veryfast" preset compared to slower presets: there will be a little more loss of small low-contrast details (eg, film grain). The edges of moving objects will be a little rougher.

[smitbret]

Handbrake doesn't support the presets but you can come close setting the individual options. This pages shows the details of the presets:

http://blog.dest-unreach.be/2009/09/08/x264-presets

That page is pretty old. I wouldn't be surprised if some of the preset settings have changed since then.

I was just going to say there are some discrepancies in those preset settings compared to the modern x264 builds

Do you have a more recent reference? Ah, it's in the --fullhelp:

      --preset <string>       Use a preset to select encoding settings [medium]
                                  Overridden by user settings.
                                  - ultrafast:
                                    --no-8x8dct --aq-mode 0 --b-adapt 0
                                    --bframes 0 --no-cabac --no-deblock
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions none --rc-lookahead 0 --ref 1
                                    --scenecut 0 --subme 0 --trellis 0
                                    --no-weightb --weightp 0
                                  - superfast:
                                    --no-mbtree --me dia --no-mixed-refs
                                    --partitions i8x8,i4x4 --rc-lookahead 0
                                    --ref 1 --subme 1 --trellis 0 --weightp 1
                                  - veryfast:
                                    --no-mixed-refs --rc-lookahead 10
                                    --ref 1 --subme 2 --trellis 0 --weightp 1
                                  - faster:
                                    --no-mixed-refs --rc-lookahead 20
                                    --ref 2 --subme 4 --weightp 1
                                  - fast:
                                    --rc-lookahead 30 --ref 2 --subme 6
                                    --weightp 1
                                  - medium:
                                    Default settings apply.
                                  - slow:
                                    --b-adapt 2 --direct auto --me umh
                                    --rc-lookahead 50 --ref 5 --subme 8
                                  - slower:
                                    --b-adapt 2 --direct auto --me umh
                                    --partitions all --rc-lookahead 60
                                    --ref 8 --subme 9 --trellis 2
                                  - veryslow:
                                    --b-adapt 2 --bframes 8 --direct auto
                                    --me umh --merange 24 --partitions all
                                    --ref 16 --subme 10 --trellis 2
                                    --rc-lookahead 60
                                  - placebo:
                                    --bframes 16 --b-adapt 2 --direct auto
                                    --slow-firstpass --no-fast-pskip
                                    --me tesa --merange 24 --partitions all
                                    --rc-lookahead 60 --ref 16 --subme 11
                                    --trellis 2

from x264 version 0.116.2044.

So, I ripped and re-encoded a 1GB segment of The Mummy last night, trying to apply as many of the veryfast settings that I could figure out with Handbrake:

I selected the Normal Profile
Constant Quality - 18
Reference Frames - 2
Maximum B-Frames - 2
Cabac - 1
Weighted P-Frames - 1
Adaptive B-frames - Default (Fast)
Adaptive Direct Mode - Default (Spatial)
Motion Estimation - Dia
Subpixel ME & Mode Decision - 6
Trellis - 0
Deblocking 0,0
Added "mixed-refs=0:rc-lookahead=10" to the text box

Ran it through and to my surprise, the encode ran between 319-359fps. I'm using a Phenom II x4 955 and did not expect that kind of performance. Does that seem reasonable compared to your Q6600? Makes me wonder if I have implemented a decent approximation of your settings. If so, it is impressive. I ran the same clip though Xilisoft with CUDA enabled I set it to:
Same Quality (CRF ~18-20)
Trellis=1
subme=umh
reference frames=3

It ran very slightly faster than the CPU encode and seemed to suffer from less blocking but was also less sharp. While I don't think either one would really satisfy my tastes, I would probably prefer the CUDA encode. I should probably compare the clips on my 50" tv instead of my 21" monitor and see if I would still prefer the CUDA encode, though.

I'll have to admit, I was very, very surprised at how quick the CPU encode was. I'm gonna have to play around with settings and find a combination that seems to work best. What setting(s) should I tweak first to remove the generalized blocking? Aside from deblocking (obviously) I was thinking of upping the reference frames to 3 and changing the subme to umh and trying it again. I think I'll mess around with some HD sources, too.

[poisondeathray]

what does "deblocking 0" mean in handbrake? does it mean deblock is off? Because later on you have deblock 0,0 which usually refers to the strength

the default settings are --deblock 0:0 which mean alpha and beta inloop deblock is enabled but the "0" refers to the strength of alpha and beta respectively; lower values (negative) weaken the strength of deblocking, higher values increase the strength (smoother picture, less detail)

so if you've turned off inloop deblocking then it's no surpise that it looks more "blockier"

also what kind of handbrake processing? IIRC does some weird mix between IVTC and deinterlacing and calls it "detelecine" or "decombing" or something

how is the source? often source has blocking in it?

What were the bitrates compared between the CUDA encode and software encode ? You can only make comparisons when you compare similar bitrates

[smitbret]

what does "deblocking 0" mean in handbrake? does it mean deblock is off? Because later on you have deblock 0,0 which usually refers to the strength

the default settings are --deblock 0:0 which mean alpha and beta inloop deblock is enabled but the "0" refers to the strength of alpha and beta respectively; lower values (negative) weaken the strength of deblocking, higher values increase the strength (smoother picture, less detail)

so if you've turned off inloop deblocking then it's no surpise that it looks more "blockier"

also what kind of handbrake processing? IIRC does some weird mix between IVTC and deinterlacing and calls it "detelecine" or "decombing" or something

how is the source? often source has blocking in it?

What were the bitrates compared between the CUDA encode and software encode ? You can only make comparisons when you compare similar bitrates

I just turned off deblocking completely. When I posted, I did a rewrite/revision and should have deleted the first "deblock 0" comment. Wouldn't turning the deblocking on increase the time it takes to encode?

I had deinterlace and decomb filters turned off for both encodes (CUDA/non-CUDA).

The source was the original DVD. The blocking is not there in the original .vob file.

The end files were nearly identical with the CUDA encode being slightly smaller (437MB vs. ~420MB) if my memory serves correctly. I also removed the audio track in both cases, so the audio size is a non-factor. I also did a 2-pass CUDA encode that was also faster than the CPU encode by a few seconds and set it for 437MB. Came out at like 436.1MB and still was lower quality than I would normally like.

[poisondeathray]

Deblocking should never be turned off for h.264. It's a standard feature and by default enabled in every AVC encoder (not just x264). Only if you are using ginormous bitrates on the high end of the compression curve would you even think of disabling it

The other difference between your settings and jagabo's was subpixel motion estimation
he used --subme 2

For a standard Hollywood movie, you wouldn't deinterlace it, this will just degrade the image. You would inverse telecine it (IVTC)

[smitbret]

Deblocking should never be turned off for h.264. It's a standard feature and by default enabled in every AVC encoder (not just x264). Only if you are using ginormous bitrates on the high end of the compression curve would you even think of disabling it

The other difference between your settings and jagabo's was subpixel motion estimation
he used --subme 2

For a standard Hollywood movie, you wouldn't deinterlace it, this will just degrade the image. You would inverse telecine it (IVTC)

Cool, I'll rerun it. The "Normal Profile" in Handbrake has it set for 0,0, so I just left it alone. What settings would you recommend?

I'll change that and the subme to 2. Looking through the thread, I see that I confused Dragonkeeper's comment about setting subme > 6 with Jagabo's recommendations.

I didn't deinterlace or decomb. Both filters were set to off. As far as reverse telecine, I don't see a setting in Handbrake for it. However, there is a choice for detelecine and from the descriptions that I'm reading, that should be the same thing. I'll check it out tonight.

[poisondeathray]

I can't make specific recommendations because your goals might be different than mine or someone else's

jagabo said he finds those settings a good compromise speed/quality tradeoff

It's a win-win because you can customize it to however you want

I think IVTC is called "detelecine" in handbreak

[jagabo]

I just tried to get the same settings in Handbrake (I'm not really familiar with the program) and examined the resulting file with MediaInfo to see exactly what settings were used. How do you manually enter settings in Handbrake? I tried adding them into the box at the bottom of the Advanced tab but they don't seem to be passed to the encoder. Right now I have this:



MediaInfo shows there are still a few differences between the two:

h : psy_rd=0.00:0.00, weightb=0, weightp=2, rc_lookahead=40
x : psy_rd=1.00:0.00, weightb=1, weightp=1, rc_lookahead=10

The resulting video looks about the same as the x264 cli veryfast encode. Handbrake encoded slightly slower and the file turned out 10 percent larger. I don't see significant blocking (I use a 4x point resize magnifier to examine videos closely).

[poisondeathray]

Might also be some difference due to x264 versions. Apparently they use an older build, unless you use the beta or nightly builds, or vidcoder

https://forum.videohelp.com/threads/340353-Want-a-good-GUI-with-x264-r2106

https://build.handbrake.fr/job/Windows/




Might be some processing differences as well. You might be using DGDecode with force film, which would be faster than a software IVTC or "detelecine"

FYI , there is a new version of DGDecode.dll, which is about 20% faster for decoding speed (not necessarily reflected in final encoding speed)
http://forum.doom9.org/showthread.php?t=162920



I'm not that familiar with handbrake either, but it looks like you can enter parameters in the command line box. Some other GUI's have this too

[jagabo]

I'm not that familiar with handbrake either, but it looks like you can enter parameters in the command line box.

That's what I thought but what I type in there doesn't show up in encoding.

[smitbret]

I can't make specific recommendations because your goals might be different than mine or someone else's

jagabo said he finds those settings a good compromise speed/quality tradeoff

It's a win-win because you can customize it to however you want

I think IVTC is called "detelecine" in handbreak

So, what you are saying is that I should be performing IVTC on any DVD of a major Hollywood motion picture?

[jagabo]

So, what you are saying is that I should be performing IVTC on any DVD of a major Hollywood motion picture?

Pretty much.

Are you still getting a lot of macroblocks in your CRF 18 encodes?

[smitbret]

So, what you are saying is that I should be performing IVTC on any DVD of a major Hollywood motion picture?

Pretty much.

Are you still getting macroblocks in your CRF 18 encodes?

Damn! Now I have to re encode a bunch of DVDs. It's not that they didn't work great the first time, it'll just bother me that they aren't encoded as efficiently as the could have been. I'm thinking I might have a touch of OCD.

I didn't get a chance to do anything last night. I will mess with it tonight, though.

[jagabo]

So, what you are saying is that I should be performing IVTC on any DVD of a major Hollywood motion picture?

Pretty much.

Damn! Now I have to re encode a bunch of DVDs.

Check some of your encodes first. DVDs that were encoded at 23.976 with pulldown flags may already have been encoded at 23.976 without having to specify IVTC. It depends on whether Handbrake performs the pulldown or not.