x264 MUCH better quality than XviD?

[ToS_Maverick]

come on, be nice to each other, we don't want to fight each other, we want to discuss in a polite manner ;)

@HDBR77: still waiting for your comment about my sample :D

[Sagittaire]

I don't think a high-quality 3CD rip of 2-2.5 hour film is useless. In such a case I get good image with less than half of standard DVD-5, instead of DVD-9 (of course, the main film is probably much less than DVD-9, but surely more than DVD-5). That's the quality I'm aiming at, so it's not useless from my POV, and I think I'm not alone (I shall tell Tegedeeck half of his presets is useless then, and alarm the MeGUI-team, that have implemented it :D). If you've got another point of view, fine with me, but don't try to play a crusader. :p
And where am I supposed to get that HDTV source from, if I may ask? Could you turn my DVDs collection into HDTV footage auto-magically? It's the first time I will write :

Well it's simply a completely useless profil for you and Tegedeeck then ...


Huh?

You can tweak ASP for change Size/quantisation scaling. With the same quantizer all the ASP don't use the same size. DivX for example use a higher size with the same quantizer.


REALLY? :D

I make the encoding for the "DivX CD test V2"
http://www.divxtest.com/sommaire.php3?lang=en

Scan the result if you want (more than 200 SAP tested)


No, thank you. I used to encode with DivX 3 for many years, and I'm not going back, nor pump my bitrate into empty void.

Well DivX3 is always developped with libavcodec. You can't compare DivX3 from libavcodec and DivX SBC with NanDub.


You've recommended it[/b] along with full command line:

1) I use my matrix for blocking problem with low inloop strenght, not for better Grain Retention.
2) My matrix is really flat matrix.
3) Grain Retention is not a CQM problem for H264. Flat16 is really good for that. Partitions, inloop, Pel Search and other internal tweak are really more important for Grain Retention.

[*.mp4 guy]

1) I use my matrix for blocking problem with low inloop strenght, not for better Grain Retention.
2) My matrix is really flat matrix.
3) Grain Retention is not a CQM problem for H264. Partitions, inloop, Pel Search and other internal tweak are really more important for Grain Retention.

1: -2:-2 is not "low inloop strength", infact when using a given crf -2:-2 usually gives lower filesizes then higher settings...

2: If its flat you would have just used the standard one, afterall its flat too and will always have better metrics then your matrix

3: I used 4x4 partitions without any problems in my encodes, you used rdo 7, the highest pel search in your encode, so thats not a problem, inloop isn't the problem, -2:-2 is just the most efficient setting for it, in spite of psnr it works better for the codec bit for bit then higher settings. You didn't tweak deadzone, or any other "internal" settings, you used trellis instead, so internal tweaking was not necessary for your sample, which indeed had good grain retention, but misteriously did not use the standard matrix despite your pontifications.

All of the encodes that used the standard matrix that I have seen in this thread had horribly poor grain retention, ToS_Mavericks encode looked ok, but it definately didn't keep much grain.

Sagittaire please stop acting as though your opinion is law, It doesn't bother me that you think all matrices are usless crap (though you are somewhat hypocritical in this), what bothers me is that you consistently try to silence people with different views, often with no actual proof that what you are saying is true. You usually end up twisting the facts to try and make your point, why bother just let people make up there own minds from the clearly available information, if you are right then people will naturally come to conclude so, if you lay out the facts clearly..

[foxyshadis]

Well DivX3 is always developped with libavcodec. You can't compare DivX3 from libavcodec and DivX SBC with NanDub.

In that case just call it MPEG-4 SP then, since it's barely related to DivX3 in any other way.

[HeadBangeR77]

@ Sagittaire:
I couldn't express myself better than mp4 guy did at the end of his last post (thank you). I'm not gonna point out all the mess you've made so far (like e.g. with the recommendation to use your matrix, while you denied that, or playing silence-of-the-lambs with many of my questions, or denying the sense of half of XivD's presets), but I will simply ignore your posts in the future. (...) Revealed-truth isn't a proper manner to discuss things these days, imo.

@ ToS_Maverick. Inventive Software:
It's so late I will surely kick the bucket soon. I've got all your samples, and I'm gonna have a closer look at them this week, though I don't know when exactly. I will try to remain objective, if it's possible. I have never tried to suggest that "XviD is better than x264" (sounds childish to me ;)) - all I ever wanted /tried to prove /examine /discuss is the idea it isn't so much worse for certain uses, though it's technologically less advanced, and it might look better to some people at high bitrates. Thanks for cooperation and excuse my harsh words, if spoken (I can't recall at this hour).

