Is converting DVDs to AVC a good idea?

[comomolo]

I've tried a few times the search string "DVD to AVC" and I get no results. It's weird.

H.264 AVC is the best quality compression scheme available, right? However, most so called DVD-Backup solutions still rely on either stronger recompressing MPEG2 (DVD9 to DVD5 solutions) or transcoding MPEG2 to Divx/Xvid (DVD to CD solutions).

While I've found some solutions to transcode DVD to AVC (Nero Recode, for instance) I can't see much enthusiasm about it. Isn't it a good idea to transcode DVDs into the new H.264 AVC format? Shouldn't it be the less destructive of all transcoding solutions? Isn't it reasonable to expect a better quality than transcoding to ASP or Divx, for instance?

[82ross]

It is reasonable, but the time it takes to encode a dvd to avc is a lot longer than to encode to xvid for example. Look into it and you can see its just a matter of convenience, people rip to xvid a tried and tested method. AVC is great but is the time increase worth the quality increase?


For most people at this time, no. It is something that will progress though. Codec optimisations, better hardware to encode and better hardware to decode will all increase the popularity of avc.

[smok3]

well, iam very entuziastic about it, however i do prefer to keep DVD backups with all the 'makingof' stuff as well, nothing easier/faster than to fire some dvdshrink.

The mp4 authoring tools should really get better/accesible and it is a win then.

[comomolo]

I was asking because I want to build a media server at home and I was thinking about 1 GB per movie files. But I also like all the extra stuff that comes with DVDs as well as all the audios and subtitles. Isn't all that stuff available after transcoding?

I really don't care that much about the processing time. It's the computer working, not me... :) Is there any comparison of the quality I can expect from AVC vs Xvid?

[markrb]

I am doing much as you are thinking of now.
However my goal is basically 1/2 the orginal movie size, not the DVD size.
I remove all the extra's and then calculate what target size I go for based on that. A short movie might hit 1.4Gb's in size while a very long movie might be almost 3gb's. Large I know, but still a considerable savings over the 7-8gb's of the original DVD.
I put all the files on a server upstairs, connected by gigabit to the HTPC downstairs. Streams fine with no issues.
Some movies I do want the whole disc ready and those I keep in ISO format on the local HTPC drive.
I could always hit the closet and get the DVD out and put it into the player, but I love the idea of just a click away always.

I have tried Xvid, but I prefer X264. I use Megui as the frontend after ripping in IFO mode with Decrypter.

I have tried Nero Digital and was very dissapointed with the quality.

It all works really well with my setup. I use MediaPortal as the frontend of my HTPC and I use Media Player Classic to watch the MKV files.

Mark

[comomolo]

So you would say X264 is worth the processing time, right?

EDIT: I have found this: http://www.xile.net/xvid_vs_x264/

If that's what can be generally expected, I believe x264 is worth it.

[bond]

seeing that the avc forum has more posts already than the divx forum, altough its around for a far shorter period, tells me that there is indeed a lot of enthusiasm about avc :D

[markrb]

My only issue with x264 is the background blocks, but this also happens with Xvid.
It seems to amplify the source blockyness to my eyes.
I have tried just about every suggestion I have read and researched and nothing seems to help much.
If you are looking for true 1:1 quality I don't see it at this point with either of these, but to my eyes I prefer x264.
Although for smaller movies I am considering leaving them alone for now.

Mark

[comomolo]

Mark: since your goals and mine seem to be close, may I ask what MeGUI preset (if any) are you using to encode your pictures? Does this blockiness happen even if you use HQ-insane?

[Blue_MiSfit]

Keeping the extras on the DVD is tricky as this requires menus. Supposedly there is a program that can embed menu structure into an MP4, but I have never really heard anything about it.

I do 1.1 GB rips (1/4 DVDR) for most movies, and 2.2GB rips (1/2 DVDR) for longer movies, and those with exceptional quality that I want to preserve. This also affords keeping the AC3 track as opposed to transcoding to AAC.

1/4 DVDR with 6ch AAC usually results in excellent quality, indistinguishable from the DVD on an NTSC TV. The blocky background issue has been mostly resolved by a couple of things:

1) no fast p skip
2) disabling the in-loop filter (for 2.2 GB rips only)
3) using M4G's high detail matrix
4) careful pre-filtering to increase compressibilty (usually removegrain mode 5 or 2, or tweaked fft3dgpu + de-banding)

1/2 DVDR is exceptional. Transparent I would submit. This is between 1/2 and 1/4 the size of the original DVD, which is excellent compression IMO.

My usual settings off the top of my head:
*all motion search options
*deblocker -2,-1
*3 bframes, all options
*6 refs
*level 1 RDO
*level 1 trellis
*no fast p skip, no dct decimation

This is a tweaked version of the HQ-Slow profile. I usually get ~5fps on my Athlon64 (see sig for details)

