x264 vs xvid while source DVD

[gurabli]

Hi!

first of all, sorry if this has been already discussed, but I couldn't find the answer. Few days ago I got my first HD TV and now I'm looking to replace my old XviD collection with the new HD content where available. But there are still some movies that are not BR or HDDVD published.

My question is, is a very good quality rip from the same DVD source using x264 far better than the one in xvid?
Is the x264 (in mkv) near DVD9 quality at DVD5 size or DVD9 to DVD5 is still better?

For example: a have serial encoded from DVD9 to xvid. I can get the same serial encoded from the same DVD9 source but using x264. Is it worth or not?

Thank you in forward to clearing me this up!

Respect,
gurabli

[Chengbin]

It is WAYYYYYY overkill to encode a movie with x264 with a file size of DVD5. DVD5 is equivalent to aruond 5000Kbps depending on the length. x264 can reach transparency at around 2500Kbps.

[gurabli]

It is WAYYYYYY overkill to encode a movie with x264 with a file size of DVD5. DVD5 is equivalent to aruond 5000Kbps depending on the length. x264 can reach transparency at around 2500Kbps.

OK, I put it wrong.
Not the x264 file size tha matter, but the quality compared to xvid, when using the same DVD9 source. Great improvement or only at HD source?

[LoRd_MuldeR]

Note that you can have any quality with any encoder/format! Even the most crappy encoder/format gives excellent quality, if you only raise the bitrate enough ;)

So the question is not: What quality can we get? The real question is: How much bitrate do we need to spend in order to retain a certain level of quality?

And the answer is: x264 will require far less bitrate for the same quality in any possible situation, compared to Xvid.

For example: If you raise the bitrate enough that even Xvid will give "transparent" quality, then x264 can't look any better at that bitrate (because transparent is transparent).

But in that case you could have the same level of quality at a much lower bitrate by using x264 instead of Xvid.

In other words: x264 doesn't inherently deliver "better" quality than Xvid, but with x264 you will always get more "quality per bit" - no matter what your source is!

Of course Xvid could give perfect quality even for HD sources, but you probably wouldn't like the bitrates that would be required for that...

[Trahald]

x264 (h264 specifically) should be better , on paper, at pretty much any size/bitrate. Having said that, beauty is in the eye of the beholder. you should really do a few encodes and see which one you like the best.

[gurabli]

Thanx for replies!

I know that quality is a very subjective variable to talk about...

What I really ment, was to find out, do I gain anything from the x264 encoded DVDrip compared to the same xvid encoded version I already own.

Yes, I will do a few encodes from the same source using xvid and x264 and see the results.

One more question: for years I have preffered 1.4GB encodes using xvid for a medium long movie with AC3 sound. What is the "standard" filesize for x264 that can be compared to 1.4GB XviD encodes?

Sorry, even more questions: for DVD9 source encode should I use the Standalone Blue-ray or HD-DVD profile in MeGui, or some other, if the highest quality with reasonable size is wanted?

[LoRd_MuldeR]

What I really ment, was to find out, do I gain anything from the x264 encoded DVDrip compared to the same xvid encoded version I already own.

Of course not! Re-encoding is inherently lossy! Converting the Xvid encode movie, which had already been encoded from the original DVD source, with x264 adds one additional encoding step. Hence re-encoding the movie again, will only add additional loss (hurt quality), but it can never improve quality. Once detail is lost, it cannot be re-added magically, even by the "best" encoder in the world. That's because the encoder only knows the already encoded (lossy!) version you feed into it. It cannot know how the original source looked - for obvious reasons. So avoid re-encoding whenever possible!

BTW: Where did you get the Xvid encode of the movie? Why you didn't encode with x264 from your original DVD initially ???

[sneaker_ger]

Of course not! Re-encoding is inherently lossy! Converting the Xvid encode movie, which had already been encoded from the original DVD source, with x264 adds one additional encoding step. Hence re-encoding the movie again, will only add additional loss (hurt quality), but it can never improve quality. Once detail is lost, it cannot be re-added magically, even by the "best" encoder in the world. That's because the encoder only knows the already encoded (lossy!) version you feed into it. It cannot know how the original source looked - for obvious reasons. So avoid re-encoding whenever possible!

BTW: Where did you get the Xvid encode of the movie? Why you didn't encode with x264 from your original DVD initially ???

From what he has said, it seems that he does not want to reencode from xvid to h264 but rather reencode from the DVD to h264.