cheers,
HDBR77

[Manao]

1: -2:-2 is not "low inloop strength", infact when using a given crf -2:-2 usually gives lower filesizes then higher settings...In what way giving a lower file size at a given crf implies that the strength is low ? The strength of the deblocking can't be judged that way. Just for information, here's how deblocking behave at a fixed quantizer : Quantizer | Force | Size | PSNR
-----------------------------------
18 | 0 | 5011 | 45.927
18 | -6 | 5076 | 45.896
18 | 3 | 4941 | 45.779
18 | 6 | 5021 | 44.814
-----------------------------------
26 | 0 | 1817 | 41.089
26 | -6 | 1869 | 40.793
26 | 3 | 1797 | 41.002
26 | 6 | 1889 | 40.286
-----------------------------------
34 | 0 | 648 | 36.509
34 | -6 | 685 | 36.187
34 | 3 | 645 | 36.369
34 | 6 | 667 | 36.007

[aabxx]

There's a MeGUI profile called "CQ-ASP_Q2_equiv":

--qp 18 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "" ""


I'm wondering, is this setting usually supposed to give a substantially smaller size than xvid @ q2 default settings or is it supposed to give same-ish bitrate?

I ask because with the above settings xvid gives me smaller sizes on my vhs material, which sort of seems strange to me as the generally more efficient encoder's q2 equivilant surely should produce smaller file sizes than xvid Q2 default on most material, right? Well that's what I would've thought anyway.

Leading me to speculate in that MAYBE xvid is more efficient with a large subset of vhs material? This is only SPECULATION untill someone can confirm that indeed, CQ-ASP_Q2_equiv does generally give smaller filesizes than xvid @ q2 default. For all I know, CQ-ASP_Q2_equiv generally gives larger file sizes so of course there is no reason for me to pursue more testing on this untill someone can give me more input.

[check]

they are not intended to be in any way similar apart from the quality of the output file. x264 q18 == xvid q2

[aabxx]

they are not intended to be in any way similar apart from the quality of the output file. x264 q18 == xvid q2


Yes, but if x264 at q18 looking same-ish as xvid q2 produces higher bitrates than the latter, would not that indicate that xvid is more efficient on that particular material?

[westgroveg]

x264 MUCH better quality than XviD?
Yes. Try a 700MB encode of a 2+ hour movie & find out.

[DarkZell666]

Yes. Try a 700MB encode of a 2+ hour movie & find out.

This is exactly the sort of silly answer you would have refrained from posting if you had read the thread completely ... cheers.

[westgroveg]

This is exactly the sort of silly answer you would have refrained from posting if you had read the thread completely ... cheers.
It's not "silly" it's the truth.

[DarkZell666]

Man, did you actually read the thread ? There isn't only encoding 2 hour movies onto 700MB in the "encoding practice", and even if x264 is very good at that, it isn't always that good in other situations (which have been extensively studied in the thread).

We've actually found it was much easier to get something transparent out of XviD than out of x264 (and faster too).

[R3Z]

It's not "silly" it's the truth.

Well at least you didnt say "best" :p

[DarkZell666]

Well at least you didnt say "best" :p
I must say, I did burst out laughing reading this :D

[check]

Yes, but if x264 at q18 looking same-ish as xvid q2 produces higher bitrates than the latter, would not that indicate that xvid is more efficient on that particular material?

No, but it does indicate that using those particular settings, xvid is better.

[aabxx]

Well I've been trying out xvid at q2 mpeg plus a few more settings adjustments to make it more optimal (configuring xvid is not exactly hocus pocus) and x264 at various settings at both crf 18 and qp 18 (this is more hocus pocus at this point).

The material is 768x576 80s homevideos (always shaking :D) on VHS.

The idea was that I was sending my friend a clip and he wanted it in "pristine" quality. However when I told him xvid at Q2 with good settings would turn out 8-9 mbps (which I knew from many past experiences), he was surprised to hear they were so big so he suggested me trying out CQ-ASP_Q2_equiv to save some space. And they typically turned out between 9-11 mbps in my tests to mine and his surprise.

This testing was primarily non-interlaced encoding (the samples were interlaced and not resized/filtered further) but interlaced encoding showed approximately the same ratios but I did not do much of those because x264 interlaced does not playback properly here for some reason neither through ffdshow or VLC.