XviD can pretty much do the same at these bitrates and is easier to decode, but I'm all about x264 these days. MeGUI is my best friend!

BTW, I usually add a tiny ammount of noise on playback with ffdshow to increase percieved detail. Luma<12, Chroma<8... Does a great job!


~MiSfit

[frodeste]

@Blue_MiSfit
:goodpost:

Could you tell me what kind of container you use that allows you not to transcode the ac3 or dts tracks? As far as I know, the .mp4 container does not support this.

One other thing I am testing, is the "threads option" in meGUI's profile for video encoding. By default, it is set to 1. I have a dual cpu setup, so I thought I would try to set it to 2. So far, this seems to speed things up. Comments?

[comomolo]

Would you say x264 at 1/4 the original DVD size is better than recoding MPEG2 to 1/2 the original size?

[bond]

Would you say x264 at 1/4 the original DVD size is better than recoding MPEG2 to 1/2 the original size?no, such a statement cant be done

apart from that mpeg-2 is not a codec, its a standard

[shon3i]

no, such a statement cant be doneBut any mpeg4 codec both asp and avc are better than mpeg2 at same bitrate almost 40-60%, this percent are grow up in small bitrates and lower in higer bitrates, like aac vs mp3

[comomolo]

Bond: let me rephrase:

If highest quality was your main concern, would you rather recode a DVD9 into DVD5 or would you recode it using x264 into something like half a DVD5?

And while we're at it, how much of a difference would do AVC vs ASP in this particular case?

[bond]

But any mpeg4 codec both asp and avc are better than mpeg2 at same bitrate almost 40-60%, this percent are grow up in small bitrates and lower in higer bitrates, like aac vs mp3not true, there can be easily avc or aac codecs that are worse then mp3 or asp or mpeg2 codecs

If highest quality was your main concern, would you rather recode a DVD9 into DVD5 or would you recode it using x264 into something like half a DVD5?i dont know. it not only depends on the mpeg-2 codec you use, but also on the video stream compressibility. i would say you cant answer this unless you try it yourself

if you say you would want to encode with a good mpeg-2 codec or x264 at the same bitrate i would choose x264.

And while we're at it, how much of a difference would do AVC vs ASP in this particular case?the higher the bitrate the less the difference. also it depends on the quality of the codec. talking only about the standards is misleading. a great asp codec, like xvid, could beat a crappy avc codec easily

it also depends on where you want to play the stream. if you want to play it on the dvd player in your living room you might want to encode to dvd even if the quality might be slightly worse.
if you have a crappy pc you might want to encode to asp because you cant play avc in realtime
aso aso


all in all we have rule 12 not for nothing. there simply is no "best" solution

[comomolo]