One more question: for years I have preffered 1.4GB encodes using xvid for a medium long movie with AC3 sound. What is the "standard" filesize for x264 that can be compared to 1.4GB XviD encodes?

The reason for the 1.4 GB Xvid encodes was that during the time those got popular people were still burning to CDs and that 1.4 GB fit perfectly onto 2 CDs. There is no "standard" size like that anymore, since more people are just doing a 1-pass encode with constant quality to a HDD and the size is not important anymore.
Some people tend to do 4,36 GB encodes in 720p to burn on a DVD5 though.

Sorry, even more questions: for DVD9 source encode should I use the Standalone Blue-ray or HD-DVD profile in MeGui, or some other, if the highest quality with reasonable size is wanted?

The standalone profiles limit the bitrate and features to make the encodes more compatible with standalone players. You are probably fine with the "Unrestricted 1pass Const. Quality HQ" or "Unrestricted 1pass Const. Quality Balanced" profiles. Just experience a bit with the quality until you are satisfied.

[LoRd_MuldeR]

From what he has said, it seems that he does not want to reencode from xvid to h264 but rather reencode from the DVD to h264.

So we have the following cases:

1. If the existing Xvid encode already looks "transparent", then making a fresh x264 encode from the original source can not look any better (for obvious reasons), but he may be able to retain transparent quality at a significant lower bitrate (smaller file) with x264. So in this case x264 doesn't improve quality, but saves bits.

2. If the existing Xvid encode does not look "transparent", quality can be improved: Either by re-encoding from the original source with Xvid (but this time at a higher bitrate!) or by re-encoding from the original source with x264 at an appropriate bitrate. Again x264 will require a significant lower bitrate (compared to Xvid) to improve the quality over the "old" Xvid encode. So in this case x264 can improve quality and probably saves bits at the same time - or at least minimizes the number of additional bits we need to spend.

[gurabli]

Sorry for not being too clear, guess I was tired...

I don't want to re-encode a movie, I know that it is quality loss!

What I ment was that I have access to original DVD release that I used to encode using XviD with GKnot (standalone compatible). They are all pretty nice quality rips that were completly satisfying for my CRT television.
Now, I have a 42" plasma TV (HD ready) and I would like to have better quality rips from those same DVDs. Most of these DVDs are old movies, I don't think they are going to be released on Blue Ray or HD DVD (for example: Monty Pythons Flying Circus episodes). If I make new encodes using x264 with MeGui using the same 350MB/episode size, will it look better than my XviD 350MB/episode version? The same goes to other DVDs where no HD source is (yet) available.
I have a WD HD TV player, AFAIK there are some restrictions in profiles, so that is why I would like to use standalone comp. profiles. Encoding speed/time is not an issue. It is quality that matter with a reasonable size (no point to go with sizes like the source DVD is).

The second question I had, which profile should I use in MeGui for this? BR or HD DVD, for there are no profiles for DVD source.

Thank you for your answers!

[LoRd_MuldeR]

I don't want to re-encode a movie, I know that it is quality loss!

I see now :)

What I ment was that I have access to original DVD release that I used to encode using XviD with GKnot (standalone compatible). They are all pretty nice quality rips that were completly satisfying for my CRT television. Now, I have a 42" plasma TV (HD ready) and I would like to have better quality rips from those same DVDs.

I already answered that question in my previous post. But to sum it up once again: If you want higher quality rips than your "old" Xvid rips (which indicates that these old rips are not "transparent" quality), you have at least two options here: Either re-rip them from your original disc with Xvid, but use a higher bitrate than the last time -or- use x264 at a bitrate that comes out at better quality than your old Xvid rips. In case you don't need to hit a specific file size, it's highly recommended to use x264's CRF mode! Try like CRF=18 for excellent quality.

And I say it again: Xvid and x264 can deliver the very same quality. x264 isn't inherently better, Xvid isn't inherently worse (I exclude x264's "lossless" mode here). But at a given bitrate x264 will deliver better quality than Xvid (unless both are transparent at that bitrate). Or in other words: For a given level of quality x264 will require less bits than Xvid. That's it.

The second question I had, which profile should I use in MeGui for this? BR or HD DVD, for there are no profiles for DVD source.

These profiles are not for source types, but for target devices. As x264 is a H.264 encoder, but Video-DVD is limited to MPEG-2, there is no "Video DVD" profile for obvious reasons ;)