I'm using the newest stable xvid (1.1.2 or whatever) and x264 core:54 svn-634. I might add too that with most settings I tried x264 is MUCH slower than xvid, even though x264 is running multithreaded while my version of xvid is not. I have not tested x264 on quicker settings as I believe that would make the quality or the file size suffer more.

This was by no means any exhaustive test. I post this because I only encode VHS most of the time, and if my current findings hold any value (I'll have to do more testing), the mantra of "generally x264 is superior to xvid" does not mean much to me if it turns out that x264 is not better on 95% of the material.

I would be very interested if someone else has compared xvid to x264 with non-pristine VHS. Especially if they found some settings where x264 is better than xvid.

Next I will try some comparisons on DV-material. DV-material is usually much easier to compress than my VHS-material so I suppose maybe x264 will win there. We'll see.

[*.mp4 guy]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original, then try using a cqm in x264 that compresses high frequencies more aggressively (this may or may not help, and is highly source dependant), If you can't get X264 to outperform Xvid (make sure to try Xvid on the downsized encode aswell) you have probably found a source that X264 is bad at, comparatively speaking.

[aabxx]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original, then try using a cqm in x264 that compresses high frequencies more aggressively (this may or may not help, and is highly source dependant),

It looks slightly better when it's not resized. I know I pay a high premium in file size to keep it at a high resolution but buying big hard drives has almost become a hobby of mine and I have almost a dozen of them by now :)

If you can't get X264 to outperform Xvid (make sure to try Xvid on the downsized encode aswell) you have probably found a source that X264 is bad at, comparatively speaking.

Yes, but this is a big thing in my book when we're comparing x264 versus xvid, as the test samples I use I believe are representative for most of my family videos from the 80s. It would not be unreasonable to suggest that the situation will be the same with tons of family videos from the 80 and at least early 90s. Comparisons here on doom9 tend overwhelmingly to be on film material and sometime tv show caps. I suspect there has been little testing done publically here on old family videos. Unfortunately I'm not a good tester but I'm just coming with some suggestions that might interest someone.

I reckon that when the bitrates are "insanely" high, as they always are with most of my vhs material, the advanced techniques of x264 does not help and therefore xvid becomes equal or perhaps even better.

Having said all that, I'm no x264 expert so I don't find myself suitable to come to any real conclusions. I merely suggest new venues for comparison because my results at least indicate to me, that when it comes to old vidoes, x264 might not be superior.

Oh btw, I've done some testing on my DV material (which is only DV-material originating from MY camera) and x264 seems more efficient than xvid there. But DV from my camera is MUCH more compressible than my old VHS tapes.

[squid808]

No, the HCT vs DCT isn't a big problem. It really doesn't matter which exact set of approximations you use as long as the encoder and decoder agree. If the encoder and decoder use different approximations, then the low quality is due to the difference between them, not due to the difference from the ideal DCT.

By quantization, I mean given a quantized coefficient and the step size, how do you compute the dequantized coefficient. h264 uses level*qscale. ASP (both h263 and mpeg) uses level*qscale+qadd, with different values of qadd. (qadd is 0 for mpeg intra, but non-0 for h263 intra and both inter).


Xvid ME uses SAD (and then may refine with RD, depending on the setting of vhq).

Has adaptive updating of the quantization offset as described in the paper at http://adsabs.harvard.edu/abs/2005SPIE.5960.1041S been tested in x264? Seems like a candidate for grain retention at very high bitrates.

[akupenguin]

Adaptive deadzone is a half-assed version of trellis. Mine is optimal, theirs is just pretty close.

[weaver4]

I have not read every post in this thread so I will probably be "blasted". Has anyone seen this site that compares MOS scores for X264, DivX, and XviD. Any comments?

http://www.compression.ru/video/codec_comparison/subjective_codecs_comparison_en.html

Something looks "fishy" between the results of XviD and DivX.

What I tell my friends is that "XviD/DivX is just as good as X264 when you set the bitrate/filesize 20% higher". Based on these MOS scores it appears that my statement is mostly accurate.

[steve77]

Since I'm the orginal poster, I guess I should slip in another word. First, thanks to all of you who took the time to do the necessary tests and analyse (mostly objectively :p ) your findings.

I myself am mostly interested in lower bitrate encodes (1500kbps max, resolutions up to 768x432 for low motion, low noise encodes)... Though I haven't done extensive testing as you fine folks have done, to my eyes I find x264 is best with high motion scenes (w/ relatively high compression): often in the past I've used XviD and found some motion to become somewhat blocky for highish quantizer values.

Then again, I go all out with my x264 encodes: 5 reference frames, RDO level 2, Exaustive ME... yes I know many people discourage RDO level 2, and the "exaustive" Motion Estimation settings. I manage 8-10fps on my encodes with all the bells and whistles.

Question: Is it wise to use the "all" marcroblocks option? (Comaptibility set asside?) I always do.

Anyway, I think that both codecs are the very best of their kind, but can't help but think that h.264 is the "next big thing" in video distribution.

[bananacreamandpeca]

Basically how it pans out is that If you are encoding in a situation where artefacts will be unavoidable X264 is better becuase its artefacts are less annoying, and overall there are less of them. In any other situation (archiving, transparent format shifting, refiltering etc.) X264 is inferior to Xvid becuase it is much harder to get transparent results with X264 then Xvid, on some sources it is completely impossible to get transparent results with X264 unless you use lossless or neer lossless bitrates.

Im still getting x264-video with lots of macroblocks in places where you see lots of smoke or dust.
Like in scenes where there are explosions or debree falling from ceilings and stuff.

Personaly I think x264 gets its higher cmpression advantage due to lots of pre-filtering (?)
And I'm still hovering over what to use in wich situation.
Xvid gives good results, even when transcoding. I always use autogk for that myself.
Dunno why, autogk just gives good results when transcoding.
x264 is painfully slow and has lots of weird options, unless you can cluster computers to do a faster job.
(anybody clustering pc's for video edting?)
MKV is, well, pretty weird. I suggest you do encodes, than copy them mkv's to clean harddrive space
before play. Or else you might notice very long seeking and starting lag.

[imcold]

MKV is, well, pretty weird. I suggest you do encodes, than copy them mkv's to clean harddrive space
before play. Or else you might notice very long seeking and starting lag.

Remux the file.

[ToS_Maverick]

i got a hint from this thread (http://forum.doom9.org/showthread.php?t=125010) where a Dr.Khron had problems with his simpsons episodes. his screenshots, where he compared different AQ settings, made me try AQ on the black pearl sample... i have to say, i'm really suprised, it looks great! i'll post some screens in the next days, i wanted to post the settings, if anyone is interested in trying them out ;)


--crf 20.0 --deadzone-inter 9 --deadzone-intra 6 --ref 3 --no-fast-pskip --bframes 2 --weightb --filter -2,-2 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2

[Dr.Khron]

Try playing with the "sensitivty" option, too. I found that 1.2 + caused artifacts, and so far I've been happiest with 0.6 & 10 (although bear in mind I'm encoding animated content, so 10 might be way too low).

[ToS_Maverick]

i found some time to test a bit, and got these settings for you guys. to give you a heads-up: i managed to get an even better quality than the last time i posted this (http://forum.doom9.org/showthread.php?p=956242#post956242), but with increased file-sizes!
screens will come if i have some time again ;)

@Dr.Khron: thx for the tip, sensitivity 10 works fine, but i had to crank up the strength to 1.2 to give satisfactory results for this file :D

"transparent" line, 52 MB:

--crf 22.0 --deadzone-inter 9 --deadzone-intra 6 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2 --aq-sensitivity 10


balanced line, good compression, good quality, quite slower, 32.2 MB:

--crf 20.0 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs" --aq-strength 1.2 --aq-sensitivity 10

with crf 18, this line will give you better quality @ 42.9 MB

[akupenguin]

"transparent" line, 52 MB:
wtf? multiple reference frames and bime with subme=1?

[ToS_Maverick]

hell jeah :D

ok subme=1 is a bit extreme, i know, but at higher settings, subme is eating up all the grain, at least for this sample.

the first line was an attempt to get real good quality, and to keep most of the grain.
the second line is more suited for the common encoding ;)

[ToS_Maverick]

ok, as promised here are some screens :D

the sample was coded in 720x304. i resized the images, to give you a closer look.

from left to right:
Original, CRF20 with AQ, CRF20 with AQ and subme=1, CRF18 without AQ

http://img251.imageshack.us/img251/7133/101origsmallis5.th.png (http://img251.imageshack.us/my.php?image=101origsmallis5.png) http://img251.imageshack.us/img251/7895/101aqsmallgo1.th.png (http://img251.imageshack.us/my.php?image=101aqsmallgo1.png) http://img251.imageshack.us/img251/4163/101aqsub1smalley7.th.png (http://img251.imageshack.us/my.php?image=101aqsub1smalley7.png) http://img251.imageshack.us/img251/185/101noaqsmallyi4.th.png (http://img251.imageshack.us/my.php?image=101noaqsmallyi4.png)

http://img108.imageshack.us/img108/5862/300origsmallsw6.th.png (http://img108.imageshack.us/my.php?image=300origsmallsw6.png) http://img122.imageshack.us/img122/1142/300aqsmallzg8.th.png (http://img122.imageshack.us/my.php?image=300aqsmallzg8.png) http://img122.imageshack.us/img122/664/300aqsub1smallda5.th.png (http://img122.imageshack.us/my.php?image=300aqsub1smallda5.png) http://img108.imageshack.us/img108/4540/300noaqsmalllq0.th.png (http://img108.imageshack.us/my.php?image=300noaqsmalllq0.png)

http://img78.imageshack.us/img78/8987/815origsmallwe1.th.png (http://img78.imageshack.us/my.php?image=815origsmallwe1.png) http://img163.imageshack.us/img163/7523/815aqsmalljr0.th.png (http://img163.imageshack.us/my.php?image=815aqsmalljr0.png) http://img163.imageshack.us/img163/6979/815aqsub1smallei6.th.png (http://img163.imageshack.us/my.php?image=815aqsub1smallei6.png) http://img163.imageshack.us/img163/9257/815noaqsmallcs7.th.png (http://img163.imageshack.us/my.php?image=815noaqsmallcs7.png)

for the record, here again my commandlines:

CRF 20, AQ
--crf 20.0 --aq-strength 1.2 --aq-sensitivity 10 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

CRF 20, AQ, subme=1
--crf 20.0 --aq-strength 1.2 --aq-sensitivity 10 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 1 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

CRF 18, no AQ
--crf 18.0 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i8x8 --8x8dct --vbv-maxrate 25000 --threads auto --thread-input --progress --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim --output "F:\Video\Black.Pearl.Sample.mp4" "F:\Video\Black.Pearl.Sample.avs"

[*.mp4 guy]

After looking at those samples, it looks like I will have to give AQ a second look, But I don't think subme 1 is helping with grain retention. I also think, that until X264 goes through some major changes, this topic had been examined about as completly as it can be.

[Sagittaire]

After looking at those samples, it looks like I will have to give AQ a second look, But I don't think subme 1 is helping with grain retention. I also think, that until X264 goes through some major changes, this topic had been examined about as completly as it can be.

Why major change ... ???
There are special functionality in H264 standard for Grain Retention at low bitrate: Film Grain Modeling.

[ToS_Maverick]

@*.mp4 guy
what things do think have to be changed?

i think including the aq-patch, and choosing a "sane" default value for it would be cool. or some other thing, to get rid of these ugly blocks, in the 2nd series of my screens.

[*.mp4 guy]

Why major change ... ???
There are special functionality in H264 standard for Grain Retention at low bitrate: Film Grain Modeling.
I would consider the addition of FGM in X264 a major change.

@*.mp4 guy
what things do think have to be changed?
I wasn't trying to say that things have to be changed.

[winkgood]

I know this is slightly offtopic since the thread originally compared XVid to x264 but here's my story.

I've been playing around with different encodings for Van Helsing HD-DVD. My original encoding was in virtual dub using DivX 6.6?(I think) codec (using the pro codec) with single pass coding on 'better' quality in 720p using 7500 bitrate for the video.

My second encoding was using MeGui with x264 codec with two passes in 720p and 8000 bitrate. Here's the log file for my x264 encoding:

*****

Looking for job processor for job...
Processor found!
Starting job job1-1 at 10:52:04 PM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 1 --bitrate 8000 --stats "V:\Van Helsing\VideoSync.stats" --level 4.1 --keyint 15 --min-keyint 1 --bframes 2 --b-pyramid --direct auto --filter -3,-2 --subme 1 --analyse none --vbv-bufsize 9781 --vbv-maxrate 29400 --me dia --threads 2 --thread-input --progress --no-psnr --no-ssim --output NUL "V:\Van Helsing\VideoSync.avs"
successfully started encoding
Processing ended at 2:32:42 AM
----------------------------------------------------------------------------------------------------------

Log for job job1-1

avis [info]: 1280x720 @ 23.98 fps (189337 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:16105 Avg QP:14.67 size: 98792
x264 [info]: slice P:99163 Avg QP:16.87 size: 47343
x264 [info]: slice B:74069 Avg QP:18.18 size: 20990
x264 [info]: mb I I16..4: 29.9% 0.0% 70.1%
x264 [info]: mb P I16..4: 31.0% 0.0% 0.0% P16..4: 56.5% 0.0% 0.0% 0.0% 0.0% skip:12.4%
x264 [info]: mb B I16..4: 4.0% 0.0% 0.0% B16..8: 31.7% 0.0% 0.0% direct:30.3% skip:34.0%
x264 [info]: final ratefactor: 17.19
x264 [info]: direct mvs spatial:94.6% temporal:5.4%
x264 [info]: kb/s:7942.7

encoded 189337 frames, 14.31 fps, 7943.33 kb/s

-------------------

Starting postprocessing of job...
Job completed successfully and deletion of intermediate files is activated
Postprocessing finished!
Looking for job processor for job...
Processor found!
Starting job job1-2 at 2:32:42 AM
Starting preprocessing of job...
Preprocessing finished!
encoder commandline:
--pass 2 --bitrate 8000 --stats "V:\Van Helsing\VideoSync.stats" --level 4.1 --keyint 15 --min-keyint 1 --ref 3 --mixed-refs --bframes 2 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,-2 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 9781 --vbv-maxrate 29400 --me umh --threads 2 --thread-input --progress --no-psnr --no-ssim --output "V:\Van Helsing\VideoSync.mkv" "V:\Van Helsing\VideoSync.avs"
successfully started encoding

Log for job job1-2

avis [info]: 1280x720 @ 23.98 fps (189337 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 SSSE3
x264 [info]: slice I:16105 Avg QP:14.81 size: 91949
x264 [info]: slice P:99163 Avg QP:16.13 size: 48936
x264 [info]: slice B:74069 Avg QP:17.37 size: 21105
x264 [info]: mb I I16..4: 20.8% 58.3% 20.9%
x264 [info]: mb P I16..4: 8.8% 25.6% 5.4% P16..4: 26.1% 16.2% 6.6% 0.0% 0.0% skip:11.3%
x264 [info]: mb B I16..4: 1.4% 3.3% 0.8% B16..8: 35.0% 2.8% 6.6% direct: 8.4% skip:41.8%
x264 [info]: 8x8 transform intra:62.3% inter:60.1%
x264 [info]: direct mvs spatial:82.5% temporal:17.5%
x264 [info]: ref P 71.9% 19.5% 8.6%
x264 [info]: ref B 78.8% 17.0% 4.2%
x264 [info]: kb/s:7999.8

encoded 189337 frames, 4.06 fps, 8000.39 kb/s
desired video bitrate of this job: 8000 kbit/s - obtained video bitrate (approximate): 8002 kbit/s





*****

With both of them I used AC3 Audio. However, the x264 took probably 14 hours to encode while the DivX one took only about 3-4 hours. I think the second pass was going at around 4 fps.

The point I'm getting at though is that I showed both video clips to a group of my friends to get their opinion on quality. None of them could really notice much of a difference although some said that one looked better and some said that the other did. This was done on a 37" 720p TV. So am I doing something incredible wrong in my x264 encoding or is there really just not much of a difference in the two at this high bitrate? If there isn't a significant difference, then I'd be better off going with divX as it would save me a lot of encoding time.

[Manao]

So am I doing something incredible wrong in my x264 encodingNo, but you're comparing two codecs at a bitrate at which you can't tell them apart, because the quality is "too good" for your eyes.
If there isn't a significant difference, then I'd be better off going with divX as it would save me a lot of encoding time.Not necessarily. You should be able to target 6000 or even 5000 kbit/sec with x264 and still have the same visual quality as DivX.

[foxyshadis]

Average q16 indicates that it's probably well above the threshold of transparency. (Which is normally q18-22 for most people.) The divx is probably q3 or 4 average, also generally transparent to the less-demanding (with the mpeg matrix). You might have to do side-by-side comparisons to find obvious differences, obviously very difficult from a DVD player, or freeze-frame at major action scenes.

You should look at constant quality mode (at 18 or so) for x264 to save time, probably almost a quarter of the encode time, and make it a bit smaller.

Overall you probably have reached the point where perceptually, either codec does roughly equally. (Especially if you denoised at all, which reduces bitrate requirements significantly.) If you don't care how large they are, and can't tell the difference in normal viewing, it'd probably be better to use divx and save the extra time. The only thing x264 could give you is smaller files.

[Sagittaire]

1) 8000 Kbps for 1280*544 resolution movie is a high quality compression. A this bitrate MPEG2 will make high quality, certainely "transparent" for your eyes and certainely with better speed than x264 or XviD.

2) DivX q3 - q4 encoding make generaly something like 3000-4000 Kbps for 720p with medium complexity source. In your case DivX use certainely something like average q2 or less.

3) Use 8 Mbps 1080p is a very better way for your encoding.