the higher the bitrate the less the difference
Would you give me a hint on where, more or less, would lie the frontier between the two codecs? 1000? 3000? 6000? (kbps) (I'm always talking about x264 and xvid).

all in all we have rule 12 not for nothing. there simply is no "best" solution
This is a beginner asking for experts opinion. If that's not allowed in this forum, please let me know and I will stop asking. I find your replies so far very valuable and helpful, as they're helping me understanding which way should I go, but if I'm in the wrong place asking wrong questions I'll understand and leave.

[markrb]

Mark: since your goals and mine seem to be close, may I ask what MeGUI preset (if any) are you using to encode your pictures? Does this blockiness happen even if you use HQ-insane?

This blockyness happens no matter the profile or even the bitrate used.
I am always trying new settings to see their effect and haven't come up with a solution yet that I am happy with.
I am leaning now to a smoother image. If I am right this should reduce the background blocks, but will slightly blur the image. I prefer a very sharp image, but I believe that amplifies the blocks.

If my current test works the way I think it will come out then I am going to have to start looking at each source and decide if it can take a little smoothing. I am pretty sure most sources will come out just fine and the ones that don't hopefully are less blocky to begin with.

In the end if you are looking for 1:1 quality I don't think that either XVID or X264 are there yet or may never be.
However I believe that with some more testing and tweaking I can eventually find settings I will be happy with.
Keep in mind I watch these on a 55" high def TV. Errors are noticable at that size.

Mark

[shon3i]

not true, there can be easily avc or aac codecs that are worse then mp3 or asp or mpeg2 codecsI don't know bond, how avc can be whrose than mpeg2 on same bitrate (aslo asp), i say that mpeg4 (nevermind that is asp or avc) must be better than mpeg2, or isn't, so we than not need mpeg4 anyway when is mpeg2 good enought right. I aslo say that if we have asp,avc,mpg2 for example @ 8mbs, where every codec will be trasparent, but i aslo think that avc must have about 2% better quality than others two, like avc in for example encoding @ 500kbs must have about 30+% in quality than others two. Correct me if i wrong.

Aslo AAC is supperior than mp3 about 30-60% in lower rates, and very small percent in high rates but comparing AAC @ 320kbs and mp3 @ 320, i think that aac is better because mp3 have big cutoff on 16khz.

Both AAC and AVC must be superior than other only if encoders is good.

[foxyshadis]

@Blue_MiSfit
:goodpost:

Could you tell me what kind of container you use that allows you not to transcode the ac3 or dts tracks? As far as I know, the .mp4 container does not support this.

One other thing I am testing, is the "threads option" in meGUI's profile for video encoding. By default, it is set to 1. I have a dual cpu setup, so I thought I would try to set it to 2. So far, this seems to speed things up. Comments?
Since no one answered: MKV. Maybe avi if you can find something to crowbar it in, but mkv will work without a hitch.

2 threads splits the encode into two side-by-side encodes; while it causes a minute quality loss, I've only ever seen a visible drop at the lowest, ugliest end of the bitrate spectrum.

[IgorC]

I don't know bond, how avc can be whrose than mpeg2 on same bitrate (aslo asp), i say that mpeg4 (nevermind that is asp or avc) must be better than mpeg2, or isn't, so we than not need mpeg4 anyway when is mpeg2 good enought right. I aslo say that if we have asp,avc,mpg2 for example @ 8mbs, where every codec will be trasparent, but i aslo think that avc must have about 2% better quality than others two, like avc in for example encoding @ 500kbs must have about 30+% in quality than others two. Correct me if i wrong. There is too much imprecision. First, You didn't any kind of test. We don't know if MPEG-2 is worse than ASP at such high bitrate as 8 mbps. ASP is mostly optimizied for low and middle bitrates. For high bitrates ASP ( I mean Xvid because using Divx is totally waste of bitrate due to its prefiltering for low bitrates needs) encoding it should be used sharp CM and maybe change another settings etc..
Second 8 mbps for SD or HD? It is a complex task.

Aslo AAC is supperior than mp3 about 30-60% in lower rates
Very imprecise.
How low rates are? If it's 16 kbps then AAC is superior than mp3 more than 30-60%. I think _maybe_ it's 300%.

and very small percent in high rates but comparing AAC @ 320kbs and mp3 @ 320, i think that aac is better because mp3 have big cutoff on 16khz.
It's not corect to compare AAC and MP3 at the same bitrate 320 kbps. From my limited experience with audiocodecs I think that to spot itunes AAC at 192 kbits from CD quality is more difficult than MP3 LAME free format ( > 320 kbps).
And last one. Lame mp3 has no 16 khz cut at 320 kbps. And lowpass at high frequencies has nothing to do with quality.
Itunes cuts more freqs at 192 than Lame at 320 kbps does but imo itunes (from my little limited only to me ABX test) is transparent in most of cases while Lame still has issues. Maybe fewest issues but there are still here.

[MeteorRain]

Correct me if i wrong.
hi i'm coming! (Orz

You should know this before everything: ASP, AVC, Mpeg-2, are all standards, which indicate the decoding process.

for a codec, how it encodes doesn't matter much. if the encoded bitstream can be decoded in an ASP way, it IS an ASP codec. also AVC.

if a codec, works bad, is encoding a file into an AVC-codec decodable bitstream, it is an AVC encoder.

so, all what you said, in fact, are indicating x264 is better than tmpgenc (or so) (and nero aac/winamp aac encoder than lame or whatsoever), not H.264 is better than Mpeg-2. if you'd like to compare h.264 & mpeg-2, you should put them on a technology level. for example, what different technology do they support? (h.264 works with cabac and mpeg2 not, aso)

(correct me if i'm wrong

regards
MR

[comomolo]

For the sake of clarity, I would keep it simple: it seems everyone around here accepts that x264 is the best H.264/AVC encoder and xvid the best ASP encoder. I don't want to wake up the monster by talking about "the best anything", but let's asume that for a moment if you guys agree.

When we're talking about choosing one technology or standard over another (MPEG2 vs AVC vs ASP) we're talking about using the best implementation of that tecnology out there, aren't we?

That should simplify the discussion.

[MeteorRain]

not so sure if x264 is the best avc encoder.

some ppl are thinking nero avc's better (yes, a friend of mine thinks so), and nero avc, in some extent __maybe__, works better than x264.

also, options are important. for example, the inloop-filter. lots ppl have lots opinions.

and also depends on the material. x264 doesn't work fine with blue sky, and XviD with red ball.

anyway, a good avc encoder is really better than a good asp encoder on most extents.
avc must be more and more popular in the future, w/ the development of the hardware.

[markrb]

1) no fast p skip
2) disabling the in-loop filter (for 2.2 GB rips only)
3) using M4G's high detail matrix
4) careful pre-filtering to increase compressibilty (usually removegrain mode 5 or 2, or tweaked fft3dgpu + de-banding)

1/2 DVDR is exceptional. Transparent I would submit. This is between 1/2 and 1/4 the size of the original DVD, which is excellent compression IMO.