You should use the least restrictive profile that your target playback device can handle. What is your target playback device ???

[gurabli]

You should use the least restrictive profile that your target playback device can handle. What is your target playback device ???

OK, I understand it now! My target playback device is Western Digital HD TV player.

Thank you for all the answers!

[MikeTR]

Good read in the end.:)

I see now :)
..use x264 at a bitrate that comes out at better quality than your old Xvid rips. In case you don't need to hit a specific file size, it's highly recommended to use x264's CRF mode! Try like CRF=18 for excellent quality.
...Or in other words: For a given level of quality x264 will require less bits than Xvid. That's it.

Is there any way to 'guesstimate' the approx. bitrate (and target) size on a given CRF setting? If there is a tool for this, I must have missed it so far.

[nurbs]

There is not really a way to guess the resulting filesize. What you can do is make an avisynth script that selects frames on regular intervalls (e.g. 200 out of 2000/4000) and encode that with your settings to get an idea what the final filesize will be, but of course that takes time.

[LoRd_MuldeR]

Is there any way to 'guesstimate' the approx. bitrate (and target) size on a given CRF setting? If there is a tool for this, I must have missed it so far.

No, you can't. The whole idea about CRF is that you specify a level of quality (roughly) and x264 will use as many bits as required for the individual source.

The exactly same CRF value may results in very different bitrates for sources of different type, even if the resolution and the framerate of these sources are identical.

You could do a test encode, as suggested by nurbs, and then extrapolate to resulting bitrate for the entire file.

But then you could do a proper 2-Pass encode from the very beginning! CRF is not intended to hit a specific filesize (or bitrate). 2-Pass mode exists for a reason ;)

[m3mbran3]

I've just encoded a TV series boxset (18 episodes @ 45min) with the unrestricted crf extra quality setting in megui with the crf set at 20. To give you an idea of file size variation, the largest video-only clip was 625mb and the smallest 495mb. This seems to give me pretty good quality encodes that look almost identical side-by-side to the original DVD source. I've found that for almost all DVD sources a crf range of 18-22 will give you very good results. I've read that for an x264 encode you should be able to get similar quality to the original mpeg2 source with between 1/3 and 1/4 of the original bitrate.

Of course x264 has the additional advantage that you can encode the ac3 audio to aac for extra space saving as well.

[7oby]

Note that you can have any quality with any encoder/format! Even the most crappy encoder/format gives excellent quality, if you only raise the bitrate enough ;)

This is definitely one of the most written statements here and it's certainly true. Is there a simple test that translates this to quantitative numbers?

If we ignore the fact that a constant CRF level doesn't exatly translate to a equal quality: How does a constant CRF level with different me/subme settings translate to encoding speed vs. filesize? I think this would help a lot of beginners. Maybe even include XviD in this test.

I'm not talking about the most advanced psy-trellis features here. Just plain basic me=dia, ..., umh and subme=1..7 for some common MeGUI Sharktooth profiles (http://forum.doom9.org/showthread.php?t=101813).

For example: If you transcode some movie to the PSP to watch it on the go and which you gonna delete afterwards anyway, you might want to favor encoding speed and getting that dammed movie on the PSP as fast as possible over filesize. You probably don't need the default umh/subme7 of the PSP profile. And you'll be fine throwing a lot of bitrate at it.

There are many x264 that cut of 30% of the encoding speed and give you at most 10% in file size reduction.

