edges, esp sharp ones look yuck compared to divx?

[createcoms]

C:\Program Files\x264\x264.exe --pass 3 --bitrate 1357 --stats ".stats" --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --weightb --filter -1,-1 --subme 6 --analyse all --8x8dct --me esa --merange 32 --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr


took about 2 weeks to encode (3 passes) and the quality is no better than a 2 day encode.

The "problem" is edges and high low contrast bits look like they've been dropped into a lower resolution (circular bits look jagged).

I did a 3 pass divx encode with max quality same bitrate, and it looks heaps better.

Am I wrong to be expecting x264 to shine? (I did try very hard to RTFM with google and here as best I could)

[Oline 61]

C:\Program Files\x264\x264.exe --pass 3 --bitrate 1357 --stats ".stats" --ref 5 --mixed-refs --bframes 2 --b-pyramid --b-rdo --weightb --bime --filter -3,-3 --subme 6 --analyse all --8x8dct --me umh --merange 16 --trellis 1 --no-fast-pskip --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr

That should be much faster and should clear up your issues. I also recommend you go with 2 passes as opposed to 3 if your computer is that slow. The quality will not suffer much.

In addition, never use "--me esa" it is an exercise in futility.
No need to use more that 5 references.
Not need for merange to be more than 16.

[createcoms]

Speed is not a real worry for me......just as long as the end result is of good quality.

[kotrtim]

2 weeks, that's a waste of time

What's the resolution of your source??

C:\Program Files\x264\x264.exe --pass 2 --bitrate 1357 --stats ".stats" --ref 3 --mixed-refs --bframes 3 --direct spatial --b-pyramid --b-rdo --bime --weightb --filter X,X --subme 6 --analyse all --8x8dct --no-fast-pskip --trellis 2 --progress --no-psnr

How about this, will be much faster

Oh, forgot about the decoder, use ffdshow and turn on postprocessing and how it corrects the jagged circle you mentioned, coz divx has postprocessing on, different postprocessing settings will also make the picture look different

[Sharktooth]

Postprocessing MUST be turned OFF!
h.264 has already inloop deblocking and doesnt need postprocessing.

[sysKin]

Jagged edges might be an overlay problem. Software resizer is simply nearest neighbour. What decoder and player are you using?

[bond]

you do know that --pass 3 doesnt mean "third pass"?
if you used --pass 2 before --pass 3 you only did a two pass encode...
but it can be questioned anyways whether 3 passes is worth the time

(also 16 reference frames is a not needed overkill imho)

[kotrtim]

Postprocessing MUST be turned OFF!
h.264 has already inloop deblocking and doesnt need postprocessing.

thanks, another new things learned today :cool:

[Sharktooth]

that's unless you deactivate inloop deblocking...

[Caroliano]

And a ME_range higher than the defaut will most likely decrease slight the quality...

Use the Sharkthoot's profiles or see this tread (http://forum.doom9.org/showthread.php?t=107699) for better choice the options in relation to speed.

[createcoms]

Oline 61,

I didn't get any tangible improvement with those settings.

kotrtim,

I simply do not care for the time aspect. Quality is the issue here.

And I did try Shartooth's profiles beforehand and all of these settings yield yucky edges.

Please at least give me a firm yes or no on this: Should x264 @ 1357 bits be better quality than divx 6 or not?

thnx!

:)

-cc

[Oline 61]

It should be much better quality. There is probably a problem in your decoder. What decoder are you using? Is there any post processing done?