My usual settings off the top of my head:
*all motion search options
*deblocker -2,-1
*3 bframes, all options
*6 refs
*level 1 RDO
*level 1 trellis
*no fast p skip, no dct decimation

This is a tweaked version of the HQ-Slow profile. I usually get ~5fps on my Athlon64 (see sig for details)

BTW, I usually add a tiny ammount of noise on playback with ffdshow to increase percieved detail. Luma<12, Chroma<8... Does a great job!
~MiSfit

I am trying pretty much the exact same setup with some differences minor.

Misfit could you expand on the inloop filter and what settings you tend to use for the pre-filtering. Where is the inloop filter? Are you talking about the deblocking filter inside megui (-2, -1) filter? If so I know which one, but just want to be sure.
Maybe you could post an avs file that I could customize for me if you don't mind with your typical pre-filter settings? I would love to see what they do for background blocks. As I said I have tried everything I have come across and will continue to until I am happy with the settings.

[comomolo]

not so sure if x264 is the best avc encoder.
OK, my point was: when someone refers to AVC vs ASP s/he's referring to "a very good if not the best AVC encoding implementation" vs "a very good if not the best ASP encoding implementation". I just wanted to get rid of statements like "a bad AVC encoder is worse than a good MPEG2 encoder", which are almost obvious. It's understood that anyone seeking for the best practice will hunt for the best tools too, so s/he won't use a bad encoder no matter the standard behind. That's it.

[MeteorRain]

btw, i'd more like to use constant quantization instead of two-passes processing to ensure the video is encoded under quality-based, not size-based.

cheers

[shon3i]

Very imprecise.
How low rates are? If it's 16 kbps then AAC is superior than mp3 more than 30-60%. I think _maybe_ it's 300%.
You can't compare HE-AAC and mp3, because is unfair, because mp3 not use sbr tech, but comparing mp3Pro and HE-AAC in lover rates HE-AAC is better about 30% than mp3Pro (if you have good decoder for mp3Pro)

Lame mp3 has no 16 khz cut at 320 kbps. And lowpass at high frequencies has nothing to do with quality.
Not at 16khz but have at 18khz, even is mp3 at 320 transprent, somwere on HA.org forum, someone told that (i am not sure Gabriel or Graf) mp3 can't propertly code samples even on 320kbs, So lc-aac must be anyway better than mp3 on higer bitrates. (like you say iTunes @ 192 sound very transparent than mp3 @ 320)

if you'd like to compare h.264 & mpeg-2, you should put them on a technology levelThat is not true because if i disable everything in H264 why i am then anyway use H264. Fair comparing will be to use maximum settings for H264 and maximum for mpeg2, and see what is better

[IgorC]

For a love to God. It is not 16 khz neither 18 khz.
You are wrong twice already. If you don't know then encode one sample with Lame at 320 kbps and look which lowpass it has. With lame 3.90.3 it's possible to use -k feature and keep all frequencies up to 22,050 khz. Maybe it improves something but not always. Transparency is something personal and depending on abilities and equipments of each one.

http://img110.imageshack.us/img110/9671/cmduy5.jpg
http://img110.imageshack.us/img110/4468/20khzcs9.jpg

You can't compare HE-AAC and mp3
Actually you did it first in your previous post. I simply followed your sample.

[bond]

Would you give me a hint on where, more or less, would lie the frontier between the two codecs? 1000? 3000? 6000? (kbps) (I'm always talking about x264 and xvid).there is no such general frontier. it all depends on things like compressibility of the source (the darker the easier to compress for example), resolution aso...

[shon3i]

Actually you did it first in your previous post. I simply followed your sample.I said that AAC is 30-60% better than mp3 in any case especialy in lower rates, and you say that is aac better than mp3 about 300% and quote an example

If it's 16 kbps then AAC is superior than mp3 more than 30-60%. I think _maybe_ it's 300%.

and i said that you can't compare two different codecs like that, because all codecs including LC-AAC can't defeat now HE-AAC in lower rates, but i think about 30-60% when we instead mp3 use mp3PRO, because mp3PRO sound aslo good at lower rates (not so good but about 40% whrose tahn HE-AAC)

[GodofaGap]

Can we stop now pulling percentages out of our behinds? How did you actually come up with these figures?

[Blue_MiSfit]

Since no one answered: MKV. Maybe avi if you can find something to crowbar it in, but mkv will work without a hitch.

2 threads splits the encode into two side-by-side encodes; while it causes a minute quality loss, I've only ever seen a visible drop at the lowest, ugliest end of the bitrate spectrum.

thanks for covering for me foxyshadis :)

I hadn't checked this thread in awhile, but yes MKV is the container format I prefer.

I am trying pretty much the exact same setup with some differences minor.

