Lovin' my H.264 encodes in FFDshow... other players, not so much.

[kai0n7]

Hello,

I recently started dabbling with H.264 AVC encoding to backup my DVD collection. I had a hell of a time with grain retention and blocking early on, but thanks to the great info here, meGui, and MP4Guy's custom matrices, I'm producing some very nice encodes. Thanks so much.

Couple of things came up though that I need some advice on. When using FFDshow and Haali to play back, everything looks fantastic. Little to no blocking, and excellent grain retention. However, when I play back a file with Nero Showtime, which uses graphics card hardware acceleration, I'm getting alot of blocking in low contrast areas. Should this be happening? My deblocking settings were a bit aggressive (-4,-2), and dialing them back on a test encode to (-2,-1) seemed to help, at the cost of some detail.

Secondly, Quicktime won't play the files back very well at all, though it doesn't seem to have any issues when playing back HD trailers and whatnot. Could this mean there is something wrong with my encoding settings?

Any advice/info would be appreciated.

[Dark Shikari]

Quicktime pretty much just sucks. If it breaks with an H.264 stream, its far more likely its Quicktime's problem, not x264's.

[fibbingbear]

Ditto on the Quicktime comment.

I know that when I play stuff with hardware acceleration, the video looks degraded as well --- in particular, stuff is darker. I had to mess around with my video card to get it to look better. I don't understand why video card designers make hardware acceleration look different than non-hardware acceleration by default....

[kai0n7]

I expected this would be the case, as far as Quicktime goes.

Any other thoughts on my issue with Nero's decoder? The DXVA playback is actually *lighter* than with FFDshow (requiring some fiddling with Nvidia Control Panel color settings... used to seeing this with MPEG2 playback), but the blocking being introduced is what is really troubling me.

[Sharktooth]

different renderer... different color range....
since it's ligther blocks are more visible...

[nm]

Any other thoughts on my issue with Nero's decoder? The DXVA playback is actually *lighter* than with FFDshow (requiring some fiddling with Nvidia Control Panel color settings... used to seeing this with MPEG2 playback), but the blocking being introduced is what is really troubling me.Which graphics card do you have? Showtime may be skipping deblocking on older GPUs, which will cause quality problems.

[georgevalkov]

If You want a x264 clip to play on a current version of the QuickTime player, you have to disable a lot of the features of the encoder:
interlaced; loop filter; b-frames; number of threads=1

QuickTime is too slow on my computer (Athlon XP 1700+ 1.83GHz with AIW9600XT). May be it works somehow better on newer hardware, but I'm not much optimistic about that.

Personally I prefer and use this two variants:
~ JetAudio with the ffdshow-clsid-SSE codec;
~ MPlayer

Now about the deblocking, I am encodding Music Idol BG, the source is MPEG2 20Mb/s captured from TV with the AIW card.
Here are my settings:
ffdshow H.264 encoder; quality:45; cabac; interlaced; loop:alpha=-1, beta=-4;

Intra analyzer flags:I4x4; I8x8; PSUB8x8
Inter analyzer flags:I8x8l PSUB8x8
Subpixel refinement:rate-distortion optimized MB types
Motion estimation method:UMH, range:16; reference frames:1; length:64

Quantanization type:JVT; min:18; max:30.
What quantanization type and matrix do You use?

With those settings, blocks are only visible when standing in range less than 1 meter from my 15" monitor (it's pretty old, so the gamma is 1.45), but from 1.5 meters away and more the quality looks great.

[Mr VacBob]

Your settings are... weird. Why qp min 18?

Also, it's really not recommended to set the loop filter below -2. QT does support it perfectly well. For maximum speed, turn off cabac and increase max B-frames to 16. (which is safe)

[georgevalkov]

Why qp min 18?
I'm not an expert on the settings. How much should it be?
I don't think it has to be lower, the quality at quantanizer 18 is nearly lossless, the bit-rate is too high, so it will probably never fall to quantanizer <=18.

Also, it's really not recommended to set the loop filter below -2.
Why is it not recommended?
I usually encode at high quality like 56 and higher, and then I disable the loop filter. But when I need a bit more compression, I can fall to 45 with very slight de-blocking. I set the threshold beta: -3 or -4, because I don't want to loose the details.

For maximum speed, turn off cabac and increase max B-frames to 16. (which is safe)
I can afford to loose a little speed to achieve a better compression (120%) at the same quality, so the cabac option stays on!

B-frames: I made a few tests with fixed quantanizer:27.
If I enable B-frames:8 (ffdshow H264 encoder does not support more); B-frames prediction:auto, then the file will be larger (110%); encodding takes longer; decodding consumes a bit more CPU.

