View Full Version : Large AVC Project... Thoughts Welcome!
Dayvon
26th January 2006, 23:39
Lord Of The Rings Extended Project
Phase 1: COMPLETE
Goal = A high quality MP4 version of the Lord Of The Rings Extended DVD's all stored on one DVD/DL (8150MB limit).
Stats:
Fellowship_w/o credits = 3h20min Total (Est: 2403MB)
Two Towers_w/o credits = 3h35m Total (Est: 2583MB)
Return_w/ credits = 4h23m Total (Est: 3158MB)
GRAND TOTAL = 11h18m (Est: 8146MB)
Example Script:
LoadPlugin("D:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
mpeg2source("H:\DVD TEMP\LOTR_EE_Fellowship_D2\VIDEO_TS\Fellowship_D2.d2v")
crop(0,58,720,358)
LanczosResize(880,368)
Recommended Settings:
#1
x264 1350kbps AVC High Profile
x264.exe --pass 2 --bitrate 1350 --stats ".stats" --ref 3 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --progress --no-psnr --output
NAAC 320kbps CBR LC-AAC 5.1
BeSweet.exe -core( -input "" -output "" -logfilea "" ) -azid( -c normal ) -bsn( -6chnew -cbr 320 -codecquality_high -aacprofile_lc -exportaac ) -ota( -d 0 -g max )
#2
x264 1320kbps AVC High Profile
x264.exe --pass 2 --bitrate 1320 --stats ".stats" --ref 3 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --progress --no-psnr --output
NAAC LC-AAC VBR 5.1 Internet Q
BeSweet.exe -core( -input "" -output "" -logfilea "" ) -azid( -c normal ) -bsn( -6chnew -vbr_internet -codecquality_high -aacprofile_lc -exportaac ) -ota( -d 0 -g max )
#3
x264 1450kbps AVC High Profile
x264.exe --pass 2 --bitrate 1450 --stats ".stats" --ref 3 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --progress --no-psnr --output
NAAC 224kbps CBR LC-AAC Stereo DLP2
BeSweet.exe -core( -input "" -output "" -logfilea "" ) -azid( -s dplii -c normal -L -3db ) -bsn( -6chnew -cbr 224 -codecquality_high -aacprofile_lc -exportaac ) -ota( -d 0 -g max )
Mux using YAMB 1.4 w/ Mp4Box
Results of #3:
http://img90.imageshack.us/img90/3231/webbalrog3xj.th.png (http://img90.imageshack.us/my.php?image=webbalrog3xj.png)http://img100.imageshack.us/img100/7820/webwater9mo.th.png (http://img100.imageshack.us/my.php?image=webwater9mo.png)http://img100.imageshack.us/img100/7214/webwaterfall2tn.th.png (http://img100.imageshack.us/my.php?image=webwaterfall2tn.png)
http://img208.imageshack.us/img208/9226/webrainorc8lg.th.png (http://img208.imageshack.us/my.php?image=webrainorc8lg.png)http://img208.imageshack.us/img208/3794/webrain0qg.th.png (http://img208.imageshack.us/my.php?image=webrain0qg.png)http://img81.imageshack.us/img81/937/weborc2vu.th.png (http://img81.imageshack.us/my.php?image=weborc2vu.png)
http://img99.imageshack.us/img99/5051/webstable6ir.th.png (http://img99.imageshack.us/my.php?image=webstable6ir.png)http://img207.imageshack.us/img207/5566/webgaladriel8fh.th.png (http://img207.imageshack.us/my.php?image=webgaladriel8fh.png)http://img99.imageshack.us/img99/7196/webtheoden5yq.th.png (http://img99.imageshack.us/my.php?image=webtheoden5yq.png)
More Pictures: Two Towers Small Sampling__5MB.zip (http://church.crossingatwoodland.com/Temp/download/Two Towers_5MB.zip) - Two Towers Large Sampling__15MB.zip (http://church.crossingatwoodland.com/Temp/download/Two Towers_15MB.zip)
Path Summary:
Original Purchased DVD -> DVDShrink 3.2 (no compression, movie only) -> Hard Disk -> DGIndex
Video Path -> MeGUI AVSynth Script Creator -> Encode -> Output x264 raw
Audio Path -> BeLight -> Encode -> Output AAC raw
Mux Path -> YAMB 1.4 Mux A&V -> YAMB 1.4 Join MP4 (Disc's 1 and 2 together, or entire set)
PHASE 2: PrePlanning
Goal = Each movie, higher than DVD quality as an MP4 file each on a DVD-R Disc. Maximum HD-Quality.
1360x560 Resolution
LimitedSharpen
FluxsmoothST
Lanczosresize
AVC - 2000kbps_x264
LC-AAC - 320+kbps_NAAC
YAMB - Mp4
More Info Coming Soon......
__________________________________ORIGINAL_PROJECT_POST_BELOW__________________________________
I've been considering doing something for quite sometime, and now, I'm really thinking of doing it. Lord of the Rings Extended. I've wanted to make an Mpeg4 - high quality version of these to fit on my computer/DVD backup for a while. Since I have now come to be fairly proficient with MeGUI, x264, Belight + AAC, and Mp4Box, I've come to the conclusion that now is the time. So here is my step-by-step plan.
1. Quality requirements.
- Good quality video for HDTV. x264 has allowed me to find bitrates down to about 1000kbps to be acceptable. 1500 kbps is the goal. I find this necessary especially when viewing from an HDTV.
- 5.1 surround sound. Got to keep the surround audio for the immersive experience. This means AAC, DTS or AC3.
- MP4 container-compliant. MP4 for future mindedness. Compliant for the same reason. This means that AVC and AAC are the way to go.
- No chapters or subtitles necessary. This is the way I roll. I just dont need 'em.
2. General Overview
- The overall length of the film(s) will be approx 11hrs19min. Using MeGUI's Bitrate calculator I found that at CBR 320kbps audio, an x264 MP4 would achieve about a 1350kbps rate to fit the files on an 8150MB DVDDL. This means that potentially, I can hit close to my desired quality and fit it all (678 min) onto 1 DVD-DL.
- The only question that remains is, should I join all the movies into one big 11hr MP4 file? This is something I haven't figured out yet, and would love advice on. I know that YAMB would potentially allow it, but I don't know if that's the wisest move. My plan right now, is to have 3 mp4 files, one for each movie.
3. Video
- My program path: DVDShrink -> DGIndex -> MeGUI -> .264 file
- I'm planning on cropping and lancos resizing via AVSynth. Files will be resized to 880x360 to keep as much of the vertical information as possible.
- I'm using 2-pass encoding obviously, but I'm not sure what other x264 settings I should use. I don't want to have these encodes running forever, yet I want the quality to be high, cause I dont want to wish later that I had encoded better.
- I'm not planning on keeping all the credits for space's sake. I am however keeping the Return of the King's credits, being that they have the hand-drawn pictures and such. Each intro will be played accordingly however.
4. Audio
- My program path: DVDShrink -> DGIndex -> BeLight -> aac file
- I'm planning on using nero aac encoder.
- There have been audio sync problems with most people's combining of Disc 1 and 2 for each set, but since I've been cutting the end and beginnings of each very tightly, I expect to have a fairly easy time with video sync.
5. Muxing
- My program path: .264 file + aac file -> YAMB -> Join MP4's in YAMB
- I will have six different encodes on this project, and these will be muxed into three MP4 files. This will require muxing and joining in YAMB.
6. DVD Burning
- Nero Data Setting
I expect this project to have complete success. As I run into problems or other hang-ups, I'll be posting them here. If you have questions, suggestions, or comments please post 'em, I'll read 'em.
DISCLAIMER: I don't know if anyone cares what I'm doing, but I thought I'd share as this seems like a really cool project to me. Anyways, have a good one!
Sirber
26th January 2006, 23:41
Are you making a GUI?
Dayvon
26th January 2006, 23:45
Are you making a GUI?
No. I think this project is self explanatory. There isn't a thread to generally discuss encoding projects, so I put it here.
MOD's: Feel free to move this to the appropriate sub-forum.
Doom9
27th January 2006, 00:08
Files will be resized to 880x360 Umm.. I thought you'd be using a DVD as source and DVDs are limited to 720 pixels horizontal so it makes no sense to go any higher than that.
Dayvon
27th January 2006, 00:18
Umm.. I thought you'd be using a DVD as source and DVDs are limited to 720 pixels horizontal so it makes no sense to go any higher than that.
Right you are. But the vertical resolution of the video is about 360 pixels, while the horizontal pixels are stretched. This means if I stick to the 2.44:1 ratio, then I would have 720x294 resolution which means I would be losing about 65 pixels of vertical info because of downsizing. Correct me if I'm wrong here but wouldn't my setting potentially have higher PQ?
foxyshadis
27th January 2006, 03:03
Well, you could just use anamorphic encoding. You only have 720 source horizontal pixels, so creating extra information is going to drag down quality somewhat. When you're hitting that kind of bitrate with AVC you're probably within the anamorphic confort range. (Of course anamorphic playback isn't always perfect... but there's a current thread on solving that in this forum.)
berrinam
27th January 2006, 03:10
- I'm planning on cropping and lancos resizing via AVSynth. Files will be resized to 880x360 to keep as much of the vertical information as possible.What you should really do then is encode it anamorphically. This means that you could encode it at the same resolution as the DVD was at, keeping all the resolution without wastefully upsizing horizontally. Read through this thread to get an idea of how to do it: http://forum.doom9.org/showthread.php?t=105809
Here is my current commandline.
_______________________________________________________________
D:\Program Files\x264\x264.exe --pass 2 --bitrate 1440 --stats ".stats" --ref 3 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -3,-3 --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,p4x4 --threads 2 --progress --no-psnr --output "" ""
_______________________________________________________________
I have a few gripes with that:
-You aren't using High Profile (8x8dct, specifically). You could get a considerable improvement by going up to High Profile. I really recommend it.
-Your value for the deblocking filter (-3,-3) is very low. You may want to consider raising it.
I would really recommend using one of Sharktooth's HQ profiles (HQ-Slow is probably the best for you, as it is the fastest of them, you have a very long encode, and the quality is still very good).
Also, from the location of x264.exe in Program Files, it looks like you are using MeGUI x264 (limited) edition. You should try looking at the full version, because it adds integration of besweet/nero audio encoding (just the same as you are doing with BeLight), DGIndexing, mp4 muxing with mp4box (but not joining. Is it really worth joining the 3 files, though?). If you need help on using MeGUI, have a look at my guide: http://forum.doom9.org/showthread.php?p=773259#post773259
*.mp4 guy
27th January 2006, 06:53
At that bitrate there shouldn't be any noticible blocking, I've gotten good looking 1 cd rips using -3:0. Deblocking is more personal preference then anything else.
Dayvon
27th January 2006, 07:34
What you should really do then is encode it anamorphically. This means that you could encode it at the same resolution as the DVD was at, keeping all the resolution without wastefully upsizing horizontally. Read through this thread to get an idea of how to do it: http://forum.doom9.org/showthread.php?t=105809
I have a few gripes with that:
-You aren't using High Profile (8x8dct, specifically). You could get a considerable improvement by going up to High Profile. I really recommend it.
-Your value for the deblocking filter (-3,-3) is very low. You may want to consider raising it.
I would really recommend using one of Sharktooth's HQ profiles (HQ-Slow is probably the best for you, as it is the fastest of them, you have a very long encode, and the quality is still very good).
Also, from the location of x264.exe in Program Files, it looks like you are using MeGUI x264 (limited) edition. You should try looking at the full version, because it adds integration of besweet/nero audio encoding (just the same as you are doing with BeLight), DGIndexing, mp4 muxing with mp4box (but not joining. Is it really worth joining the 3 files, though?). If you need help on using MeGUI, have a look at my guide: http://forum.doom9.org/showthread.php?p=773259#post773259
Thanks sooooo much. I totally did not notice that I hadn't enable high profile. I had selected ALL in the tab for those 8x8, 4x4 thing, but I had to enable it in the screen before. Generally, I like less deblocking. I find it smears too much for my tastes.
Oh, and I am using MeGUI, NOT the x264 version. I like to put my codecs where I can find them and use them from there. :)
kotrtim
27th January 2006, 09:41
Oh, and I am using MeGUI, NOT the x264 version. I like to put my codecs where I can find them and use them from there.
You can copy the profile folder from shartooth's megui-x264 folder:profile and also folder:data , you can normally get it here "C:\Program Files\x264\" and those 2 folders mentioned to the same directoty as your MeGUI, you'll have all the presets made by shartooth....pretty easy , don't have check the options, just simply go for HQ profiles if high quality what you are looking for.
-s dplii, remove this line!!
use this
-azid( -c normal )
my suggestion is
audio: Nero LC-AAC streaming ~ 400 kbps... 256 kbps is too low
make sure it is nero 6, if you are using nero 7, the command line you used for besweet will produce wrong channel mapping
video: ~1300 kbps, keep the original resolution, apply no resize filter, use picture aspect ratio features of mp4...I'm sure you'll get the encode done at quantizer lower than the default 26 at such high bitrate.
bkman
27th January 2006, 09:53
Why not HE-AAC?
Dayvon
27th January 2006, 17:33
@bkman
As far as I've found HE-AAC sounds not so good (to my ear). If I was converting from a 5.1 WAV source, then it'd probably be ok, but from compressed AC3 it doesn't cut the quality for me.
@kotrtim
256 is a bit low I agree. However, going to 320kbps means lower than 1400kbps on video.... So the sacrifice has to be made somewhere. I tried out the 256 CBR 5.1, and the rear channels are somewhat artifacing when you listen to them alone, however, when you listen to the whole mix it sounds fine. Not great, but fine. Good enough to not notice when engrossed in the movie.
I really wish that there was either 2-pass AAC encoding or an ABR setting. The streaming-internet-radio-settings I can't find bitrate information on but I assume they are a VBR constant quality-type setting and don't hit a certain filesize. If I could use a VBR setting and hit approx 256 CBR file size, I want that.
@Everyone
Thanks so much for the info on Sharktooth's presets. I do have them, but I like to get down and dirty with the codecs. I got a good idea what I'm doin' so well see in about 1hr when the first Fellowship disc is done.
Cheers!
EDIT: So the encode finished and the first muxing just got done. I think it looks great aside from some blocking issues in certain cloud type things. The audio and video quality are really great though. This is a great project and quite the example for how awesome AVC, AAC, MeGUI, and the MP4 standard are compared to the DVD standard. I'm gonna keep rollin' with this, I'll let you all know how it goes.
*.mp4 guy
28th January 2006, 04:14
If the blocking occurs a lot you might want to try a cqm on a sample clip and see if you like it better (make sure to test your original settings on the same clip aswell to make sure that you get accurate results)
iceborne
28th January 2006, 10:45
why don't you transcode the dts file to acc instead. the source is a lot cleaner than ac3
[)370|\|470!2
28th January 2006, 14:30
I'd suggest using DPLII instead of 5.1. It restores 5.1 sounds almost perfectly,
especially when using an external Dolby amplifier. And @ 256kbps it'll sound nice
both as 2.0 and surround-restored.
Dayvon
28th January 2006, 22:22
Update....
Well Fellowship Extended Edition is compressed, cut, muxed, and joined successfully!!! I had a bit of trouble with the sync when joining the first 2 discs. I started Fellowship Disc 2 on the first frame which introduce a 240ms sync issue. I anticipate less issue with the other discs since I didn't start any of the other discs on the first frame.
Other notes of interest include, a 2453MB final size with a length of 3hr20m35s (credits cut) and that's with 1450kbps and 256kbps bitrates.
I may consider redoing the audio after the initial run depending on how much extra space I end up with. Or maybe I'll redo using MP3 and DPL2.
why don't you transcode the dts file to acc instead. the source is a lot cleaner than ac3
I've never really heard of using the DTS as your source. I suppose I could... How much better would it be than using the AC3?
Anyway, thanks for all your input. I'll let you all know how it goes.
kotrtim
29th January 2006, 14:33
DTS = 768 kbps
AC3 = 448 kbps
the bitrate difference is quite large, DTS is of course better
Besweet supports DTS, but you'll need to have a WinDVD (pay ware) installed. Decode can only be done in 1X....very slow......
Otherwise, try foobar's DTS playback plugin (libdts) & nero encoder plugin, free! the faster your processor, the faster it decodes
I may consider redoing the audio after the initial run depending on how much extra space I end up with. Or maybe I'll redo using MP3 and DPL2.
He-AAC, are you using Nero 6 He-AAC?, yeah it is truly bad, outdated....but Nero 7 He-AAC is so much better, it doesn't have those horrible artefacts that Nero 6 has
Or you can also use Winamp's He-AAC, it's one of the best He-AAC
[)370|\|470!2
29th January 2006, 20:02
He-AAC, are you using Nero 6 He-AAC?, yeah it is truly bad, outdated....but Nero 7 He-AAC is so much better, it doesn't have those horrible artefacts that Nero 6 has
Oh really? I'd say it's sux the exactly same way as before. Dimkovic should retire. Pity. :devil:
Or you can also use Winamp's He-AAC, it's one of the best He-AAC
Yea. He may also consider to encode his video @ 200kbps. xD
Dayvon
29th January 2006, 20:09
LOL. Well guys, I'm actually using LC-AAC as I can't stand the sound of HE-AAC. At the 256 CBR, it doesn't sound half bad. I can hear it if I'm listening for it, but I think it is that way with almost any codec from AC3.
I'm trying the different VBR settings (radio-internet-streaming) to see if I can hit my file size and get a better sound than the 256 CBR. Hopefully, my encodes might be a bit smaller than they were estimated at. The calc said to use 1459kbps AVC but I like round numbers and also like to give some space so I ran them at 1450kbps. Hopefully, I might have enough room to squeak out 320kbps LC-AAC 5.1 sound. That would make it all better. :)
Oline 61
30th January 2006, 00:29
Dayvon, my I inquire as to how you are going about IVTC on "The Fellowship of the Ring"? For me Telecide or TIVTC produced strange red artifacts, and Force Film in DGIndex left behind a few interlaced frames. How are you doing it?
foxyshadis
30th January 2006, 02:10
HE-AAC is designed entirely for < 64kbps (or < 128kbps 5.1), getting relatively better the lower you go, so it makes sense that it sounds terrible at those bitrates. =p
kotrtim
30th January 2006, 03:41
Oh really? I'd say it's sux the exactly same way as before. Dimkovic should retire. Pity.
You can listen it yourself, it really does improve a lot...
Soulhunter
30th January 2006, 05:17
Umm.. I thought you'd be using a DVD as source and DVDs are limited to 720 pixels horizontal so it makes no sense to go any higher than that.
Pardon!? (http://forum.doom9.org/showthread.php?p=568512#post568512) ^^
Bye
[)370|\|470!2
30th January 2006, 13:35
You can listen it yourself, it really does improve a lot...
Of course i did. Tested with aacenc32.dll ver.4.2.2.3, compared to ver.4.2.0.27
(nero7 vs nero6). Both samples @ 64kbps sounds disgusting. Even LC imho sounds better
at this bitrate. And oggenc aotuv beats them all. But enough offtopic. :sly:
Dayvon
30th January 2006, 16:09
I don't mind the off topic. Audio quality to me is just about as important as the visual quality.
I watched thru The Fellowship, and I really didn't mind the LC-AAC @ 256kbps. Not that I couldn't hear the artifacts, but that it didn't bother me much. When I focused on listening for it, I could here it with certain voice textures, in quite a few musical string passages and lack of high-pitch detail in the rear speakers.
Just for testing purpose sake, I'm doing my first cut of Return of the King using MP3 256kbps w/ DLP2. Obviously this will help with the string passages and the vocal textures. I'm hoping that I don't lose to much directional information.
Is there an audio filter I can use to decode DLP2? I need it to decode in the player since my external won't exactly decode DLP2.
_________________________________________________________________
Oh, and BTW, I've now finished the Two Towers encode. Length = 03h34m49s. Size = 2627MB.
Lord Of The Rings total length so far = 06h55m24s Size = 5080MB
Total GOAL Size = 8373MB
Return of the King max size = 3293MB__ Estimated length = 04h23m03s
Should be right on track!!
_________________________________________________________________
Thanks everyone!
[)370|\|470!2
30th January 2006, 16:15
FFDShow has Dolby decoder, just enable it and configure I/O.
Dayvon
30th January 2006, 16:23
I thought it did. Thanks ;)
nm
30th January 2006, 16:26
Yes, FFDShow has a Dolby Pro Logic decoder, but it doesn't decode Pro Logic II properly (discussion about DPL2 decoding here (http://forum.doom9.org/showthread.php?p=771207#post771207)). So you'll get the same results with it as with an external DPL1 decoder.
Dayvon
30th January 2006, 17:25
Dayvon, my I inquire as to how you are going about IVTC on "The Fellowship of the Ring"? For me Telecide or TIVTC produced strange red artifacts, and Force Film in DGIndex left behind a few interlaced frames. How are you doing it?
I haven't had any interlaced issues. I do have one spot in Two Towers Disc2 at the very beginning where there is about 10 frames that are interlaced, but that's it. I've had no problem with Fellowship (Disc1 or 2) watched the enitre 3h20m last night. All I did was force film in DGIndex.
Maybe you need to get latest version of DGIndex?. I have 1.4.3
In terms of DLP2....
I tried using the ffdshow Dolby digital decode, but the rear output sounds a bit funny to me. Almost like it has a tremolo on it (volume rising and lowering quickly and at a constant rate). I checked more forum stuff, and it seems that ffdshow does not do DLP2 decoding properly. Wondering if anyone can shed some more light on this issue?
nm
30th January 2006, 17:30
I tried using the ffdshow Dolby digital decode, but the rear output sounds a bit funny to me. Almost like it has a tremolo on it (volume rising and lowering quickly and at a constant rate). I checked more forum stuff, and it seems that ffdshow does not do DLP2 decoding properly. Wondering if anyone can shed some more light on this issue?
Did you check the discussion I linked to above?
Dayvon
30th January 2006, 17:42
Yeah. Specifically wonderbra says, "Keep in mind that DPLII decoding is done by hardware AC3 decoders, there is no codec or software that really provides true DPLII decoding, since the matrixes (as simple as they are) are not properly implemented yet by any software decoder."
I have an USB external sound card that does AC3 decoding and sends the surround info to my Logitech Z-560's via analog 1/8 inch plugs. My sound card doesn't decode the DLP2.
Should I be using ffdshow to decode DLP2, or AC3filter? Or should I get those speaker I've wanted? :D http://www.pricegrabber.com/search_getprod.php/masterid=4117156/sort_type=bottomline
nm
30th January 2006, 17:51
Should I be using ffdshow to decode DLP2, or AC3filter? Or should I get those speaker I've wanted? :D http://www.pricegrabber.com/search_getprod.php/masterid=4117156/sort_type=bottomline
Try both and use whatever pleases you most. For most purposes DPLII is inferior to DD 5.1 and in some cases to 5.1 LC AAC @256kbps, so I wouldn't buy new hardware just because of it.
Dayvon
30th January 2006, 17:57
I've been wanting to upgrade to those speaker for a while anyway. But, yeah, I'm thinking that I'll stick with the LC AAC. If only there was a way to get ABR LC-AAC 5.1 !!!!!!
Oh and if I want to do DLP2 in the future, should I pull my source from a DD 2.0 or DD 5.1 AC3?
nm
30th January 2006, 18:13
Oh and if I want to do DLP2 in the future, should I pull my source from a DD 2.0 or DD 5.1 AC3?
5.1 certainly, but the DD 2.0 track could already be in DPL2, in which case you can use it as is, or re-encode if it is too large or you have difficulties with putting an AC3 track into your container.
Doom9
30th January 2006, 18:51
Pardon!? ^^there are plenty on-the-fly resizers that you can use if you really care. It is basically possible to do all the filtering didee applies before encoding after encoding.. thus leaving it up to the very same algorithms to get the picture to the desired size.
The thread you linked to does not take into account the severe bits/pixel deficit you incurr when you upsize prior to encoding. And on top of that, to be fair you'd have to apply the whole filter chain except for resizing to a non resized encode as well.
Soulhunter
30th January 2006, 21:05
there are plenty on-the-fly resizers that you can use if you really care. It is basically possible to do all the filtering didee applies before encoding after encoding.. thus leaving it up to the very same algorithms to get the picture to the desired size... ...And on top of that, to be fair you'd have to apply the whole filter chain except for resizing to a non resized encode as well.
Veto! :) It can make a big difference if you apply a filter before or after upsizing (as Didèe tried to show with his example) and as such "advanced filtering" doesnt run in realtime (not even with the most recent cpu) you cant do it on-the-fly!
The thread you linked to does not take into account the severe bits/pixel deficit you incurr when you upsize prior to encoding.
Ditto! :) Yes, of course the upsized version is less compressible than the small one! So at a low-mid bitrates (<- yes, very vague... lets say 1-3CD ASP / 1-2CD AVC encodes) the upsized one will have more artefacts, but also more MVs and smaller blocks (yes, only a minor benefit). But at higher bitrates (where compression artefacts arent visible anyway) it will only lose some of the details you enhanced before. IMO: In the first case its probably a matter of taste (details -vs- artefacts... just like with h.263 -vs- MPEG or XviD -vs- DivX). But for the second case I can confirm that the "upsized->filtered" version will look better than "filtered->upsized" one! Tho a compare of both methods would make a interesting subject for a future blindtest... ^^
Bye
nm
30th January 2006, 22:01
Veto! :) It can make a big difference if you apply a filter before or after upsizing (as Didèe tried to show with his example) and as such "advanced filtering" doesnt run in realtime (not even with the most recent cpu) you cant do it on-the-fly!
Perhaps you can't run some insane "advanced" filtering, but for example lanczos resizing runs just fine on-the-fly, even on not-so-recent processors. Didèe's example showed the results of bad (hardware) bilinear filtering and compared that to a hand-crafted example of the desired result. Even plain lanczos resizing would have been much better, and that still leaves room for other filtering. Of course you can argue that people want to display the video with standalones or hardware-assisted decoders, but then, people do stupid things ;)
I'm very sceptical that you would get better results with any filtering and upsizing prior to encoding compared to normal high-quality realtime resizing of the encoded video. It would be nice to see blind-test results or even some samples for testing.
guada 2
30th January 2006, 22:05
Yes... "Soul "
Very interesting like comparison.
It would be well to make this test on a source of bad quality.
But I suppose that it is only useful on low bitrate.
Interesting, but the time of encoding is it the same in the 2 cases?
To check too.
IgorC
30th January 2006, 22:18
Of course i did. Tested with aacenc32.dll ver.4.2.2.3, compared to ver.4.2.0.27
(nero7 vs nero6). Both samples @ 64kbps sounds disgusting. Even LC imho sounds better
at this bitrate. And oggenc aotuv beats them all. But enough offtopic. :sly:
It was public blind test. http://www.rjamorim.com/test/64test/plot12z.png
http://www.rjamorim.com/test/64test/results.html
Since then HE and LC profiles were impoved both . The difference is here.
Soulhunter
30th January 2006, 22:34
I'm very sceptical that you would get better results with any filtering and upsizing prior to encoding compared to normal high-quality realtime resizing of the encoded video...
Then you probably never used filters like LimitedSharpen (http://forum.doom9.org/showthread.php?t=84196) or IIP (http://forum.doom9.org/showthread.php?t=70916)!?
Socio posted a interesting compare some time ago...
Source:
http://img147.exs.cx/img147/3656/nosharpen6xy.jpg
LimitedSharpen + IIP
http://img48.exs.cx/img48/1732/ls2iip7mr.jpg
Interesting, but the time of encoding is it the same in the 2 cases?
More resolution = More pixels to filter = More cpu cycles needed = Slower ;)
Bye
guada 2
30th January 2006, 22:59
@Soulhunter
Why LimitedSharpen + IIP? and not IIP + LimitedSharpen ?
Could you explain please?
nm
30th January 2006, 23:03
LimitedSharpen and IIP have little to do with actual resizing. You can as well use them on the source before encoding without resizing and get similar results, like Doom9 already said above.
Soulhunter
30th January 2006, 23:09
LimitedSharpen and IIP have little to do with actual resizing. You can as well use them on the source before encoding without resizing and get similar results, like Doom9 already said above.
Nope, and thats what Didèe tried to explain with his example...
Filtering -> Resizing cant achieve the same results as Resizing -> Sharpening!
@Soulhunter
Why LimitedSharpen + IIP? and not IIP + LimitedSharpen ?
Could you explain please?
Well, ask Socio! He posted the samples... ;)
Bye
nm
30th January 2006, 23:20
Filtering -> Resizing cant achieve the same results as Resizing -> Sharpening!
I agree, but you are now leaving the encoding part out of the equation. I also agree that if you resize before encoding and give it as much bitrate as it needs (with a fixed quantizer for example), you can get better results. What I don't agree with is that you could use the same bitrate (one that is enough for the not-resized source) for both encodes and the resized one would look better.
You can also sharpen after resizing on-the-fly with a decent processor. Again the algorithms may not be as high quality, but the result would still be better compared to watching the encoding artifacts.
guada 2
30th January 2006, 23:33
"Soul.."
After a small test:
Limitedsharpen+IIP: picture is more fluid, luminous and more matter than IIP+Limitedsharpen.
Strange but it's true.
maybe, Socio or Didée have an idea ?
:thanks: Soulhunter ;)
Soulhunter
30th January 2006, 23:39
I agree, but you are now leaving the encoding part out of the equation. I also agree that if you resize before encoding and give it as much bitrate as it needs (with a fixed quantizer for example), you can get better results. What I don't agree with is that you could use the same bitrate (one that is enough for the not-resized source) for both encodes and the resized one would look better. Yes, it works only if the bitrate is high enough! Visually "close to lossless" or like I wrote earlier: "higher bitrates (where compression artefacts arent visible anyway)" What someone considers as "is enough" varys from 1CD to 1DVD, so this kind of processing wont be ideal for everyone, yes...
You can also sharpen after resizing on-the-fly with a decent processor. Again the algorithms may not be as high quality, but the result would still be better compared to watching the encoding artifacts.Fair enough! One is happy with simple EE sharpening as post-processing the next one spends hours to remove EE halos from a source just to spend even more hours to re-sharpen it without halos. Different ppl, different quality needs! Still the statement that upsizing a source is always wrong and makes no sense at all is wrong...
Bye
iceborne
31st January 2006, 00:33
how do you get limitedsharpen and iip to work? i'm new at avs scripts. can you give me a sample avs script with those function involve? i wanto to test these sharpening effects out.
Dayvon
31st January 2006, 01:04
Well on the audio encoding side, I just got done doing a few test runs on the 1st Two Towers disc. Here are my results.
_______________________________________________________________
Length: 01h46m33s__Source: AC3 5.1 @ 448kbps = 341MB
LC-AAC w/ DLP2@ 224kbps = 148MB; Quality = Good (except for rear decoding which is probably my setup)
MP3 w/ DLP2 @ 224kbps = 173MB; Quality = Passable (except for rear decoding which is probably my setup)
LC-AAC 5.1 @Radio Q = 170MB; Quality = Poor
LC-AAC 5.1 @256kbps = 197MB; Quality = Passable
MP3 w/ DLP2 @256kbps = 198MB; Quality = Good (except for rear decoding which is probably my setup)
LC-AAC 5.1 @320kbps = 245MB; Quality = Good
LC-AAC 5.1 @Internet Q = 254MB; Quality = Good
LC-AAC 5.1 @Streaming Q = 315MB; Quality = Good (not much better)
_______________________________________________________________
I normally like the Normal Q or Streaming Q settings for LC-AAC 5.1, which both are close to the size of the original AC3. I'm hoping for undersized file totals which might let me squeak in LC-AAC 5.1 Internet Q audio tracks for the entire project. Crossing my fingers... ;)
So moral of the story is, try to not go below LC-AAC 5.1 @ 320, or Internet Q. These qualitys are about the minimum bitrates if you are sensitive to compression artifacts and the "sizzling bacon" syndrome.
Soulhunter
31st January 2006, 01:05
how do you get limitedsharpen and iip to work? i'm new at avs scripts. can you give me a sample avs script with those function involve? i wanto to test these sharpening effects out.
I gonna send you a pm...
Bye
IgorC
31st January 2006, 02:11
I think it is not offtopic. But part of this project.
Did anybody try QuickTime7 LC-AAC 5.1 VBR? Actually Apple LC-AAC Stereo brings superior quality than Nero7.
http://www.hydrogenaudio.org/forums/index.php?showtopic=38792
http://audiotests.free.fr/tests/2005.11/results_gr5.png
For my ears Apple 5.1 approx. 200 kbps brings transparent quality. (the same bitrate is used for HD trailers 720/1080p)
For some tracks where is mostly human speech 160-192 kbps HE-AAC Nero7 5.1 is more than enough.
Dayvon
31st January 2006, 02:59
Son of a Gun...
Well I did some triple-check just now to see how close I am gonna be to file size... And I'm pretty sure I'm over, even with audio at 256kbps. I think that it basically came down to mis-calculation due to bytes-kilobytes-megabytes conversions. So In theory, right now (w/ audio @ 256) I'm gonna hit about a 8294MB total unless I change something. So if the DVD/DL burn maxes at 8547000000 (as mentioned in DVD Burning FAQ (http://forum.doom9.org/showthread.php?p=173982#post173982)), then I'm already over because that is 8152MB. And I kind of want to go with LC-AAC @ ~320kbps now, but that would drop the video bitrate to ~1350kbps, if I tried to fit that all in 8152MB.
So either:
A) Stick with the DVD-DL goal, and re-encode at 1)1350kbps and 320 LC-AAC or 2) 1410kbps and 256 LC-AAC or 3) Use 224kbps DLP2
B) Switch to 2 DVD-R's. Use 320CBR LCAAC and don't re-encode, use current 1450kbps video. (Two Towers would be split in 2... haha )
C) Switch to 3 DVD-R's. Use 320+ LC-AAC 5.1, and a 2100kbps video rate. Later on, burn to 15GB HD-DVD-R :D
If I did re-encode, would I have to run the first-passes again?
Right now, I'm thinking of A3 because I don't waste all the encoding I've already done. But also about C as well for the high-high quality with future proofing in mind as well. Any other thoughts/opinions?
foxyshadis
31st January 2006, 06:46
Nope, first pass is only done once, unless you cut frames out.
My nearly 3-year-old processor can deal with limitedsharpen on DVD content (just barely). I can't wait for the new system, when I can throw ls, spline resize, fft3dgpu, tbilateral, or whatever else I need at it. But I don't see anyone saying upsizing is always preferable, so I perfectly agree that it's fine if you've got the bitrate and not the horsepower.
iceborne
31st January 2006, 07:57
i'ld love to see some screenshots results
Dayvon
31st January 2006, 08:21
i'ld love to see some screenshots results
Of......
iceborne
31st January 2006, 08:46
your project, LOTR, of course. and at what res. did you encode @?
Dayvon
31st January 2006, 10:06
I'm gonna update the main page with tons of info when I'm done and exactly where I cut the films (number's of frames) etc. Right now, I'm just getting to the making part.
I did the encodings at ~880x360 give or take with a 1450kbps. Each movie cropped differently and also then resized differently. As of right now, I'm planning on doing a second-higher birate run. 2000kbps x264 with 320+kbps LC-AAC 5.1 to fit on 3 DVD's and later 1 HD-DVD. This I will probably crop uniformily and also upscale and possibly filter extensively.
In terms of where I am now, I will be encoding the last Return of the King disc sometime in the next day or two. This is all I have left. All the others are encoded at 1450 2-pass with 224 LC-AAC DLP2 tracks. If I had to do it over again (for the smaller run) I would have used more/slower ME and done 1350 with 320 LCAAC 5.1, but I'm not doing the small run again.
I'll post some pics. Particular spots of interest are the Balrog scene and the Helm's Deep battle. Rain and smoke/fire really give codecs a ran for their money. x264 handles it all pretty well. I can't complain having a 1450kbps file. I mean 3h20m movies at 2.4 GB with this quality? That is good compression.
NOTE: If you want to join the entire set into one mp4, I highly recommend that you crop and resize to the same resolution across all six discs. I can't seem to join more than 2 dvd's and I believe this is in part due to the differing resolutions between movies.
Doom9
31st January 2006, 10:22
It can make a big difference if you apply a filter before or after upsizing (as Didèe tried to show with his example) The sample doesn't get into very important details. First of all, the exact filtering chain would be important to know. I consider resizing as the last thing in a filter chain, so you could do whatever filtering you want prior to encoding, then just do the resize on the fly. Clearly, that wouldn't cause any problems for any CPU, especially not my X2. For DivX/XviD, I could add a lot more filters to the playback chain and never run out of CPU horsepower.
Also, the image example you posted is an execellent one to outline my point that people who get into filtering never create an accurate representation of the source.. but of what they want the source to look. These are two very different approaches.
And by the way, my screen's native resolution is 1920x1080 and soon 2560x1600.. so in case of high res screens, upsizing before encoding is just plain insane.. you're not going to upscale a 720x480 source to 2560x just so that there won't be any resizing during playback.
berrinam
31st January 2006, 10:37
Well I did some triple-check just now to see how close I am gonna be to file size... And I'm pretty sure I'm over, even with audio at 256kbps. I think that it basically came down to mis-calculation due to bytes-kilobytes-megabytes conversions.
The newest MeGUI now supports up to 25 hours of video in the bitrate calculator, as well as a DVD-9 option. Go nuts with that if you want.
Kurtnoise
31st January 2006, 12:02
Did anybody try QuickTime7 LC-AAC 5.1 VBR?
I tried and...qt doesn't support audio files > 2GB. :rolleyes:
Besweet supports DTS...
not at all...I'd say azidts which is completely different. :)
bond
31st January 2006, 12:33
not at all...I'd say azidts which is completely different. :)azidts also doesnt support dts, it simply wraps a commercial dshow dts decoder
i am asking for a native dts plugin for besweet for a long time already, but noone seems to want to do it...
Soulhunter
31st January 2006, 17:21
The sample doesn't get into very important details. First of all, the exact filtering chain would be important to know. I consider resizing as the last thing in a filter chain, so you could do whatever filtering you want prior to encoding, then just do the resize on the fly. Clearly, that wouldn't cause any problems for any CPU, especially not my X2. For DivX/XviD, I could add a lot more filters to the playback chain and never run out of CPU horsepower.
Also, the image example you posted is an execellent one to outline my point that people who get into filtering never create an accurate representation of the source.. but of what they want the source to look. These are two very different approaches...
Right! As you dont know how the master is supposed to look you have to guess how its supposed to look. Well, this LimiedSharpen+IIP picture was maybe already a bit "uber-enhanced" and alters the original look of the image, but its a good example to show how much hidden detail you can squeeze out of a DVD. Anyway, Socio also posted a "more natural" enhanced version...
Source:
http://img147.exs.cx/img147/3656/nosharpen6xy.jpg
aSharp + LimitedSharpen:
http://img28.exs.cx/img28/8233/lswithasharp6vl.jpg
And by the way, my screen's native resolution is 1920x1080 and soon 2560x1600.. so in case of high res screens, upsizing before encoding is just plain insane.. you're not going to upscale a 720x480 source to 2560x just so that there won't be any resizing during playback.
Hey, you could upscale 1920* content -> 2560* then... ^^
But c'mon, most ppl still have displays with 1024* or 1280* resolution, so for "joe average" a 720x576 -> 1024x576 (PAL DVD upsized for 1024*768 display) processing works fine. Btw, in this case keeping the full vertical resolution of the source is another benefit I havent mentioned before (ok, you could also encode anamorphic, but then you have to do a resize while playback to correct the AR, and this will soften/alter some of the enhanced details again)
Bye
Oline 61
1st February 2006, 01:05
Have you considered using FAAC? It has VBR constant quality settings from 1 to 100. This way you could get VBR around 300kbps which might be better for you that CBR 256 or CBR 320. IMHO the quality is as good as Nero, and encoding is faster.
[)370|\|470!2
1st February 2006, 03:29
Tbh, FAAC's quality is even worse than ancient xings mp3 encoders :D
Oline 61
1st February 2006, 05:24
If it is I can't hear it through my integrated audio and crappy stereo :P
Dayvon
1st February 2006, 08:48
Pictures, pictures, pictures.
I decided to pull all captures from the Two Towers, as this movie is the most representative of the entire series image quality (being a better source than Fellowship, and worse than Return of the King).
On with my quick analysis. Overall the image quality is what I would call very good considering I'm fitting over 11 hours of movie on 1 DVDDL. Let's start with the bad, and end with the good.
http://img90.imageshack.us/img90/3231/webbalrog3xj.th.png (http://img90.imageshack.us/my.php?image=webbalrog3xj.png)
Ok the balrog is tough. I mean bright red fading to shadow, with haze/smoke and fast motion all rolled into a codec's worst nightmare. Basically, it looked ok. I mean in the photo it's bad, in motion its passable. If you look for it you'll see it. But it didn't ruin my viewing experience.
http://img100.imageshack.us/img100/7820/webwater9mo.th.png (http://img100.imageshack.us/my.php?image=webwater9mo.png) http://img100.imageshack.us/img100/7214/webwaterfall2tn.th.png (http://img100.imageshack.us/my.php?image=webwaterfall2tn.png)
Water combined with smoke is tough as well. Note, when there wasn't smog with water, the water looked pretty good as in the second photo. All in all this scene was a low point in quality terms but not too bad. Again, it didn't ruin the experience.
http://img208.imageshack.us/img208/9226/webrainorc8lg.th.png (http://img208.imageshack.us/my.php?image=webrainorc8lg.png) http://img208.imageshack.us/img208/3794/webrain0qg.th.png (http://img208.imageshack.us/my.php?image=webrain0qg.png)
Naturally the rain scene was a big question mark. I came away stunned. x264 really took a beating here and came up shining. I was very impressed at the whole thing. It could have been real bad, but I saw pretty much only good things. Smearing was at a minimum and most details were kept. I gave two pictures, one that is great and one that's pretty good. That pretty much covers the rain scene.
http://img81.imageshack.us/img81/937/weborc2vu.th.png (http://img81.imageshack.us/my.php?image=weborc2vu.png) http://img99.imageshack.us/img99/5051/webstable6ir.th.png (http://img99.imageshack.us/my.php?image=webstable6ir.png)
http://img207.imageshack.us/img207/5566/webgaladriel8fh.th.png (http://img207.imageshack.us/my.php?image=webgaladriel8fh.png) http://img99.imageshack.us/img99/7196/webtheoden5yq.th.png (http://img99.imageshack.us/my.php?image=webtheoden5yq.png)
Here are a bunch of close-ups and other various shots. These as you can see are great. Some much better than great. The orc one is a favorite as well as the horse w/ Aragorn, and Galadriel. Good job x264.
CONCLUSION: If there is anything that needs improvement, its the dark tones and smoke. The blue fading to black in most night scenes has some significant blocking, and anytime there is a smoke or cloud, it looks fairly unnatural as it moves in chunks instead of swirling. Other than that, x264 did a great job with rain, unfocused portions of scenes, closeups, fire in general and fast motion scenes. Really overall a great experience.
If you want even more pictures, check out the links below.
Two Towers Small Sampling__5MB.zip (http://church.crossingatwoodland.com/Temp/download/Two Towers_5MB.zip)
Two Towers Large Sampling__15MB.zip (http://church.crossingatwoodland.com/Temp/download/Two Towers_15MB.zip)
Doom9
1st February 2006, 08:53
but then you have to do a resize while playback to correct the AR, and this will soften/alter some of the enhanced details again)but that's exactly what your DVD player does ;)
iceborne
1st February 2006, 09:20
@soulhunter,
i can see how impressive asharp+limitedsharpen can do as an example you posted, but it all the more makes Yoda more fake, more plastic as to say. Lucas, i think, intentionally blurr all their cgi characters for realism and all this does is reverse it. but hey, just my 2 cents!
Soulhunter
1st February 2006, 09:40
but that's exactly what your DVD player does ;)
Just another reason for me to use a HTPC instead of a DVD-player... ^^
@soulhunter,
i can see how impressive asharp+limitedsharpen can do as an example you posted, but it all the more makes Yoda more fake, more plastic as to say...
Hey, isnt Yoda made of plastic!? Ah no, that was in the 3 old episodes... ;) :D
Bye
Oline 61
1st February 2006, 21:54
I thought that x264 encoded better at resolutions that are multiples of 16. I encoded this movie at 720x352 (w/ SAR 52/45 so playback was 832x352). In my copy (not the extended edition, just regular widescreen version) there are only 352 good pixels vertically. Thr first few on the top and bottom taper off into darkness instead of having a clear deliniation(sp?).
Also, why is your aspect 2.42:1? IIRC most anamorphic movies are at 2.35:1. All of my LoTR DVDs (regular widescreen version) are 2.35:1.
Dayvon
2nd February 2006, 02:19
I thought that x264 encoded better at resolutions that are multiples of 16. I encoded this movie at 720x352 (w/ SAR 52/45 so playback was 832x352). In my copy (not the extended edition, just regular widescreen version) there are only 352 good pixels vertically. Thr first few on the top and bottom taper off into darkness instead of having a clear deliniation(sp?).
Also, why is your aspect 2.42:1? IIRC most anamorphic movies are at 2.35:1. All of my LoTR DVDs (regular widescreen version) are 2.35:1.
Most movies are 2.35:1 as they are viewed IN THEATRES. And that is also the aspect ratio of the source. What they store on the DVD is of course 720x480 video, aspect ratio correction, and w/ bars for 16x9 widescreen. What this adds up to is the the actual anamorphically corrected movie in terms of what you can visually see, is not necessarily perfect 2.35:1. Most 2.35:1 movies I find to be right around a visible 2.4:1 aspect ratio. Now I usually crop on the edge of visible movie, and not over the edge. This tends to make the final ratio a bit skewed from the box.
Dayvon
2nd February 2006, 03:07
Well folks Part 1 is finished.
7989MB total of 8150MB possible. So all in all a very good encode. 11 hrs and 18 min of LOTR video.
Final specs:
7989MB Total
1450kbps AVC - x264 w/ MeGUI
x264.exe --pass 2 --bitrate 1450 --stats ".stats" --ref 3 --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --progress --no-psnr --output
224kbps LC-AAC - NAAC w/ Belight
BeSweet.exe -core( -input "" -output "" -logfilea "" ) -azid( -s dplii -c normal -L -3db ) -bsn( -2ch -cbr 224 -codecquality_high -aacprofile_lc -exportaac ) -ota( -d 0 -g max )
YAMB 1.4 Muxing w/ Mp4Box
Now onto phase 2....
1360x554 Resolution
LimitedSharpen
FluxsmoothST
Lanczosresize
AVC - 2000kbps_x264
LC-AAC - 320+kbps_NAAC
YAMB - Mp4
More info soon.
____________________________________________________
EDIT: Check out post #1. Reworked it and sharing the luv.
..
MatMaul
8th February 2006, 14:37
hello !
I have a question for deyvon.
I try to encode "the return of the king" extended version and I want to know how do you have join the two dvd before the encode ?
I have tried to do that in dgindex : I had the vob of the first dvd and the vob of the second dvd and I save the d2v file (dgindex also demux the audio). The video is ok but not the audio : after video encode, I have mux video and audio in avi file and all is good for the first part of the film, but when the second part (the second dvd) of the film begin, the audio and the video aren't synchronized (about 1/2 second between audio and video).
Can you help me?
PS : I don't recode the audio, I mux the ac3 file directly
MatMaul
8th February 2006, 15:03
I have also test to demux ac3 with dgindex but for each dvd, and join ac3 with "copy /b 1.ac3 + 2.ac3 ok.ac3" : the same behaviour appears
EDIT : same behaviour when I play my avs script in MPC and with the ac3 file selected for the audio
Dayvon
8th February 2006, 15:42
The audio on these files will not sync properly if you DGIndex as you have. Basically, there is less audio frames than video frames. The way that I did it, is that I render both disc seperately using MeGUI, x264, and Belight for audio. Then I used YAMB 1.5 for combining the audio with the video.
After each movie was function fine on its own, I joined the MP4 files with YAMB 1.5 which did introduce sync issues. My solution was to then figure out the offset by using Media Player Classic's delayed audio function to match the second disc back up to A/V sync. Then I re-encoded the audio using Belight and added in the delay difference. When the movie are then joined using YAMB, they flow perfectly.
This was my work around and the only solution that I could figure out. Trying to join movies like this doesn't happen that much, so this is not a problem most encoders encounter. Good luck, and I hope that explains/helps :)
MatMaul
8th February 2006, 16:16
I have find the problem !
the first audio file is about 0,5s longer than the video.
I have cut this file and join with the other, and it's ok.
If, at the contrary, the file is shorter, we can also introduce a delay in the second file, and I think it's good.
For the video, I finally use avisynth for join the 2 DVD and not dgindex. I use this script :
video1 = MPEG2Source("C:\LOTR_RETURN_OF_THE_KING_SEE_D1\VIDEO_TS\VTS_01_1.d2v", idct=7)
video2 = MPEG2Source("C:\LOTR_RETURN_OF_THE_KING_SEE_D2\VIDEO_TS\VTS_02_1.d2v", idct=7)
movie = video1 + video2
movie = movie.Trim(0, 347500)
movie = movie.Crop(0, 76, 0, -78)
movie = movie.LanczosResize(720, 304)
movie = movie.VobSub("C:\lotr3\subs_final\output.idx")
return movie
Dayvon
10th February 2006, 19:27
Help with blocking!!!!
I'm wondering how to fix this sort of blocking.
http://img69.imageshack.us/img69/1750/balrogbit14cj.th.png (http://img69.imageshack.us/my.php?image=balrogbit14cj.png) http://img453.imageshack.us/img453/1549/striderbit3ol.th.png (http://img453.imageshack.us/my.php?image=striderbit3ol.png)
I can't seem to get rid of those nasty HUGE blocks. It happens with x264 even as bitrate is increased (this was a 2000kbps 2-pass). I'm wondering if having more or less motion estimation would help. Or if there is some other setting that can fix this.
Here's my cmd line:
x264.exe --pass 2 --bitrate 2000 --stats ".stats" --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-2 --subme 6 --trellis 1 --analyse all --8x8dct --threads 2 --progress --no-psnr --output "" ""
ChronoReverse
10th February 2006, 23:21
--filter -2,-2 <=== isn't this the setting that's supposed to do the inloop deblocking?
In any case, I wonder if it's possible to do Limitedsharpen and IIP using pixel shaders. Then it'd be possible to do the resize and filtering during playback without increasing CPU load (MPC let's you run pixel shader programs to manipulate the output).
Oline 61
10th February 2006, 23:23
Try more reference, maybe 8 or more. Also you could go to subme=7 and/or me=umh
Dayvon
10th February 2006, 23:50
Try more reference, maybe 8 or more. Also you could go to subme=7 and/or me=umh
That's the thing that has me wondering... Would more motion estimation actually 'cause the problem? Or would having more motion analyzation mean that it would figure out that this part needs more bitrate? It just seems weird to me that I can jump from 1350 kbps to 2000kbps and still have a similar look in the same problem areas.
Soulhunter
10th February 2006, 23:58
In any case, I wonder if it's possible to do Limitedsharpen and IIP using pixel shaders. Then it'd be possible to do the resize and filtering during playback without increasing CPU load (MPC let's you run pixel shader programs to manipulate the output).
Antitorgo (http://forum.doom9.org/showthread.php?t=86793) tried to code something like this, but then he disappeared... :\
Bye
Oline 61
11th February 2006, 00:23
That's the thing that has me wondering... Would more motion estimation actually 'cause the problem? Or would having more motion analyzation mean that it would figure out that this part needs more bitrate? It just seems weird to me that I can jump from 1350 kbps to 2000kbps and still have a similar look in the same problem areas.
Well you also went from 720x360 to 1360x554.
Thats 259,200 vs. 753,440 pixels. If the relationship is linear you will need almost 3x the bitrate to reach the same quality at 1360x554 as at 720x360.
Dayvon
11th February 2006, 01:31
Well you also went from 720x360 to 1360x554.
Thats 259,200 vs. 753,440 pixels. If the relationship is linear you will need almost 3x the bitrate to reach the same quality at 1360x554 as at 720x360.
True but the resizing isnt the issue that makes the blocks. Do a quick compare of the screens.
The 1360x544 files are 2000kbps and the 880x360 files are 1450kbps. But they both exhibit the same exact problem and it looks identical.
http://img69.imageshack.us/img69/1750/balrogbit14cj.th.png (http://img69.imageshack.us/my.php?image=balrogbit14cj.png) http://img453.imageshack.us/img453/1549/striderbit3ol.th.png (http://img453.imageshack.us/my.php?image=striderbit3ol.png)
EDIT: Ill post the other screens when imageshack uploading is back up.
I'm looking to know if there is a setting that I need to adjust, or if this is just the youth of x264 and it's motion estimation algorythms? I know I could turn up deblocking, but that won't help the quality of the encode, just add some smearing to make it harder to see. What setting would I have to run to get those blocks to go away aside from lossless? I'm kinda bummed that the extra 650kbpx didn't help :confused: :(
nm
11th February 2006, 02:15
True but the resizing isnt the issue that makes the blocks. Do a quick compare of the screens.
The 1360x544 files are 2000kbps and the 880x360 files are 1450kbps. But they both exhibit the same exact problem and it looks identical.
[...]
I'm kinda bummed that the extra 650kbpx didn't help :confused: :(
The resize as such is not the problem, but the bitrate could be. Since your resized picture contains 2.33 times the amount of pixels the smaller one had, you should give it two times the bitrate too! Even 3000 kbps would still give you only about the same quality as 1450 kbps for the smaller resolution. Why don't you try 880x360 with >2000 kbps and inloop at 0:0? You can easily test different bitrates and settings by encoding only a part of a difficult scene from the source.
Dayvon
11th February 2006, 03:19
The resize as such is not the problem, but the bitrate could be. Since your resized picture contains 2.33 times the amount of pixels the smaller one had, you should give it two times the bitrate too!
Really? That seems off, 'cause I don't think that there is such a direct correlation between resolution and bitrate. I mean what you say makes sense, but I haven't heard of that before and if that was the case, the quality would be more disparing between the two.
The goal of the large size is that the resize is done in the midst of enhancements (limitedsharpen, flux smooth,etc.) and then no resizing is needed in rendering, since lancoz is better than overlay resizing. Overall, the quality is much higher than the smaller encode, aside from the bit-ing out in these two scenes in particular.
Oline 61
11th February 2006, 04:47
nm said pretty much the same thing I was trying to say in a more clear, concise way.
The only thing I can think of is increase codec settings, what about trellis=2 or no trellis, more references, RDO level 7, or maybe lower settings. Experimentation is called for.
foxyshadis
11th February 2006, 05:31
I was going to say AQ for the darkness, that's what it's there for, but that would do jack all for the flames. It is possible that it's a total motion/reference mismatch, you can try no b-frames, 1-2 references, see if that helps at all. Even if it does it's probably not worth it, maybe you should just use a zone for the fire scene to double its bitrate.
Blockbuster might help slightly with the night scene as well, if used conservatively.
Didée
11th February 2006, 05:37
The goal of the large size is that the resize is done in the midst of enhancements (limitedsharpen, flux smooth,etc.) and then no resizing is needed in rendering, since lancoz is better than overlay resizing. Overall, the quality is much higher than the smaller encode, aside from the bit-ing out in these two scenes in particular.
As usual, I'm in the wrong place right now thus cannot check ... but somehow I've the feeling that my agy pseudo-HD version of LOTR at least doesn't look worse ... okay, resolution was smaller (960x528, "anamorphic" 720p), but for FOTR, that was with a bloody alpha of XviD 1.0, inmature B-frames, no trellis, broken 2-pass, etc. ...
Would you mind posting the exact Avisynth script you're using? Perhaps there is something to improve. Your mentioning of LimitedSharpen *and* lanczosresize makes me think ...
Also, on what display device are you planning to play back, so that your (uncommon) resolution of 1360x544 leads to "no resizing during playback"? 1280*xxx is a common resoltion, but 1360?
Dayvon
11th February 2006, 07:51
As usual, I'm in the wrong place right now thus cannot check ... but somehow I've the feeling that my agy pseudo-HD version of LOTR at least doesn't look worse ... okay, resolution was smaller (960x528, "anamorphic" 720p), but for FOTR, that was with a bloody alpha of XviD 1.0, inmature B-frames, no trellis, broken 2-pass, etc. ...
Would you mind posting the exact Avisynth script you're using? Perhaps there is something to improve. Your mentioning of LimitedSharpen *and* lanczosresize makes me think ...
Also, on what display device are you planning to play back, so that your (uncommon) resolution of 1360x544 leads to "no resizing during playback"? 1280*xxx is a common resoltion, but 1360?
The video it self doesn't look bad... There are just a couple scenes (these in particular) that to me it seems x264 is not doing so hot with the motion estimation. I don't ever remember seeing blocking problems with Xvid at 2000kbps, so x264 doing this seems a bit odd to me. It obviously thinks that that portion of the clip is high motion when it is not.
As to the 1360x554, my display is a 32" LCD with a resolution of 1366x768. Now being that 1366x768 is not divisible by 16, it is *near* impossible to run a desktop at that resolution, so you have to run at 1360x768. I run from my HTPC through DVI to the LCD for movie viewing. Thus if I resize to 1360x554 then I have no resizing upon viewing. ;)
So for my script...
SetMemoryMax(512)
LoadPlugin("D:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
LoadPlugin("D:\Program Files\MaskTools-v1.5.8\MaskTools.dll")
LoadPlugin("D:\Program Files\AviSynth 2.5\plugins\undot.dll")
LoadPlugin("D:\Program Files\WarpSharpen\warpsharp.dll")
LoadPlugin("D:\Program Files\WarpSharpen\LoadPluginEx.dll")
LoadPlugin("D:\Program Files\AviSynth 2.5\plugins\dustv5.dll")
LoadPlugin("D:\Program Files\AviSynth 2.5\plugins\fluxsmooth.dll")
mpeg2source("H:\DVD TEMP\LOTR_EE_Fellowship_D1\Fellowship_D1_v2.d2v")
crop(4,64,712,352)
FluxSmoothST(2,2)
LimitedSharpen(dest_x=1360,dest_y=554,ss_x=1.0,ss_y=1.0,Smode=2,strength=35)
# LimitedSharpen()
#
# A multi-purpose sharpener by Didée
#
function LimitedSharpen( clip clp,
\ float "ss_x", float "ss_y",
\ int "dest_x", int "dest_y",
\ int "Smode" , int "strength", int "radius",
\ int "Lmode", bool "wide", int "overshoot",
\ bool "soft", int "edgemode", bool "special",
\ int "exborder" )
{
ox = clp.width
oy = clp.height
ss_x = default( ss_x, 1.5 )
ss_y = default( ss_y, 1.5 )
dest_x = default( dest_x, ox )
dest_y = default( dest_y, oy )
Smode = default( Smode, 3 )
strength = Smode==1
\ ? default( strength, 160 )
\ : default( strength, 100 )
strength = Smode==2&&strength>100 ? 100 : strength
radius = default( radius, 2 )
Lmode = default( Lmode, 1 )
wide = default( wide, false )
overshoot= default( overshoot, 1)
overshoot= overshoot<0 ? 0 : overshoot
soft = default( soft, false )
edgemode = default( edgemode, 0 )
special = default( special, false )
exborder = default( exborder, 0)
#radius = round( radius*(ss_x+ss_y)/2) # If it's you, Mug Funky - feel free to activate it again
xxs=round(ox*ss_x/8)*8
yys=round(oy*ss_y/8)*8
smx=exborder==0?dest_x:round(dest_x/Exborder/4)*4
smy=exborder==0?dest_y:round(dest_y/Exborder/4)*4
clp.isYV12() ? clp : clp.converttoyv12()
ss_x != 1.0 || ss_y != 1.0 ? last.lanczosresize(xxs,yys) : last
tmp = last
edge = logic( tmp.DEdgeMask(0,255,0,255,"5 10 5 0 0 0 -5 -10 -5", divisor=2)
\ ,tmp.DEdgeMask(0,255,0,255,"5 0 -5 10 0 -10 5 0 -5", divisor=2)
\ ,"max").levels(0,0.86,128,0,255,false)
bright_limit = (soft == true) ? tmp.blur(1.0) : tmp
dark_limit1 = bright_limit.inpand()
bright_limit1 = bright_limit.expand()
dark_limit = (wide==false) ? dark_limit1 : dark_limit1 .inflate.deflate.inpand()
bright_limit = (wide==false) ? bright_limit1 : bright_limit1.deflate.inflate.expand()
minmaxavg = special==false
\ ? yv12lutxy(dark_limit1,bright_limit1,yexpr="x y + 2 /")
\ : maskedmerge(dark_limit,bright_limit,tmp,Y=3,U=-128,V=-128)
Str=string(float(strength)/100.0)
normsharp = Smode==1 ? unsharpmask(strength,radius,0)
\ : Smode==2 ? sharpen(float(strength)/100.0)
\ : yv12lutxy(tmp,minmaxavg,yexpr="x x y - "+Str+" * +")
OS = string(overshoot)
Lmode == 1 ? yv12lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x "+OS+" + ?")
\ : yv12lutxy( bright_limit, normsharp, yexpr="y x "+OS+" + < y x y x - "+OS+" - 1 2 / ^ + "+OS+" + ?")
Lmode == 1 ? yv12lutxy( dark_limit, last, yexpr="y x "+OS+" - > y x "+OS+" - ?")
\ : yv12lutxy( dark_limit, last, yexpr="y x "+OS+" - > y x x y - "+OS+" - 1 2 / ^ - "+OS+" - ?")
edgemode==0 ? NOP
\ : edgemode==1 ? MaskedMerge(tmp,last,edge.inflate.inflate.blur(1.0),Y=3,U=1,V=1)
\ : MaskedMerge(last,tmp,edge.inflate.inflate.blur(1.0),Y=3,U=1,V=1)
(ss_x != 1.0 || ss_y != 1.0)
\ || (dest_x != ox || dest_y != oy) ? lanczosresize(dest_x,dest_y) : last
ex=blankclip(last,width=smx,height=smy,color=$FFFFFF).addborders(2,2,2,2).coloryuv(levels="TV->PC")
\.blur(1.3).inpand().blur(1.3).bicubicresize(dest_x,dest_y,1.0,.0)
tmp=clp.lanczosresize(dest_x,dest_y)
clp.isYV12() ? ( exborder==0 ? tmp.mergeluma(last)
\ : maskedmerge(tmp,last,ex,Y=3,U=1,V=1) )
\ : ( exborder==0 ? tmp.mergeluma(last.converttoyuy2())
\ : tmp.mergeluma( maskedmerge(tmp.converttoyv12(),last,ex,Y=3,U=1,V=1)
\ .converttoyuy2()) )
return last
}
nm
11th February 2006, 07:58
Really? That seems off, 'cause I don't think that there is such a direct correlation between resolution and bitrate. I mean what you say makes sense, but I haven't heard of that before and if that was the case, the quality would be more disparing between the two.
Of course the correlation is not linear, especially because visual quality does not change linearly with the bitrate. Like Oline 61, I was just pointing out that there is a clear reason why the "extra" bitrate didn't help.
The goal of the large size is that the resize is done in the midst of enhancements (limitedsharpen, flux smooth,etc.) and then no resizing is needed in rendering, since lancoz is better than overlay resizing. Overall, the quality is much higher than the smaller encode, aside from the bit-ing out in these two scenes in particular.
So why don't you use lanczos during playback? It would require much less processing power than decoding AVC video at three times the original resolution (720x360). Perhaps you could do other filtering on the fly too. If you are thinking easy playback with all your video players, have you thought what happens when you buy a new display (1920x1080 perhaps)?
Dayvon
11th February 2006, 08:17
Of course the correlation is not linear, especially because visual quality does not change linearly with the bitrate. Like Oline 61, I was just pointing out that there is a clear reason why the "extra" bitrate didn't help.
So why don't you use lanczos during playback? It would require much less processing power than decoding AVC video at three times the original resolution (720x360). Perhaps you could do other filtering on the fly too. If you are thinking easy playback with all your video players, have you thought what happens when you buy a new display (1920x1080 perhaps)?
Still the quality won't be the same. Look at the script, you can see the the resizing is happening with the sharpening, which can't happen the same way post rendering.
As for the display, I'm gonna be paying on it for another 2 years, so I'm gonna be happy with it for a good while to come. :o Besides, 2 years down the road an HD version of the Extended Editions will probably be available anyway. This is kind of backup/hobby/viewing use.
Soulhunter
11th February 2006, 09:08
Blockbuster might help slightly with the night scene as well, if used conservatively.
Ditto!
Try something like this (after LimitedSharpen) for the two scenes...
Blockbuster(Method="Noise",Detail_Min=1,Detail_Max=15,Variance=1)
...and raise the bitrate ~ 200-300% for em as well!
Bye
akupenguin
11th February 2006, 11:10
Still the quality won't be the same. Look at the script, you can see the the resizing is happening with the sharpening, which can't happen the same way post rendering. No, that's exactly what lanczos does: resizes and sharpens at the same time. Of course it isn't the same as limitedsharpen, but only the reason for switching is that limitedsharpen is too slow for realtime playback, not that you couldn't use it for rendering.
bond
11th February 2006, 11:18
--filter -2,-2 <=== isn't this the setting that's supposed to do the inloop deblocking?its -2:-2 not -2,-2
*.mp4 guy
11th February 2006, 12:27
Those are dct blocks unrelated to motion estimation (they would most likely apear even at much higher bitrates, atleast that has been my experience with them) you could add noise to the source (with a filter like blockbuster as previously suggested) or you could try a cqm that wouldn't drop frequencies as aggressively.
Dayvon
11th February 2006, 15:34
Those are dct blocks unrelated to motion estimation (they would most likely apear even at much higher bitrates, atleast that has been my experience with them) you could add noise to the source (with a filter like blockbuster as previously suggested) or you could try a cqm that wouldn't drop frequencies as aggressively.
That's kinda what I've been figuring out too. I can't seem to get rid of blocking in these types of situations. There seem to be alot of work arounds mentioned, but to me it seems clear that there is something that could be done to x264 to decrease that blocking. Not saying I would have the slightest idea what saying that means. And I'm sure that it would probably suck for the developers to try to fix this kind of issue.
But honestly if the only way to fix such obvious dct blocking is to "add noise to the source" or to extensively use zones and rerender AFTER already doing your rendering and finding that there is a problem, that just seems like not the kinda thing that should have to be done. There should be some sort of setting in x264 that fixes this kinda of problem. If there's not, there should be.
I say this because x264 is the best codec I've used ever. The quality of the vast majority of these encodes is stellar. But this last mile of quality should be figured out somehow besides hacking the video by encoding a second time with custom settings.
ChronoReverse
11th February 2006, 20:53
its -2:-2 not -2,-2
Why tell me? I'm just copying and pasting what he put. I would've used Megui and gotten it right =P
foxyshadis
11th February 2006, 21:34
Megui still uses the incorrect -2,-2 parameter (even though it's been mentioned in the thread 5-6 times the last few weeks).
Unfortunately, most DCT-based encoders tend to do badly with very smooth gradients. (Even the yv12 colorspace degrades them.) AQ is supposed to lower the quantizer of blocks that turn solid (left with only AC component), but if it's shallow enough it'll still be under the threshold. Perhaps some future AQ patch will do different, but I have no idea how it would. (You can hardly adjust q matrix for individual blocks.)
Didée
11th February 2006, 22:35
crop(4,64,712,352)
FluxSmoothST(2,2)
LimitedSharpen(dest_x=1360,dest_y=554,ss_x=1.0,ss_y=1.0,Smode=2,strength=35)
And there the suboptimal-ness begins. You're sharpening at the initial resolution, and resize afterwards. That's what's causing the lack of "definition", which I was missing from your screenshots. If the final step is just upsizing from SD to HD by lanczos, then the result will look just like that: like an upsized source. Working out the sharpness at the final resolution (at least that, if not supersampled) is what will give at least a bit of the impression like if there actually would be "more" in it.
Also, what is "554" for a value for vertical resolution ... you want to got for 560 here, for 'compatibility' as well as for codec's efficiency and, last not least, also for the aspect ration, won't you?
Suggestion: Arm yourself with the latest version of LimitedSharpen, get Deblock_qed (http://videoprocessing.11.forumer.com/viewtopic.php?p=413#413) too, as well as Soothe (http://forum.doom9.org/showthread.php?t=99679), and try
Deblock_QED(quant1=18,aOff1=16,quant2=28,aOff2=11)
FluxSmoothT(1)
ConvertToYUY2().FaeryDust(1).ConvertToYV12()
crop(4,64,712,352) # cropping here, because FaeryDust needs MOD16 horizontally
a=last.lanczosresize(1360,560)
b=LimitedSharpen(dest_x=1360,dest_y=560,ss_x=(1360.0/712.0),ss_y=(560.0/352.0),
\ Smode=4,strength=200,soft=33,Lmode=3,wide=true,overshoot=3)
Soothe(a,b,32)
edit: script corrected
That's rather similar to how I did FOTR back then, only that today's filtering methods are much more advanced than they have been.
Perhaps FaeryDust could be replaced with some Sigma=1 FFT3D nowadays, too ... didn't play with LOTR for a good while already.
(However I started out with the PAL versions of the EE's, so there was more vertical resolution to start with.)
guada 2
11th February 2006, 23:09
YES Didée;
Again..... :)
I am in a hurry to see your next optimization.
And its name? LimitedSharpen XXX ;)
To soon.
Oline 61
11th February 2006, 23:11
I went back and checked and my encode has the blocks too.
http://img132.imageshack.us/img132/5417/00633nw.th.jpg (http://img132.imageshack.us/my.php?image=00633nw.jpg)
AVS:
MPEG2Source("VTS_01_1.d2v")
ColorMatrix()
TFM(d2v="VTS_01_1.d2v")
TDecimate()
Crop(0,62,0,-66)
UnDot()
x264:
C:\Program Files\x264\x264.exe --pass 1 --bitrate 1412 --stats ".stats" --bframes 2 --b-pyramid --filter -2,0 --subme 1 --analyse none --ratetol 3 --me dia --sar 52:45 --cqmfile "C:\Program Files\MeGUI\matrix\eqm_avc_hr.cfg" --progress --no-psnr --output NUL ""
C:\Program Files\x264\x264.exe --pass 2 --bitrate 1412 --stats ".stats" --ref 8 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,0 --subme 7 --trellis 1 --analyse all --8x8dct --ratetol 3 --me umh --sar 52:45 --cqmfile "C:\Program Files\MeGUI\matrix\eqm_avc_hr.cfg" --progress --no-psnr --output "" ""
foxyshadis
11th February 2006, 23:11
And before you come back and say the script doesn't work and oh god the horrible artifacts: ;)
Deblock_QED(quant1=18,aOff1=16,quant2=28,aOff2=11)
FluxSmoothT(1)
ConvertToYUY2().FaeryDust(1).ConvertToYV12()
crop(4,64,712,352) # cropping here, because FaeryDust needs MOD16 horizontally
a=last.LanczosResize(1360,560) # or your favorite resize, lanczos might sharpen too much for this
b=LimitedSharpen(dest_x=1360,dest_y=560,ss_x=(1360.0/712.0),ss_y=(560.0/352.0),
\ Smode=4,strength=200,soft=33,Lmode=3,wide=true,overshoot=3)
Soothe(a,b,32)
Didée
11th February 2006, 23:28
Oh dear, I was sloppy again :o
Script must be exactly like foxyshadis showed. The "a" clip must be resized, else it can't work.
EDIT:
foxyshadis' script is wrong, crop() is at the wrong place. The cropping must be done *after* FaeryDust (or PixieDust or GoldDust, for that matter), like I originally posted. Feeding a source that's horizontally only MOD8 into those Dust filters will most probably cause green or purple artefacts on the right border.
Caroliano
11th February 2006, 23:41
Try the spatial mode for b-frames and see if it change something about the blocks. We are discussing this, but only in anime for now.
http://forum.doom9.org/showthread.php?t=106942
http://forum.doom9.org/showthread.php?t=107118
Posting PSNR and bitrate diferences would also be good.
Dayvon
12th February 2006, 00:48
And before you come back and say the script doesn't work and oh god the horrible artifacts: ;)
Deblock_QED(quant1=18,aOff1=16,quant2=28,aOff2=11)
FluxSmoothT(1)
crop(4,64,712,352) # cropping here, because FaeryDust needs MOD16 horizontally
ConvertToYUY2().FaeryDust(1).ConvertToYV12()
a=last.LanczosResize(1360,560) # or your favorite resize, lanczos might sharpen too much for this
b=LimitedSharpen(dest_x=1360,dest_y=560,ss_x=(1360.0/712.0),ss_y=(560.0/352.0),
\ Smode=4,strength=200,soft=33,Lmode=3,wide=true,overshoot=3)
Soothe(a,b,32)
@Didee-or-foxyshadis
Quick question... So I'm half way through the series right? And each of the 2nd-pass encodes already takes a full 20~24 hours, and I only have one computer. (So that kind of bites to start all over, but if it's worth it, then it is worth it ;) ) Any idea how much longer of an encode this would be compared with my AVS file? (Please don't say double the time..... :scared: )
@Caroliano
I might try the spatial setting for b-frames with this next encode. I'll let you see the results.
@akupenguin
Do you think that changing the ME Range might help with this blocking? I wouldn't mind a longer encode time I suppose if it might help with these scenes.
foxyshadis
12th February 2006, 01:41
The LimitedSharpenFaster+Soothe for MT2 is probably a 20-30% slowdown compared to plain sharpen+resize. DeBlock_QED probably introduces a 10% slowdown for me. FluxSmooth and FairyDust I've never used.
You can always cut out a thouand-frame segment an encode that, so you don't have to start all over, even if the bitrates don't match the main encode in that area it'll let you compare speed and effectiveness.
akupenguin
12th February 2006, 03:58
@akupenguin
Do you think that changing the ME Range might help with this blocking? I wouldn't mind a longer encode time I suppose if it might help with these scenes.
No. It might possibly do something in the fire scene, but even then I think it would only reduce bitrate a little, not affect blocking per-se.
Didée
12th February 2006, 04:27
Last script by foxyshadis had a bug. See my edit above.
Dayvon
12th February 2006, 05:13
The first-pass (turbo) test file I'm doing is running at 2.35fps!!! Holy crap! You guys actually encode like a whole entire movie like this? Wow. I'm not sure if I can lock up my only computer for 5 days just to do Fellowship disc 1 like this ;) ...
But seriously, thanks for the help guys. Got any suggestions that would be almost do-able in realtime (aka about 15-20fps realtime) that use limitedsharpen? I want the high quality but with reasonable encode times, like maybe 15-20 hour encodes (note: for the 2ndpass only). I know I should test it all and figure it out myself, but tweaking script-heavy AVSynth stuff is just not for me.
I was fairly happy with my script's results with my previous settings, so basing off of that, what should I change (so as to get the sharpening done AFTER resizing)? I like the fluxsmooth and the limitedsharpen, do I really need faerydust? Also limitedsharpen has 3 versions: Beta, Faster, and original. Which should I use?
@Didee or Foxy
Which version of limitedsharpen did you intend for me to use?
foxyshadis
12th February 2006, 06:00
Oh, I didn't realize it was already in mod16 and moving to mod8, not vice versa, I thought you'd swapped that accidentally too... my mistake! I should have taken a moment to realize it was only mod8.
Didée
12th February 2006, 19:59
Use LimitedSharpenFaster, and foxyshadis' adaption of Soothe() for MasktTools v2.
For overall speed, you should do an initial pass with all the filtering, and save that to an intermediate file with lossless compression. Then encode this one as usual. Needs very much temporary space, but in the end it's the fastest method.
FYI - the whole encoding process of FOTR took me one month, back then ...
(Because a) 4*SSXSharpen was slow as hell, and moreover b) XviD's 2-pass system was broken at that time, so I assigned *all* frame quantizers manually - a total of ~1000 zones, or something :eek: )
If you're not that much of a nerd, encode the source as-is without any filtering, resize during playback, be done with it and go out to have social contacts.
Dayvon
12th February 2006, 20:58
FYI - the whole encoding process of FOTR took me one month, back then ...
(Because a) 4*SSXSharpen was slow as hell, and moreover b) XviD's 2-pass system was broken at that time, so I assigned *all* frame quantizers manually - a total of ~1000 zones, or something :eek: )
If you're not that much of a nerd, encode the source as-is without any filtering, resize during playback, be done with it and go out to have social contacts.
LOL. I'm not THAT much of a nerd :p
But the fact that I'm on this board with an average of 2.25 post's a day.... Well, ok, I'm a nerd :cool:
I'll have a big update to this post in a few minutes, doing a test of "spatial vs. temporal b-frames" and "multihex vs. hexagonal" to see what helps solve the blocking issue.
EDIT: Alright below are the main images that we're gonna look at. Rendered with 2-pass 1450kbps, the images on the left side are with spatial b-frames and multihex enabled, while the images on the right are temporal b-frames and hexagonal enabled.
http://img46.imageshack.us/img46/9666/d1v21both7hu.th.png (http://img46.imageshack.us/my.php?image=d1v21both7hu.png) http://img395.imageshack.us/img395/8530/d1v21neither7lp.th.png (http://img395.imageshack.us/my.php?image=d1v21neither7lp.png)
http://img366.imageshack.us/img366/7793/d2v2both1te.th.png (http://img366.imageshack.us/my.php?image=d2v2both1te.png) http://img395.imageshack.us/img395/6088/d2v2neither3hx.th.png (http://img395.imageshack.us/my.php?image=d2v2neither3hx.png)
Really, its kind of a crap shoot. Both are not the greatest, but to my eye the temporal with hex has the edge. I also ran other runs, but they are all too similar and the temporal/hex one renders the fastest.
Another word of note is that I ran a 1350kbps encode, and used a weight of 200% on the horse scene with ZERO effect on the blocking. It was still there in force with little to no improvement. This goes back to my point of needing something else to help in these spots, such as a improved Chroma ME that also takes luminicity into more consideration.
Anyway, just thought I'd share the results. :)
frednerk
1st March 2006, 10:52
foxyshadis' adaption of Soothe() for MasktTools v2. Thanks!! Found it at http://forum.doom9.org/showthread.php?p=784366#post784366
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.