Misfit could you expand on the inloop filter and what settings you tend to use for the pre-filtering. Where is the inloop filter? Are you talking about the deblocking filter inside megui (-2, -1) filter? If so I know which one, but just want to be sure.
Maybe you could post an avs file that I could customize for me if you don't mind with your typical pre-filter settings? I would love to see what they do for background blocks. As I said I have tried everything I have come across and will continue to until I am happy with the settings.

Yes I mean the deblocker. It is different from (for example) deblocking in ffdshow. I dont know the details, but I do know that having it enabled tends to kill details that could otherwise be preserved at high bitrates - IMHO.

I still have some problems with the big flat gradients blocking a bit.

As far as pre-filtering is concerned, removegrain(mode=5) is basically free extra compressibility. I cannot tell the difference between the source and mode 5. mode 1 is just undot. mode 2 is a bit blurrier... I pretty much use removegrain on every encode I do.

For those that are a little noisier, I like to add fft3dgpu but this one is really no "one setting fits all". There are lots of parameters and the defaults are too aggressive for me. Reading the documentation and spending time tweaking and testing with stackvertical(source,filtered) is crucial.

I have found that at conservative settings for fft3dgpu, there tends to be a bit of banding. Gradfun2db can help these.

I used to always use undot().unfilter(-5,-5) which gives a big boost. Then I realized that this unfilter call generally softened things too much for my tastes. It's a GREAT base setting for filtering animated stuff though.

Another awesome filter that I used to use all the time but haven't recently (mainly because I forgot about it after doing a reinstall) is LRemoveDust. This is Didee's update of RemoveDust, and it's freaking cool, and fast! Search about...

Anyway, totally killing the x264 blocks in the big flat scenes is almost impossible. My theory is that if you are really looking to preserve everything with no blocking whatsoever and have the bitrate to do it (2500+, though as we know that number is totally meaningless :)) - just do XviD with 6of9 or EQM-V3HR. It doesn't have this problem in my experience.

I really thought I had this problem beat in x264, but last night I encoded Pretty Persuasion (omg... absurd freaking movie, pretty entertaining though) using only removegrain(mode =5), no deblocker, and the other settings I mentioned. I shot for 1848mb (2200mb - AC3), and when using stackvertical(source,encoded), I could not tell most frames apart. Still, in those flat areas I did notice a tiny bit of blocking. We're talking maybe 5 minutes of the whole film, but still I couldn't help staring at it. ME NO LIKE BLOCK!:eek:

I'm gonna try again with XviD tonight and see if I can murder those damned infernal blocks!

Sorry if I rambled or got OT...

~MiSfit

[shon3i]

@Blue_MiSfit nice tutorial, about this filters did you mean to use all of this filters for example

undot().unfilter(-5,-5)
RemoveGrain(mode=5)
LRemoveDust ()
etc..

or?

[Blue_MiSfit]

No... That would be too much :)

For many movies I used to do UnDot().Unfilter(-5,-5).

UnDot = RemoveGrain(mode=1), but RemoveGrain is faster (especially the SSE2/3 versions).

Now I use at least RemoveGrain(mode=5).

If I use fft3dgpu(...) I will usually follow it with RemoveGrain(mode=5), and gradfun2db(...).

I just stumbled across a PM from Didee that I got awhile back that really explained a lot to me. Here is a part of it:


Well, whatever I could tell you, for sure means SLOW processing. Not really my fault - but to get the best possible out of any source, one just cannot get away with one or two ultra-fast filters. And also not without filtering. Dedicated processing means *a lot* of computations, to get only a little effect in the end - overprocessing is evil, too. Good things always take their time. Before I would produce 5 mediocre rips in a week, I'd rather do only 1, but get a really beatiful result.

Producing average quality is not an art.


Quote:
So you think the encode would look better if I dropped pixiedust?

Probably not. Make yourself a little experiment: take one minute of the source, encode it @ quant=2 - one time *with* PixieDust(2|3), one time without any filtering. Afterwards, compare the filesizes. The conclusion is: where the Dust'ed encoding will come out with an average quant of, say, 3.2, the not-filtered encoding will need an average quant of 4.0~4.5, or something like that. See my point?

Many people say "I don't do ANY filtering, 'cause I want to stay as close to the original source as possible." Now, that's a good objection, but the wrong way to achieve it (unless one goes for VERY high bitrates, like >3000 kbps.

The point is, the encoding process will filter out very much frequencies anyways. In the end, it plays no role if frequencies were dropped by pre-filtering, or if they were dropped by the encoding process.
But: If the encoder drops frequencies, then it will drop them out of the motion-compensated error-image. And this one is a wild mixture of a) noise and b) actual image content that could not be fully compensated. Therefore, the codec will drop noise as well as it will drop actual image information. Therefore, I prefer to do careful pre-processing. There I have much more control over the distinction between noise and detail. If prefiltering is succesful in dropping much more noise than detail and/or sharpness, then the final loss in the encoding stage will be much smaller: The noise is already out, so the encoder is much less forced to drop *anything*, for a given bitrate.