4) Your profil is a HDDVD profil encoding. This profil use 0.606 sec GOP. With this short GOP you must change the ratio quantizer between I and P (something like --ipratio 1.10). If you don't want use HDDVD profil (mean multiplexing in HDDVD project) you must use higher GOP lenght, the efficiency will be really better with large GOP.

[infoeater]

VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original (...)

This is not true, VHS have full vertically resolution of PAL B/G/D/K/I (576 lines) or NTSC, and is losing details only horizontally. More about it: http://forum.doom9.org/showthread.php?p=188998#post188998 (and in whole topic).

[*.mp4 guy]

480->384 corresponds to a kel factor of 0.8, which is extremely optimisitic for a vhs sampling system. Also, this thread is quite old, why did you raise it from the dead?

[infoeater]

Yes, you would keep at 480x384 most of horizontal details, but would lose some vertical, because vertical resolution of NTSC VHS is "digital" 480 lines, unless some blurring has been add.

I resurrected this thread, because I had to do so, to write in it something new. Large part of my knowledge about video encoding from years come from reading threads, even very old, from doom9.org forum. I thing many other people too, so it's important to maintain quality of this important source of information.

Also if I am wrong and/or understand something incorrectly from this topic, or topic to which I linked to, I can have hope, then somebody will explain it to my, and other people with similar mind to my, which may read this thread in future.