Can somebody point me to such comparisons? I only found this one (which I don't like for a couple of reasons):
http://juliensimon.blogspot.com/2009/01/x264-benchmarks-individual-flags-motion.html

To give an example
. CRF=20 on a 2:24 min trailer YUV12 @ 320 x 240
. YUV12 used to rule out bottlenecking by MPEG-2/-4 decoding speed
. 320 x 240 used to have file in cache and no being bottlenecked by HDD transfer speed
. vbv CLI options removed for test due to interference with crf

Using two different profiles on a T7500 Core2 Duo, I get:
. Device-iPod 5.5G : 252,2 fps, 396,31 kbps
. Device-PSP : 78,58 fps, 284,5 kbps

That's 3x the encoding speed! If you compare the profile options, that's not much of a surprise (no cabac, no partitions, no b-frames, ... for iPod profile):

Device-iPod 5.5G:
--level 3 --nf --no-cabac --partitions none --qpmin 16 --me umh --merange 12 --threads auto
--thread-input --no-psnr --no-ssim

Device-PSP:
--level 3 --ref 3 --mixed-refs --bframes 3 --b-adapt 2 --weightb --direct auto --subme 7
--trellis 1 --partitions p8x8,b8x8,i4x4 --me umh --threads auto --thread-input


And both results are fine for mobile use. And I guess not everybody using the MeGUI profiles expects such a huge difference just by switching target devices.

[Sagekilla]

At a rather simple level, the slower settings you use (i.e. subme 7 instead of subme 5), the smaller your file size will be at a given crf for very similar quality.

By very similar, I mean that for all intents and purposes your eyes won't be able to tell the difference between crf 20 subme 5 and crf 20 subme 9.

[Dark Shikari]

At a rather simple level, the slower settings you use (i.e. subme 7 instead of subme 5), the smaller your file size will be at a given crf for very similar quality.

By very similar, I mean that for all intents and purposes your eyes won't be able to tell the difference between crf 20 subme 5 and crf 20 subme 9.Not at all true. psy-RD, activated at subme 6 and above, tends to significantly raise filesize at the same CRF (and accordingly, quality).

[7oby]

At a rather simple level, the slower settings you use (i.e. subme 7 instead of subme 5), the smaller your file size will be at a given crf for very similar quality.
This is the same statement of LoRd_MuldeR, which I quoted - just with other words.

I wasn't looking for a qualitative comparison. This is what most threads here are about and we mostly have a common agreement and understanding. I was looking for a quantitative one, which will also help to put GPU based encoders in place.

I'm also aware that the most advanced settings (psy-RD and that's why I mentioned trellis) will raise the bitrate at constant CRF levels. And for those mathematical quality measurements don't work anyway.

-

One of the problems I had and that's related to this topic: Mobile devices offer MPEG4-ASP as well as MPEG4-AVC. What's the better way to go if filesize is not an issue? One parameter is encoding speed regarding this matter (another are the level decoding capabilities of the device). Then you need something like x264 with these settings translates to this bitrate and encoding speed. And in a second step you could compare that to XviD. But even for the first step to compare filesize/encoding speed among different x264 CLI options I didn't find a nice summary/test. (I wasn't lazy - I did my own, but it's not as comprehensive as I would have liked it)

If you archive something (DVD) that's "rather" easy: You do it only once. Thus encoding speed doesn't matter much and you may throw a lot of quality encoding options at it. You can always run it as batch with low priority. To me optimizing transcoding for stuff that I watch mobile is more difficult.

[LoRd_MuldeR]

At a rather simple level, the slower settings you use (i.e. subme 7 instead of subme 5), the smaller your file size will be at a given crf for very similar quality.This is the same statement of LoRd_MuldeR, which I quoted - just with other words.

Using "slower" settings at the same CRF value gives better "quality per bit", but there is no way to know how the total size will change ;)

Various things may happen: You may get better quality at same size, smaller file at same quality, smaller file at worse quality or bigger file at better quality.

Note that in the last two cases the "quality per bit" ratio will still be improved over the "faster" settings!

For example: If you end up with a bigger file, the quality improvement is more than what you would have gotten by simply raising the bitrate (lowering the CRF).

If you end up with a smaller file, the loss in quality is less then what you would have gotten by simply lowering the bitrate (raising the CRF).

[Archimedes]

One of the problems I had and that's related to this topic: Mobile devices offer MPEG4-ASP as well as MPEG4-AVC. What's the better way to go if filesize is not an issue? One parameter is encoding speed regarding this matter (another are the level decoding capabilities of the device). Then you need something like x264 with these settings translates to this bitrate and encoding speed. And in a second step you could compare that to XviD. But even for the first step to compare filesize/encoding speed among different x264 CLI options I didn't find a nice summary/test. (I wasn't lazy - I did my own, but it's not as comprehensive as i would have liked it)
I own a HP iPAQ 214 (Marvell PXA310 prozessor, 624 MHz, 640x480). The iPAQ is able to play H.264 content with a resolution of 640x352 at 384 kbps (benchmark of about 120 %, tested with the CorePlayer). I can use all features of x264, but i have to disable deblocking at playback time (in CorePlayer). With deblocking on at playback time i have to disable a lot of features (b frames, 8x8dct, CABAC etc.) to become a stuttering free playback. Of course, with disabling some features i can go up with the bitrate, but the results are not very amusing.