And my little trick with applying "TemporalSoften(1,2,3,23,2)" before PixieDust is just for making Dust's life a little easier. The loss from that tempsoften isn't noticeable, but in fact the clip gets way calmer on a per-pixel level, so that the motion estimation engine of Dust has a cleaner source, and can work better.
Oh, and the spatial part of Dust suffers a little bit from noise-cutoff. You probably won't see it when viewing the clip, but for sure the encoder sees it during encoding. UnDot() after Dust is reasonable effective against that - even better than before it (!).

So, a better sequence than only PixieDust() alone looks like that:

TemporalSoften(1,2,3,23,2)
ConvertToYUY2().PixieDust(2).ConvertToYV12()
UnDot()

Lastly: If possible, avoid higher values for Dust than "3"!! I mostly use "2" only, and that's fully enough most times. Dust is very different from all other filters. To learn a little more about it, visit this thread, and take those few minutes for reading .


Quote:
Also, I was using avisynth's built in sharpen() function. What would YOU reccommend for a bit of sharpening when upsizing?

Short answer: iiP.

Longer answer: For sure, not a simple sharpen(). If you want a fast sharpening after dust, use unfilter(20,20)~(40,40). unfilter works only on luma, leaving chroma as de-noised as it already is, in this case, sharpen() will re-introduce a little chroma noise. And, for me unfilter does the job just a little better.

Another very good possibility is to used supersampled XSharpen, a.k.a. sharp resize:
LanczosResize(current_size * 4).XSharpen(255,255).LanczosResize(current_size)
Perhaps even with Lanczos4 instead of Lanczos. But then again, that's slow.

Yet another possibility: LimitedSharpen(). But it's also not very fast ...


It's a tad unrelated, but the thought process applies. I hope you ppl enjoy and that Didee doesn't mind :)

~MiSfit

[*.mp4 guy]

I've been working on a new matrix (http://www.yousendit.com/transfer.php?action=download&ufid=10E832D079074FD3) for "transparency", its not quite finnished yet, but It should work well If anyone here is actually aiming at transparency in X264.