Finally lots of forums nowadays have in they rules not to resurrect dead threads, or to do it only in very important cases. This doesn’t, so I thought, that somebody intentionally didn't write such term, maybe thinking same as me.

[*.mp4 guy]

I have captured quite a few vhs tapes, and I can assure you none of them have usefull information above 384 lines. It is because of a combination of factors, two of the major culprits are interlacing and associated filtering, and the kel factor of the sensors used (more relevant for older vhs, before dvd was released). Newer Svhs releases (most modern vhs are actually svhs, which is backwards compatible with vhs) may have resolution above 384 vertical pixels, but only if they were created from a high quality dvd master.

long story short, just because a standard, such as vhs has 480 discrete pixels of vertical resolution, does not mean that they will actually contain information. Due to poor quality mastering, interlacing, and luma-chroma cross talk (dot crawl) it is extremely dificult to get even half of the theoretical vertical resolution on a vhs to yeild any usefull information.

Interlacing and and inadequate tbc alone can leave you with between 120 and 240 vertical resolution. Add in poor mastering (many dvd's struggle to reach 384 vertical resolution, and being a digital format they could easily have 440+, if mastered correctly) and 384 is pretty much impossible. Then, dotcrawl compounds the problem, in order to completely eliminate dotcrawl, more then 2/3rds of the frequency resolution, horizontal and vertical must be lowpassed; most modern systems, use a digital notch, or comb filter instead of a lowpass filter which can recover most of the resolution, while eliminating most of the dotcrawl, but there are still significant losses.

So theoretically, with a perfect master, perfect ivtc/deinterlacing, and perfect luma chroma separation, you could get 480 vertical pixels of resolution out of a vhs. However, perfect masters are nonexistent, even on dvd's, and still very rare on blu-ray, perfect ivtc/deinterlacing is an np-hard problem with no known solution, as is luma/chroma separation. Even if all of these step are done with very high (but not perfect) quality, 384 pixels of vertical resolution is an extemely unlikely benchmark to reach.

[weaver4]

I might as well throw in my results here.

I did 12 movies with DivX(6.8) Q=4, Width of 640. I found the quality of these moves to be very-good to me. I went back and tried to duplicate the "very-good" rating "for me" with x264 and found that a crf=21 or crf=22 was appropriate using StaxRip. I don't really know what all x264 parameters that Stax uses, but I assume he knows what he is doing. I found that the x264 filesizes were on average 24% smaller.

So my conclusion is: For "good-quality" movies the filesizes are approx 24% smaller with x264....but DivX movies are much more portable across hardware devices.

[Wilbert]

Originally Posted by *.mp4 guy View Post
VHS has so few high frequencies (especially at your high capture resolution) that you have to aproach compressing it differently then other material. First resize to 480*384, which should keep all of the detail in the original (...)
infoeater is right. The kell factor has nothing to do with the amount of vertical detail. It's about the perceived vertical resolution (and not with respect to pixels, but with respect to the analog signal):

"how much of the detail in an analogue signal can you actually discern with the human eye when played back on a TV screen (Which includes Kell).
This only comes into play when you are watching it afterwards, and depends on the player and TV/screen/beamer/??? used."
source: http://forum.doom9.org/showthread.php?p=415817#post415817

long story short, just because a standard, such as vhs has 480 discrete pixels of vertical resolution, does not mean that they will actually contain information. Due to poor quality mastering, interlacing, and luma-chroma cross talk (dot crawl) it is extremely dificult to get even half of the theoretical vertical resolution on a vhs to yeild any usefull information.

Luma-chroma cross talk has nothing to do with the vertical resolution, but has an impact on the horizontal resolution. Also, interlacing isn't "destroyed" by recording a pal/ntsc signal on your vcr, so it has no impact on the vertical resolution either.

Xesdeeni gave a nice explanation here: http://forum.doom9.org/showthread.php?p=184675#post184675

[*.mp4 guy]

interlacing will cause aliasing "jitter" if the image isn't vertically lowpassed, thats one way it negatively impacts resolution(most interlaced signals are vertically lowpassed at some point). The second way, is that, for films, at some point you have to undo the 3:2 pattern, with vhs this is much harder because of line jitter, and some fairly horrible results may be had (second way interlacing impacts resolution).

The kell factor is affected by the relationship between the scanning device (camera) and display device (television). If you are using a camera with only 720*480 pixels, you will only get aproximately 504*336 useful pixels for a tube camera, and 648*432 for a ccd. I assume most vhs were captured with fairly poor equipment, and so this becomes a factor.

Luma-chroma cross talk, alright, I made a mistake here, it can be removed by lowpassing either the horizontal or vertical axes to a bit less then 1/3rd the original frequency resolution. High quality comb filters usually use a combination of vertical, horizontal and temporal combinations, to cancel out the phase differences of neighboring pixels, this does affect vertical resolution.

You will note that I didn't say vhs has a resolution of 352*240, because it doesn't. 512*384, on the other hand, is more then adequate.

I have to admit, that it is theoretically possible for a vhs to have 480 vertical pixels of resolution, and that there isn't any reason it can't happen, it just doesn't.

[Wilbert]

interlacing will cause aliasing "jitter" if the image isn't vertically lowpassed, thats one way it negatively impacts resolution(most interlaced signals are vertically lowpassed at some point).
Do you think that a vcr does that?

The kell factor is affected by the relationship between the scanning device (camera) and display device (television). If you are using a camera with only 720*480 pixels, you will only get aproximately 504*336 useful pixels for a tube camera, and 648*432 for a ccd. I assume most vhs were captured with fairly poor equipment, and so this becomes a factor.
Ok, but this is not a problem of your vcr. If you cap from tv show you won't have that problem. In the thread that i linked, i4004 made a test dvd with alternating black and white lines. Recording it to your vcr and capping with a capture guide, retains that alternating black and white line image.

[*.mp4 guy]

1-Do you think that a vcr does that?


2-Ok, but this is not a problem of your vcr. If you cap from tv show you won't have that problem. In the thread that i linked, i4004 made a test dvd with alternating black and white lines. Recording it to your vcr and capping with a capture guide, retains that alternating black and white line image.

1. no, it is a problem with the master sources, a very prevalent problem, even amound dvds. Keep in mind my points are from the perspective of capturing studio releases and family films from vhs, and both sources are going to have sub-par vertical resolution, for reasons I have already outlined.

2 That was a thought experiment. It also handily avoids the comb filter issue. Give me a real world example where you can manage that with alternating green and magenta hued bars, in the same orientation as the luminance lines, at the maximum color frequency resolution, overlaid with alternating lines of 64 and 191 intensity (so the hue is visible), and I will acknowledge the point.

[Wilbert]

1. no, it is a problem with the master sources, a very prevalent problem, even amound dvds. Keep in mind my points are from the perspective of capturing studio releases and family films from vhs, and both sources are going to have sub-par vertical resolution, for reasons I have already outlined.
A few posts back you were talking about the vertical resolution that a vhs could retain. Of course if the source is crap, the output will be crap too.

2 That was a thought experiment. It also handily avoids the comb filter issue. Give me a real world example where you can manage that with alternating green and magenta hued bars, in the same orientation as the luminance lines, at the maximum color frequency resolution, overlaid with alternating lines of 64 and 191 intensity (so the hue is visible), and I will acknowledge the point.
That's an interesting experiment! I don't have my pc connected to my tv/vcr anymore, so unfortunately i can't do it myself. I will ask i4004 to do this.

[Inventive Software]

Why was this thread gravedigged? It's been dead a year and a half...