LOTR: ROTK EE on 1 CD, what resolution would you use?

[Chainmax]

I plan on using Ogg Vorbis @ q3.5 for the soundtrack, which would leave ~284kbps for the video. The following x264 settings will be used: ABR, 5 reference frames, deblocking=0/0, chroma ME, all macroblock options, RDO level 2, uneven multi hexagon. The avisynth script will be very simple, just IVTC+Crop+Lanczos4Resize. First of all, I was wondering if it's a good idea to use bframes (I'd use 3 and enable adaptive, weighted, pyramid) on such a low bitrate. Then, I'd like to know if you'd rather use 640x272 or 528x224 and why.

[Revgen]

You shouldn't need any more than 2 b-frames when encoding 23.976FPS content. Uneven Multi-Hexagon is way too slow and doesn't improve quality that much. I'd suggest a regular hexagon search instead. IMHO The rest of the settings are fine.

Then I'd try using .MP4 Guy's matrix before trying to lower the resolution. FFDshow now supports CQM's so there even more reason to try it out.

Try Sharktooths EQM matrix if it's a 2 disc encode.

[Sharktooth]

3-bframes is ok. i would not use --subme 7 (RDO lvl2 in megui) though. Maybe 10+ reference frames with mixed refs option enabled.
ogg vorbis audio suppose the mkv container and 284kbps is way too high for stereo (unless you intend to encode all the 6 audio channels).
Also ABR mode is not too indicated. 2 passes will produce much better quality.

[Sagittaire]

LOTR: ROTK EE on 1 CD with Ogg at 284 Kbps ... ????!!!

Use High Profil with 5 ref and subme 6 or 7. IMO 720*400 with mod16 (720*304 for real image and 720*48 + 720*48 for black border)

Use LC-AAC with 2.0 at 80 or 96 Kbps for audio

[nm]

LOTR: ROTK EE on 1 CD with Ogg at 284 Kbps ... ????!!!
Chainmax said q3.5 for audio, which means under 128 Kbps. The 284 Kbps is left for video (the film is over 4h long) and therefore it may be better to use lower resolution than 720x304. And why would he encode the black borders?

Personally, I would use 64-80 Kbps for audio with Vorbis aoTuV b4. It should be better than LC-AAC.

[Chainmax]

What I meant was Ogg Vorbis @ q3.5 (~98kbps in my experience) for audio (and yeah, I would use aoTuVb4, I read guruboolez's tests :)), so video would have an average bitrate of 284kbps which is why I chose ABR over VBR.

Revgen: ffdshow now supports CQMs? When did that happen? Do Celtic Druid's build have that feature as well? About uneven multi hexagon, people around here seem to use it, are you sure the IQ increase is not worth the slower encoding?

Sharktooth: now that I clarified the video bitrate point, why not using RDO level 2? And would 3 bframes be a good idea for such a low bitrate?



Off topic question: is it ok if I only enable YV12 output colorspace on ffdshow's VFW codec and video decoder sections?

[Sagittaire]

you want use 100 Kbps for audio and 284 kbps for video ... it is not good audio-video bitrate repartition

1) first: use 64 Kbps or less with sbr codec like he-aac
2) second: use 310 Kbps 512*224 with high profil and best possible setting (2 bframe, subme 6/7, wpred, deblock 0, 5 ref ...)

And why would he encode the black borders?

Because if you respect mod16 for all part (real image and black boarders) the quality is exactly the same. I use 720*400 for all my movie (2.35 or 16/9). 720*400 is better for 2.35 movie + subtitle for example.

[nm]

Because if you respect mod16 for all part (real image and black boarders) the quality is exactly the same. I use 720*400 for all my movie (2.35 or 16/9). 720*400 is better for 2.35 movie + subtitle for example.
Not exactly. (http://forum.doom9.org/showthread.php?p=728534#post728534) But you have probably measured it, and the difference is quite small anyway. I also think it is the players job to position subtitles correctly so that they don't overlap with the video.

[Revgen]

Revgen: ffdshow now supports CQMs? When did that happen? Do Celtic Druid's build have that feature as well? About uneven multi hexagon, people around here seem to use it, are you sure the IQ increase is not worth the slower encoding?


clsid released his build in the ffdshow build thread. (http://forum.doom9.org/showthread.php?p=728688#post728688)

Celtic Druid hasn't released a CQM version yet.

Uneven multi hexagon is good for cartoons, anime, or any source that has alot of still scenes. Whoever suggested to you to try it was probably an anime freak ;) .

A full-motion movie like LOTR is not likely to benefit from it.

[rushin_911]

well I would suggest using -q 0 with autov beta 4, the encoding quality is really good (for that bitrate) and I personally perfer it over nero's he-aac at the same bitrate

as for the resolution I would go with 528x224 since the bitrate is going to be very low... although if you have some spare time and don't mind testing maybe you'd go with the higher resolution (would be interesting to see the results :) )