My high detail matrix (http://www.yousendit.com/transfer.php?action=download&ufid=8EBC6357519773C9) has been through some changes aswell, its not quite aimed at the same area as the old one though (it is aimed at a bit higher bitrates).

Also recommended deblocking settings for both matrixes are -2:-4 for sharp results, -1:-2 for medium sharpness, and 0:1 for smooth results. I would recommend using the sharpest settings that don't casue enough artifacts to bother you.

[elguaxo]

Thanks *.mp4 guy!

[frodeste]

Since no one answered: MKV. Maybe avi if you can find something to crowbar it in, but mkv will work without a hitch.


Agreed. I will use MKV for now. I should get this to play fine in any directshow player with the correct codecs. I have been reading up on this container since I posted last.


2 threads splits the encode into two side-by-side encodes; while it causes a minute quality loss, I've only ever seen a visible drop at the lowest, ugliest end of the bitrate spectrum.

I cannot see any difference on a small display. Speed increase on the second pass was not noticeable, so I will keep it at 1 thread.

:thanks:

[markrb]

Call me stupid, but what do you mean by "transparency"?

Thanks,
Mark

[smok3]

markrb, visually indistinguishable from original = transparent (also used in audio domain, like: that mp3 is subjectively transparent to uncompressed version)

[frodeste]

I have been testing encoding a couple of DVDs to h264 using MeGUI and x264. Source: Hostage PAL DVD

AVIscript:

DGDecode_mpeg2source("V:\Hostage\VIDEO_TS\VTS_05_1.d2v",info=3)
ColorMatrix(hints=true)
#Not doing anything because the source is progressive
#crop
BicubicResize(720,384,0,0.5) # Bicubic (Neutral)
Undot() # Minimal Noise

Profile used: HQ-Insane, target bitrate: 1400 kbps without soundtrack.

Log:
Starting job job1-1 at 23:01:50
encoder commandline:
--pass 1 --bitrate 1400 --stats "V:\Hostage\VIDEO_TS\1.stats" --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --analyse none --vbv-maxrate 25000 --me dia --threads 2 --thread-input --progress --no-psnr --output NUL "V:\Hostage\VIDEO_TS\1.avs"
successfully started encoding
Processing ended at 00:43:26
----------------------------------------------------------------------------------------------------------

Log for job job1-1

avis [info]: 720x384 @ 25.00 fps (162990 frames)
x264 [warning]: VBV maxrate specified, but no bufsize.
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
x264 [info]: slice I:1227 Avg QP:17.16 size: 31163
x264 [info]: slice P:61300 Avg QP:19.07 size: 10957
x264 [info]: slice B:100463 Avg QP:20.66 size: 4275
x264 [info]: mb I I16..4: 36.5% 0.0% 63.5%
x264 [info]: mb P I16..4: 21.9% 0.0% 0.0% P16..4: 56.2% 0.0% 0.0% 0.0% 0.0% skip:21.9%
x264 [info]: mb B I16..4: 1.4% 0.0% 0.0% B16..8: 23.4% 0.0% 0.0% direct:23.1% skip:52.0%
x264 [info]: direct mvs spatial:99.1% temporal:0.9%
x264 [info]: SSIM Mean Y:0.9819285
x264 [info]: kb/s:1398.1

encoded 162990 frames, 26.77 fps, 1399.18 kb/s

----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated
job job1-1 has been processed. This job is linked to the next job: job1-2
Starting job job1-2 at 00:43:26
encoder commandline:
--pass 2 --bitrate 1400 --stats "V:\Hostage\VIDEO_TS\1.stats" --ref 16 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --threads 2 --thread-input --progress --no-psnr --output "V:\Hostage\VIDEO_TS\1.mp4" "V:\Hostage\VIDEO_TS\1.avs"
successfully started encoding
Processing ended at 11:13:57
----------------------------------------------------------------------------------------------------------

Log for job job1-2

avis [info]: 720x384 @ 25.00 fps (162990 frames)
x264 [warning]: VBV maxrate specified, but no bufsize.
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!
mp4 [info]: initial delay 2 (scale 25)
x264 [info]: slice I:1227 Avg QP:16.25 size: 31395
x264 [info]: slice P:61300 Avg QP:17.94 size: 11095
x264 [info]: slice B:100463 Avg QP:19.38 size: 4203
x264 [info]: mb I I16..4: 22.9% 50.5% 26.6%
x264 [info]: mb P I16..4: 5.7% 10.0% 2.2% P16..4: 42.6% 16.3% 7.2% 0.6% 0.3% skip:15.0%
x264 [info]: mb B I16..4: 0.3% 0.8% 0.3% B16..8: 36.3% 2.2% 3.8% direct: 5.0% skip:51.2%
x264 [info]: 8x8 transform intra:55.5% inter:45.2%
x264 [info]: direct mvs spatial:87.6% temporal:12.4%
x264 [info]: ref P 55.2% 17.0% 8.5% 4.1% 3.0% 2.7% 2.1% 1.2% 1.0% 1.0% 0.8% 0.8% 0.7% 0.7% 0.7% 0.5%
x264 [info]: ref B 71.3% 14.3% 4.6% 2.4% 1.3% 1.1% 0.8% 0.6% 0.4% 0.4% 0.3% 0.5% 0.3% 1.2% 0.3%
x264 [info]: SSIM Mean Y:0.9863097
x264 [info]: kb/s:1400.0

encoded 162990 frames, 4.31 fps, 1401.03 kb/s

desired video bitrate of this job: 1400 kbit/s - obtained video bitrate (approximate): 1403 kbit/s
----------------------------------------------------------------------------------------------------------
Job completed successfully and deletion of intermediate files is activated
Found intermediate output file 'V:\Hostage\VIDEO_TS\1.stats', deleting...
Deletion succeeded.Starting job job2 at 21:08:31
encoder commandline:
-add "V:\Hostage\VIDEO_TS\1.mp4" -new "V:\Hostage\VIDEO_TS\2.mp4"
successfully started encoding
Processing ended at 21:16:53

Problem: Stutter. Several sequences play just fine, and then parts or the whole image will stutter back and forth for a few seconds. CPU usage is never above 10% during playback, and all other paramteres like RAM are well below max. Playback is now done in Nero Showtime.
The stuttering appears to be more frequent at bitrates above 1 mbit/s


I have been reading prevous posts but they don't give the clues I need. Any clues would be of great help!

Could this be because of the VBV Buffer Size?

[GodofaGap]

Well the most obvious question to ask would be if you tried another player (MPC, VLC, etc.).

[frodeste]

Well the most obvious question to ask would be if you tried another player (MPC, VLC, etc.).
Not yet, I did however try another encode using CE-Baseline. No stuttering at all.

[Blue_MiSfit]

try other players. Specifically, Media Player Classic with ffdshow handling the h.264 decoding.

[frodeste]

try other players. Specifically, Media Player Classic with ffdshow handling the h.264 decoding.
:) Already there! I will test this tonight, or sunday. But I thought I would test the CoreAVC first. Reading this forum tells me that this should be more efficient.

Thank you for your input!

[comomolo]

Call me stupid, but what do you mean by "transparency"?


markrb, visually indistinguishable from original = transparent (also used in audio domain, like: that mp3 is subjectively transparent to uncompressed version)

Well, I've been told at another thread that 3000 kbps would be "transparent". I used that bitrate and HQ-slow, but I see tons of blocks dancing around in flat colored areas. I certainly can distinguish that from the original DVD very easily.