At fixed quality 56 using B-frames, reduced the file size (96%), but costed a little more time to encode. A few 3-4% more CPU is used for decoding.

Tell me something good about the B-frames?

[Dark Shikari]

I'm not an expert on the settings. How much should it be?
I don't think it has to be lower, the quality at quantanizer 18 is nearly lossless, the bit-rate is too high, so it will probably never fall to quantanizer <=18.Bad idea, especially if you're using an AQ build. Leave it on default.
I usually encode at high qualityLower QPs have an inherently lower loop filter strength. There is no need to lower it much further.
stuff
1) H.264 without B-frames is basically useless. Its like hiring the greatest swordsman in the land to fight for you and then cutting his arm off.

2) Why in the world are you encoding with FFDshow's VfW? H.264 does not work correctly with VfW. Use x264 directly, or an appropriately GUI like MeGUI.

[georgevalkov]

Bad idea, especially if you're using an AQ build. Leave it on default.
Lower QPs have an inherently lower loop filter strength. There is no need to lower it much further.

1) H.264 without B-frames is basically useless. Its like hiring the greatest swordsman in the land to fight for you and then cutting his arm off.
I've downloaded the latest version of x264 and also Your version - the one with AQ support, I will test it tomorrow. :thanks: Thank You for the advice!


2) Why in the world are you encoding with FFDshow's VfW? H.264 does not work correctly with VfW.
Don't be jealous :cool: I've been using FFDshow for a long time, I shouldn't mind using Your encoder, if I find it to better fit my needs :)

Yes, quite right! As far as I have read, the AVI container and VFW API does not support some of the H.264's features, and this causes problems. Example: variable frame rate and B-frames. If a source format like MPEG2 passes through VFW, there may also be incompatibility problems, especially when variable frame rate is used in the source.

In my case the source is MPEG2, interlaced, 20mb/s captured with an AIW9600XT card. It can be used in VFW tools like Virtual Dub-Mod, without any problems.
Virtual Dub cuts and decodes (fast re-compress) the source to RGB24 (it cannot decode interlaced format to YUY2 properly, so I use RGB24).
FFdshow is fed with interlaced RGB24 frames. A strong pro in FFdshow is that I can crop and use filtering, including AVISynth scripts. The output is set to RAW 264 stream, and is multiplexed with the audio after encoding. It can also be multiplexed during encoding, which allows to preview the result, without interrupting the process. Audio is decompressed to RAW and then encoded to AAC (faac.exe), then it is muxed with the RAW 264 stream in MP4 container. As far as I know there aren't any restrictions to use H.264 in it's native container. :cool:


I use the second scheme when I don't need to cut the stream (usually for DVD backup). It's faster, pure direct-show based and preserves all features if the input stream like variable frame rate. The MKV file is remuxed with the AC3 audio stream after encoding. So far I have not found any problems with neither of the schemes. The MKV container supports H.264 streams.


Use x264 directly, or an appropriately GUI like MeGUI.
Use directly... Eh, on the MPEG2 stream? that'd be too good to be possible! :)
Do You know of a version of x264 that supports interlaced YUY2 RAW input? YUV 4:2:0 and YV12 cannot be interlaced. Any way it's too long and slow path to decompress to RAW and encode after. I don't care about the disk space, there's a plenty of room for RAW video, but...
It has to be the shortest path: cut, crop 16 pixes from the right border on the fly and encode to H.264.
The audio should be decompressed to RAW frames, so that I can touch it with Sound Forge, and then encode the RAW audio to to AAC and mux with the video in MP4 container.

In what way does x264.exe offer me a faster way to reencode MPEG2 to H.264 MP4?

I have MeGUI, I'll give it a try and see if it allows me to work faster and better!

[Dark Shikari]

Use directly... Eh, on the MPEG2 stream? that'd be too good to be possible! :)
Do You know of a version of x264 that supports interlaced YUY2 RAW input? YUV 4:2:0 and YV12 cannot be interlaced. Any way it's too long and slow path to decompress to RAW and encode after. I don't care about the disk space, there's a plenty of room for RAW video, but...
It has to be the shortest path: cut, crop 16 pixes from the right border on the fly and encode to H.264.
The audio should be decompressed to RAW frames, so that I can touch it with Sound Forge, and then encode the RAW audio to to AAC and mux with the video in MP4 container.Wow, your setup is really overcomplicated.

x264 on Windows accepts Avisynth input, and MeGUI does also. There's no need to have such a mess of graphs and such!