and I think the use of 3 b-frames would be appropriate (and with 3 b-frames I think you will be able to use the b-pyramid option)

good luck

[celtic_druid]

My next build will support CQM's. Should hopefully have time tonight to build it. Sounds like some of the other builds available are now as fast as mine anyway so no real need to wait.

[akupenguin]

Uneven multi hexagon is good for cartoons, anime, or any source that has alot of still scenes.
No, in still scenes all motion estimation methods give the same results (they still differ in speed, though). It doesn't take any searching at all to find mv=(0,0). UMH is better than Hex only in high-motion.
That said, high-motion anime may still gain more than high-motion live-action. "Motion" in anime is really an object appearing in one place in one frame and another place in another frame, so it's not guaranteed to be temporally coherent.

[Revgen]

No, in still scenes all motion estimation methods give the same results (they still differe in speed, though). It doesn't take any searching at all to find mv=(0,0). UMH is better than Hex only in high-motion.
That said, high-motion anime may still gain more than high-motion live-action. "Motion" in anime is really an object appearing in one place in one frame and another place in another frame, it's not guaranteed to be temporally coherent.

Okay so what your saying is that UMH is better for anime because anime has more motion than live action since the differences between the frames are greater?

If so then it's new to me. Thanks.

[Manao]

But you have probably measured it, and the difference is quite small anyway.If he did, it may be a trick : black borders improve the PSNR, because they are relatively more easily encoded. To accurately measure the difference, you'd have to add the borders, encode, and then remove the borders and compute the psnr.

[*.mp4 guy]

If speed is not an issue: 640*272, mixed refs, 16 reference frames, 3 max consecutive B-frames, Uneven multi hexagon search and motion search precision 7 along with all high profile features. Optional choices are deblocking strength and use of a cqm, I would recomend -3 alpha and beta deblocking along with my low bitrate cqm.

If speed is important to you, or you would rather have a more artifact free (and blurry) picture I would recomend reducing the resolution to 480*192 and using the above settings, possibly dropping to motion search precision 6, hexagon search and 8 references if speed is very important to you.

Using two passes and fast first pass is always a good idea.

[Sagittaire]

IMO 640*272 ~300 Kbps is more than q30 for average quant with LOTR 1CDR -> very poor quality in all case with x264

[Leo 69]

For audio: I would advise 48 kbps parametric stereo AAC+ v2 or Ogg Vorbis Aotuv b4 @ -q2. Both variants give almost transparent audio, as for a movie. No need to go higher, especially in this case.

For video: Apart from what *.mp4 guy said I would advise to use some light, but effective denoising, then the needed bitrate may fall down by 30 % without noticable difference in image quality. I recommend to use motion compensated denoising.
You need DePan plugin from Fizick http://bag.hotmail.ru/depan/depan17.zip
And FluxSmooth.

Use this in the script, just nothing else, it should be enough

-----------------------
i=converttoYV12()
mdata=DePanEstimate(i)
DePanInterleave(i,data=mdata)
fluxsmoothT(10)
selectevery(3,1)
-----------------------

[Chainmax]

Sagittaire: I do agree with you that audio having over 1/3 of video bitrate is not a good repartition, but even though my hearing is quite crappy I trust guruboolez's tests. Besides, this rip is going to go around so that people see how good AVC is for such low bitrate conditions. So I have to stick with ~98kbps Ogg Vorbis aoTuVb4 audio.
About subtitles, I plan on muxing the IDX and SUB files, so subtitle position can easily be changed and therefore encoding the black borders won't be necessary.

akupenguin: this movie has lots of motion, so I'll keep UMH. How does it compare to plain Hex in low motion?

*.mp4 guy: 16 reference frames? Isn't that overkill? Almost everyone here recommends not to go over 5, 8 at most...Also, I don't think deblocking stronger than 0 is needed for such a clean movie, especially if I was to use your CQM.

Leo69: deblocking will already kill too much detail, there's no need for denoising in my opinion.



So, following everyone's recommendation, I will encode two 1min clips:

1) 640x272; 2 pass VBR; 5 reference frames (mixed); 3 bframes (adaptive, weighted, pyramid); deblocking=0/0; chroma ME; all macroblock options; RDO level 2, uneven multi hexagon, *.mp4 guy's CQM.

2) 528x224; 2 pass VBR; 5 reference frames (mixed); 3 bframes (adaptive, weighted, pyramid); deblocking=0/0; chroma ME; all macroblock options; RDO; uneven multi hexagon.

And post them here for you guys to give me feedback on.

[Sharktooth]

16 refs with mixed refs option enabled is quite usefull for compression while 5 is almost useless :)
dont forget to enable 8x8 transform and all macroblock partitions.

[Chainmax]

So, it's either 5Refs or 16Refs+Mixed, right? By the way, isn't 8x8 transform one of the macroblock options?

[Sharktooth]

no... 8x8 transform is the -8 (or --8x8dct) option.

[bond]