Are we hoping for the impossible or transparency can actually be achieved?

[smok3]

comomolo, certainly not with bitrate methods, try some quality based encodings..., and even there only maybe, depends on a lot of parameters. Best bet is to do case on case method so far.

[comomolo]

Thank you smok3,

I started this thread and I think I have an answer to the posted question. From what I have grasped, all boils down to:

"Unless you have a thorough understanding of what's going on when using AVC for compressing DVDs, unless you're willing to spend hours or days tweaking the settings for each movie (effectively becoming a compressionist yourself) and until most decisions on parameters become more or less automatic (the future will tell) you're better off copying your DVDs ISOs to hard disks "as is", or reducing them in half with tools like CloneDVD. You'll need some extra space, but hard disks aren't that expensive these days..."

I guess I'm heading for a bigger disk array. In the end, when all those HD-DVD titles can be put on hard disks, I'll need even more, so I better start saving!

Thanks for a pleasant discussion and interesting points of view.

CM

[Shinjite]

:) Already there! I will test this tonight, or sunday. But I thought I would test the CoreAVC first. Reading this forum tells me that this should be more efficient.

Thank you for your input!

Recommended with CoreAVC as the decoder
FFDShow's h264 libavcodec's speed is still not up to par as what CoreAVC can achieve at the moment :)

[Morte66]

Re Mass DVD conversion for media server...

I've been down this road, to the tune of about 500 encodes so far, so here's what I think. IMHO etc:

1) If you want to build a media server for hundreds of DVDs, you've got to use some sort of MPEG4 encoder. The drive size and cost is prohibitive otherwise. MPEG2 backups are for people who burn DVD-Rs and put them in 400 disc wallets.

2) With the right setup (encoders runinng 24/7 in the background at low priority, good GUIs), slow encoders are relatively painless. They use the computer's time, rather than your time. But there is a point of diminishing returns on encoder settings -- you start getting 20% more compression for 3 times the encoder time or whatever -- so you have to pick a sweet spot.

3) As many people have said, Xvid vs X264 depends on the details of your specific material, the actual bitrate you're using, your settings, etc etc. You really have to try for yourself. FWIW, after 500 encodes with my "sweet spot" settings I ended up getting a file about half the size in double the encoding time with h264.

4) If you have a bright, contrasty LCD monitor which will reveal DGIndex and x264's block flicker problems in all their glory, you'll want to disable DGIndex's MPEG2 deblocking and use a custom x264 matrix, which will increase the file size by about 30-50%. See this thread (http://forum.doom9.org/showthread.php?t=113313) and this thread (http://forum.doom9.org/showthread.php?t=112968).

5) You don't need to hit an exact file size on a media server, that's for burning discs. So don't use a two-pass with a bitrate, use single pass constant quality mode on x264 (try the range 22 to 18) and constant quantiser on Xvid (try the range 4 to 2). This will give you faster encodes and will use a bitrate appropriate to each file (e.g. high motion action material will get more, talking heads in front of a wall will get less).

[Xvid at q2 is a special case -- it's pretty near perfect through sheer bitrate so you can turn all the clever stuff off, and thus get very fast encodes. You average about half the original size over the long term, with a huge variation per disc.]

6) Make anamorphic backups. Use the full resolution of the original DVD (720x480 for NTSC or 720x576 for PAL), and set an aspect ratio in the final mux to MKV/MP4. This way you only get one resize in the whole rip-to-view chain, during final playback. Don't let your software resize to 720x400 or whatever before encoding (lots of GUIs will try). This is a bigger deal than the fine points of encoder settings.

7) In the long run, I've averaged about 10MB/minute for 720x576 pixel DVD encodes using x264 on my crf 22 anti-blocking settings. I encode at about 7.5fps on a A64 X2 3800+. The encodes look better than the originals -- I gain far more from the Avisynth ColorMatrix filter and x264's inherent de-noising (noise desaturates colours) than I lose in the borderline-transparent compression.

8) Transparency is in the eye of the beholder. It depends on how fussy you are, how far you sit from the screen, how good your display is, and what material you're watching. When I started, I did some tests and decided that x264 at constant quality (crf) 24 was good enough for me, but I increased the quality to crf 22 to be on the safe side. After a year and several hundred encodes I bought a better monitor, and discovered that crf 24 wasn't good enough for me any more. I was very glad I'd allowed that safety margin. So think about the future...

9) FWIW, I mildly prefer MKV to MP4. It handles everything (including AC3), the muxer is faster, the files are a smidgeon smaller, and when you play it back it seems more resistant to skipping on a system that's under heavy load (useful for HD).

10) You have to make exceptions. Despite what I said about MPEG4 being the only practical solution for media servers, I still sometimes use DVD Shrink to back up to DVD-R. I've never seen any MPEG4 encoder that didn't suck (major shadow blocking) on the opening standup sketches in Seinfeld, for example.