[Lil' Jer]

And I did try Shartooth's profiles beforehand and all of these settings yield yucky edges.

Can you post a screenshot that shows the problem? Your vague description of "yucky" isn't much to go on.

[rushin_911]

wouldn't 16 reference frames make sense with the --mixed-refs option?

[Soulhunter]

The "problem" is edges and high low contrast bits look like they've been dropped into a lower resolution (circular bits look jagged).Looks it similar to this (http://forum.doom9.org/showpost.php?p=772467&postcount=66)?


Bye

[Caroliano]

wouldn't 16 reference frames make sense with the --mixed-refs option?
Forget that. The gain is too small, and the time too big. 5 or even less (3 or 4) references shoud be suficient for most videos.

[createcoms]

divx6:
http://suprfile.com/src/2/42mdxe/divx6.png (http://suprfile.com/get.php?id=42mdxe)

x264:

http://suprfile.com/src/2/42wxk5/x264.png (http://suprfile.com/get.php?id=42wxk5)

[Hellworm]

Looking at the images I would say they didn't use the same source. The x264 source seems to be processed by some deinterlacer ( a bad one btw).

[kotrtim]

--pass 2 --bitrate 736 --stats ".stats" --ref 3 --mixed-refs --bframes 3 --direct spatial --b-pyramid --b-rdo --bime --weightb --filter -4,-3 --subme 6 --analyse all --8x8dct --no-fast-pskip --trellis 2 --progress --no-psnr

dgindex - forced film
this is a fulll length 1 hour 44 min taxi, I'm not extracting a small portion and encode..

720x368

haha... so much faster than yours, even better...more details:D

http://img48.imageshack.us/img48/6246/20thcent3sd.th.png (http://img48.imageshack.us/my.php?image=20thcent3sd.png)

[createcoms]

Everything about the encode between those two is IDENTICAL except for the codec used......

kotrtim, if your post is supposed to be helpful I'm sorry but I've failed to appreciate it?

[nm]

Describe the complete encoding procedure step by step. The problem is most likely in preprocessing, but if you can, post a small clip of the buggy video, so someone else can test it and rule out decoding problems.

[kotrtim]

kotrtim, if your post is supposed to be helpful I'm sorry but I've failed to appreciate it?

No, I just wanna tell if I can encode a nice looking "20th century", you can too, something must be wrong, are you feeding divx and x264 the same avs script?

is your source inetrlaced, telecined?
If your source is a telecined source, don't use deinterlacer, use better implementation like decomb

[Caroliano]

This is either a problem in pre-processing (interlacing issues are the more probably) or somewere in the decoder chain. The encoder can't do something like that AFAIK. So do what nm said to narrow the problems possibilitys.

I have a problem like this while decoding my videos under Kaffeine and VLC in linux, but no problem with Mplayer in linux or VLC in windows. Simply strange.

[createcoms]

As I said both screenshots are from the same source, the only difference is codec so kotrtim yes that means the same avs framserving script.

The source is NOT interlaced.

Also playback is done on the same player, and this problem is not apparent on anything but my x264 encodes.

[foxyshadis]

Same player, but same decoder? Are they both ffdshow? If you can, turn off all deinterlacing in ffdshow (or nero or whatever's decoding it) and retry. Because the x264 version has obviously been dumb-bobbed, and if it isn't interlaced it's very confusing as to why that happened. Normal x264 video shouldn't look like that at all. If you could try to cap the same frame from both encodes (directshowsource or mpc can do it) that would be more enlightening; if they are different but come from the same source, then the decoder's playing havok with it.

[GodofaGap]

I can't be sure (since the screenshots aren't of the exact same frame) but it could also be a problem with a different video renderer (upsampling problem) used. The apparent difference in brightness between the screenshots might suggest that (although again, I can't be really sure of this, since the screenshots are not of the same frame).

[nm]

createcoms, if you can't post a sample clip, try decoding with the VLC player. That should eliminate at least some of the possible decoding problems.

[createcoms]

Bing! ffdshow is the culprit.

But it's very strange. There's two settings profiles, default which is nothing turned on and a profile for ChrisTV which has been set so it only responds to the specific program .exe

Obviously something is #(*&$(#*$ because as soon as I nuke the ChrisTV profile, our jaggies disappear! So I have tried to make the "default everything off" specifically bound to h264 decoding now (hopefully it will behave itself).


Okay now thats sorted.....I wonder if I dare ask, what is the absolute overkill on all MegaSuperIdontcarefortimeUltraHQ settings that will take a thousand years to encode ?

I would like to thank everybody that bothered to post here....my lack of patience meant I was ready to walk away from x264 (which would have been a shame!).

thnx

-cc

[foxyshadis]

If you use the latest sharktooth profiles, start with HQ-Slowest or HQ-Insane, the main difference being 2-pass vs 3-pass, and make a couple of tweaks: Change B-frame-mode to Auto, add a smidge of AQ if you have a build enabled for it, and if you're using megabitrate or tinybitrate try a matrix optimized for it. Then run the bitrate calc (which will put the bitrate into the profile) and start it up!

If you're just worried that it runs too fast, well, you can turn --me esa on, but it really won't do anything for quality.

[Caroliano]

If you're just worried that it runs too fast, well, you can turn --me esa on, but it really won't do anything for quality.
Better: If you think that it runs too fast, thanks to x264 devs that optimized it so much. :)

[createcoms]

When I try to use Sharktook HQ Insane profile I get a requester titled Fatal Error and it says:

MeGUI has encountered a fatal error and may not be able to proceed. Reason:InvalidArgument=Value of '6' is not valid for 'SelectedIndex'.

PLus a bunch of stuff below that (cant seem to copy and paste it).

[fight2win]

Everything about the encode between those two is IDENTICAL except for the codec used......

kotrtim, if your post is supposed to be helpful I'm sorry but I've failed to appreciate it?

divx 6 offers a better quality than x264 or xvid, imho, but people see it with high postprocessing, and they say it's blurred!

[ChronoCross]

divx 6 offers a better quality than x264 or xvid, imho, but people see it with high postprocessing, and they say it's blurred!

/me gives him a funny look.


Your not seriously saying divx 6 is better than H.264? I mean your kinda out of your mind by saying this. every test thus far points to x264 being superior to xvid and divx in every way.

[Sirber]

divx 6 offers a better quality than x264 or xvid, imho, but people see it with high postprocessing, and they say it's blurred!Can we even compare DIVX and x264? :confused:

[Oline 61]

I think he means that DIVX6 is better than x264 at producing video of poor quality. Therefore x264 is of higher quality than DIVX6.

[shon3i]

Basicly on very high bitrates with no using mpeg4 asp & avc technique just basic settings there is no differents for me. Offcourse that is x264 better soultion for lower rates but is much slower. Aslo H264 sharpness give sharm to H264 encoders so H264 looks better than DivX/XviD

[Sharktooth]

Well MPEG-2 is better than divx then... and huffyuv even better....:P
An encoder is made to COMPRESS as much as possible loosing less quality as possible...

[shon3i]

Well MPEG-2 is better than divx then... and huffyuv even better....:P
An encoder is made to COMPRESS as much as possible loosing less quality as possible...
Yes is true MPEG2 in high bitrates rocks but cost of space in hdd where x264 and DivX/Xvid uses less space for same quality.

[Sharktooth]

everything in high bitrate rox...

[fight2win]

everything in high bitrate rox...
exactly, my point is that divx offers a warmth to encoded video, thus giving a rather soothing and pleasing look to the human eye!If u have a good source, divx also rox if encoded properly with good bitrate! X264 and H.264 Rock, but DivX is Also Good!

[foxyshadis]

Haha, Divx should employ you as a marketroid. That's the best babble I've heard all week.

[Sirber]

exactly, my point is that divx offers a warmth to encoded video, thus giving a rather soothing and pleasing look to the human eye!If u have a good source, divx also rox if encoded properly with good bitrate! X264 and H.264 Rock, but DivX is Also Good!Do you use PP?

[Hellworm]

What's about uncompressed?
Some say it looks even better than divx! And the speed is incredible!

[bond]

uncompressed before or after you have encoded with divx? :D

[fight2win]

ok, ok, calm down ya all! x264 is great, divx is ok too!

[shon3i]

ok, ok, calm down ya all! x264 is great, divx is ok too!
and XviD

[createcoms]

<cough> MeGUI problems <cough>

:D

[xyloy]

divx 6 offers a better quality than x264 or xvid
What a fine joke! http://img156.imageshack.us/img156/7964/rofl0te.gif

Thanx for so much fun. ;-)

[foxyshadis]

Hi,

what's the auto b frame setting you speak of (is it in the MeGUI or do I add it to the commandline somehow?)?

And whats the smidgen of AQ?


thnx

-cc
On the last page of the x264 config there's a dropdown for "B frame mode", set it to auto. (command line: --direct auto) As for AQ, having retested it a lot lately, I wouldn't recommend it unless you have really severe blocking in dark or cloudy scenes, because it makes the whole video look slightly worse.

(Posting to the relevant thread, don't really prefer basic questions as PMs)

[fight2win]

What a fine joke! :D

Thanx for so much fun. ;-)

Laugh it up, Frencho.

[fight2win]

and XviD

XviD Rocks, literally brings down da house!