For audio: I would advise 48 kbps parametric stereo AAC+ v2 or Ogg Vorbis Aotuv b4 @ -q2. my opinion too

[DigitalDivide]

Just curious, is the mixed ref option mostly for high compressions? Or would you always want to use it. I encode all my movies to a target file size of 2GB, 3 B Frames, 8 Ref Frames, Uneven Multi Hex, 5 High Quality. Just sweet and simple. I don't care to play around to much. Just line up my movies and encode. Just wondering if I should be checking the mixed ref box?

[Leo 69]

DigitalDivide

http://forum.doom9.org/showthread.php?t=101056

[Chainmax]

So, if I don't use mixed references then 5 reference frames is still the standard?

[Chainmax]

no... 8x8 transform is the -8 (or --8x8dct) option.

...which comes from enabling the last two macroblock options.

[Blue_MiSfit]

What I've found to be VERY hit or miss denoising is the lovely LRemoveDust script. It calls MaskTools, RemoveGrain, and Repair. I have found it (in most cases) boosts compression by about 30% with little to no slowdown or blurring. Of course, results vary, sometimes it makes a blur-fest, sometimes it's incredibly sharp and detailed with no noise. I think ROTK EE would be a great candidate for LRemoveDust, because I assume it is a very clean picture to begin with like the other LOTR movies. I remember encoding Lemony Snickett's A series of unfortunate events which was an excellent DVD transfer that preserved film grain nicely with little noise. I used LRemoveDust(4,1).RemoveGrain(mode=1) and was quite literally unable to tell the difference between the DVD and the resulting 1/4 DVD sized MKV :)

The speed is incredible, even with its filtering and high x264 settings (see below) I usually average 6-7fps on secondpass with my 2800+ A64, which is similar to the speed I get when I just feed x264.exe an avs with nothing more than an MPEG2Source. From what I understand, the effect is similar to PixieDust, but it's very optimized, becuase you can use RemoveGrainSSE2 and RepairSSE2 or even SSE3 if you have a prescott p4 or newer / venice athlon64 or newer.

Recently for my encodes I have been doing full resolution, with 2 max bframes, msp6 (rdo), all hp options, mixed refs, 6+ total refs, and -1,-1 for deblocking, and usually LRemoveDust(4,1).RemoveGrain(mode=1) for denoising.

However, in this particular scenario, with a very very small (bits/pixel)*frame ratio, would not higher deblocking values be apropriate? perhaps 2,2? I suppose lots of comptests would be needed in order to test various settings. I would also have to suggest a lower resolution, something in the 640x... or 512x... range.

How long is the EE? About 4 hours?? I wouldn't expect stellar quality out of a 700mb CD, but the mere fact that you can reduce (probably) close to 10 gb of MPEG-2/AC3 VOB down to 700mb of AVC/(AAC/Vorbis) Matroska and have the quality still be watchable is incredible. Can't wait for AVC and blu-ray/ HD-DVD!!

Sounds like a fun project, I wonder if I could fit the whole ROTK EE at QCIF resolution on my 256mb transflash card using xvid for my cell phone with good quality? :) If only it was capable of playing AVC.

Good luck
-MiSfit

[DigitalDivide]

Thanks, I'll give mix refs a try on ...hmm X-men and see what happens.

[Chainmax]

Blue_MiSfit: I know about the LRemoveDust function, but since I'll already be using inloop I prefer not to denoise, otherwise too much detail will be killed. By the way, if you use a resolution of about 256x112 with the eqm_v3ulr matrix and Ogg Vorbis aoTuVb4 @ q1 (~32kbps) together with some slight denoising (I'd recommend FFT3DFilter(sigma=1)), you could probably pull off a somewhat decent looking 256MB rip.

[Blue_MiSfit]

@Chainmax:

Interesting. You would rather increase the in-loop deblocker rather than do heavier pre-filtering?

Can't say that I ever thought of that. I will have to try it out.

~MiSfit

[Tuesday]

Have you thought about using XCD www.doom9.org/xcd.htm

If you insist on sticking to 1CD, then you may as well try to make the most out of it.

IMHO they're just as reliable as normal discs so long as you don't throw them around too much.

[Leo 69]

:) Besides there are 800mb CD-Rs and even up to 900mb if you are lucky enough to find such.

[Chainmax]

Blue_MiSfit: actually, that's the other way around. I feel inloop kills too much detail and while that actually helps on animated content, it probaly isn't the case with live action footage. Therefore, I prefer slight denoising (or lower target resolution) rather than increasing inloop strength. Then again, I never really made a full x264 encode.

Tuesday, Leo 69: well, I already have the original DVDs, this is just meant as a fun exercise and proof of concept for a disbeliever friend of mine. If I wanted backups, I'd probably be encoding each movie to a single DVD-R, upsize to 1280x544 using IIP with settings posted a long time ago by Gn0m0rz and keeping the DTS track :). The process would probably take me several days to finish though :).