Even with enabling the deblocking at playback time (wich results in a stuttering video), a 735 kbps XviD video looks much better – in my eyes - than a 384 kbps x264 video (with all features enabled). I find out, that x264 needs about 66 % of the XviD bitrate for my sources (interlaced tv captures). So the filesize reduction in this case isn't big so far. And as i see a little difference between 800 kbps and 1000 kbps (XviD videos) on the small display, i normally use 1000 kbps for a resolution of 640x352. For 640x480 i'm using bitrates of about 1300 kbps. The iPAQ is able to play up to 3000 kbps (and a little bit more) at a resolution of 640x480 (benchmark of about 126 %)! DV videos, for example, need such high bitrates. What's your x264 arguments against such high bitrates? :D

So, the best playback quality - in my eyes - can only be achived with XviD (Mpeg 4 ASP) die to the hardware limitations of the iPAQ.

[nm]

I own a HP iPAQ 214 (Marvell PXA310 prozessor, 624 MHz, 640x480). The iPAQ is able to play H.264 content with a resolution of 640x352 at 384 kbps (benchmark of about 120 %, tested with the CorePlayer). I can use all features of x264, but i have to disable deblocking at playback time (in CorePlayer). With deblocking on at playback time i have to disable a lot of features (b frames, 8x8dct, CABAC etc.) to become a stuttering free playback.If that iPAQ is the primary target for your encodes, it would be much better to disable deblocking during encoding instead of decoding. Otherwise you get additional corruption, especially at low bitrates such as 384 kbps for 640x352 video.

[Ghitulescu]

Hi!

first of all, sorry if this has been already discussed, but I couldn't find the answer. Few days ago I got my first HD TV and now I'm looking to replace my old XviD collection with the new HD content where available. But there are still some movies that are not BR or HDDVD published.

Wait ;).

This year (2009) just appeared some movies never issued on DVD, and DVD was here for 10 years now. Now the collectors spend hours recoding them to divx/h.264 from DVDs, the very same thing they did years ago with VHS tapes. Back then made a lot of sense, today I'm not sure it's worth the energy/time/electricity. Tomorrow they'll find the same movie/series on BD and they start again recoding it ...

It seems to be more like a frenzy than a real need ;)

PS: buy the HDDs in pairs (mirror one to the other one), otherwise you'll risk doing this once more, HDDs won't last forever...

[Chengbin]

I own a HP iPAQ 214 (Marvell PXA310 prozessor, 624 MHz, 640x480). The iPAQ is able to play H.264 content with a resolution of 640x352 at 384 kbps (benchmark of about 120 %, tested with the CorePlayer). I can use all features of x264, but i have to disable deblocking at playback time (in CorePlayer). With deblocking on at playback time i have to disable a lot of features (b frames, 8x8dct, CABAC etc.) to become a stuttering free playback. Of course, with disabling some features i can go up with the bitrate, but the results are not very amusing.

Even with enabling the deblocking at playback time (wich results in a stuttering video), a 735 kbps XviD video looks much better – in my eyes - than a 384 kbps x264 video (with all features enabled). I find out, that x264 needs about 66 % of the XviD bitrate for my sources (interlaced tv captures). So the filesize reduction in this case isn't big so far. And as i see a little difference between 800 kbps and 1000 kbps (XviD videos) on the small display, i normally use 1000 kbps for a resolution of 640x352. For 640x480 i'm using bitrates of about 1300 kbps. The iPAQ is able to play up to 3000 kbps (and a little bit more) at a resolution of 640x480 (benchmark of about 126 %)! DV videos, for example, need such high bitrates. What's your x264 arguments against such high bitrates? :D

So, the best playback quality - in my eyes - can only be achived with XviD (Mpeg 4 ASP) die to the hardware limitations of the iPAQ.

I agree wholeheartedly

I have an Archos 5, which plays just about every format out there (except high profile H.264 and MKV). It has an ARM Cortex A8 at 600MHz. At 704x400, main profile H.264, with settings like CABAC, deblocking, 4 b-frames, 6 ref-frames, and b-pyramid, maximum bitrate is about 5400Kbps before stuttering. But, if I use XviD, with every setting on, the maximum bitrate at the same resolution is around 20Mbps, which translates into about 7000-8000Kbps in 1280x720. Since it has a HDMI out, if I had a HDTV, I would definitely choose XviD at 720p.