meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[Vitreous]

Also consider reducing the thread count, as less threads means less likelihood of a crash. With Main Threads set to Auto, you get 12 threads on a 6 core machine. Try reducing it to 10 or 8 for stability. For performance, you want to set the number of threads such that you just hit 100% CPU. If you set too many threads you will of course get 100% CPU, but you may just be wasting time on the overhead of switching threads. I would expect the ideal setting for the defaults to be less than 12 threads.

On a similar point, reducing the Sub-Threads setting might help. It defaults to the same as Main Threads (i.e. 12 for you), so try setting it to 8, 4 or even 1. Performance effects may not be significant from doing this.

The main avisynth developer is active, but he has removed multi-threading completely from recent builds (because he can't decide how / doesn't have time to fix it or something). There is an active unofficial build (from SEt) with multi-threading support and some threading fixes, which is the one I posted.

isityours comments are correct. Whilst you can use your machine during a rip and often have no problem, the incidence of crashes is higher when you do.

 

[anandneemish]

Yes, I've had a few people observe that multi-threaded QTGMC (the core of MeguIVit) is a tougher stress test than Prime95. It's because it accesses much more memory and hits the harddrive continuously as well as the intense CPU activity. I'm quite proud ^^

FYI. I am currently running i7 2600K. The stock cooler was really lousy and I was not able to peg it without overheating (and hence leading to CPU backing off on). I now have re-purposed my old heatsink, and have been able to OC the CPU. I have been able to sustain queues of 10+ consecutive jobs over several days running at ~25-26 FPS. The CPU is pegged at a solid 100% for days on end. VERY excellent! Thanks again Vit!

 

[shank]

Well, I have been doing all those things on that list, isityours. My os is on a separate ssd. I reboot, run nothing except Meguivit and go do something else (like watch tv or play a console game), so there's no other cpu stress or disk transfers. Prerendering is checked, I think it's on by default. Thanks for the suggestions. This is getting frustrating now, just tried another attempt and an avisynth/mencoder crash with 6 mins left after 2 1/2 hours of (the prerendering?) encoding video.

However, after originally writing that, I changed the Main Thread's setting from Auto to 6 (to make it an even division in half) and both encodes since then have not had an avisynth/mencoder crash! So hopefully that will be the final step in getting this stable.

The quality that comes out of this is amazing. I've been ripping gravure dvds and comparing them to what's available for download from usual places and these rips I'm making are far better quality. And I don't even know anything special about encoding video. I'm simply using the default settings with this MeguIVit setup. It creates encodes that are higher resolution (i.e. keeping the original resolution, instead of shrinking), better video clarity, smoother video (fps), and in most cases the file size is smaller.

I hope more video content officially goes 60fps. The difference between it and 23-30fps is night and day. Just like in video games. I'm not sure how people argued that there's no difference between 30fps and 60fps. It's clearly smoother and allows more headroom when there's a lot of action.

 

[isityours]

My os is on a separate ssd

do you mean on a separate ssd (other than your os disk) or that your os disk is an ssd (which isnt relevant if you arent using it to rip on) and the disk you are using during ripping is a standard SATA platter type?
another member had trouble using his second ssd as a ripping disk. moving to a regular hard disk solved his problems (although it sounds as though you solved your problem of a threading issue).

in either case, processing bottlenecks at the CPU before the disk so there would be no speed increase anyway. not to mention the wear on the ssd.....if you are planning to do a lot of ripping it makes sense to have a cheap dedicated scratch disk, to save wear on your 'good' disks.

 

[Vitreous]

I changed the Main Thread's setting from Auto to 6 (to make it an even division in half)

Threads don't get attached to cores so there's no need to pick values related to your number of cores. Experiment until you find the highest value that is consistently stable. I know 11 threads is best for me on defaults but it may be lower for you.

I hope more video content officially goes 60fps. The difference between it and 23-30fps is night and day. Just like in video games. I'm not sure how people argued that there's no difference between 30fps and 60fps. It's clearly smoother and allows more headroom when there's a lot of action.

Any content that is interlaced can naturally be taken to 50fps (PAL) or 60fps (NTSC) with clear improvements in clarity and smoothness. However there has been resistance in a number of communities to make the change. Usual argument is that 60fps footage looks like cheap broadcast material compared to film at 24fps - but this is (subconsciously) making a mistaken link between the high production values seen in film with its low frame rate. Some say that the high frame rate gives them motion sickness, another form of 24/30fps over-familiarity, which passes. Also there is concern about 60fps rips taking twice as long to process and being twice as large. Neither of which is true, difference with latest MeguIVit is very minor on both counts. The changeover is inevitable now and 60fps rips are becoming more commonplace (IV, game footage, home video conversions, TV rips etc.). A few people still need 30fps on weaker machines, but once you're used to 60fps, 30fps looks primitive.

Nevertheless, those making rips at speed (i.e. some of those trying to make a few $ from direct downloads) will often use high-speed low-quality ripping methods - they're not concerned about the content, just getting it out there fast. With some exceptions, especially in the JI area where 60fps is the norm now (e.g. akiva uses MeguIVit for his JI releases)

And back to film: Peter Jackson is filming The Hobbit at 48fps, James Cameron is doing Avatar 2 at a higher frame rate too (48 or 60fps). Finally. I find 48fps suffers a little from the jumpiness we see at 30 so I hope 60fps becomes the new standard for film (I'd actually prefer around 80-90fps but that's not very practical).

 

[shank]

do you mean on a separate ssd (other than your os disk) or that your os disk is an ssd

I meant that my OS is on an ssd by itself. The ripping is done on a standard hdd. That's another weird issue I've heard lately involving ssd. I just found out part of Creatives issues with their sound card drivers involves having an ssd. And knowing Creative they'll half fix it in a year or two, then will say you have to buy the next card they release to fully "resolve" the problem.

ah, I didn't know threads weren't dependent on cores. I'll play with that number more then.

 

[Konata Izumi]

where can I download the latest meguIVit?
EDIT: never mind I found it.

how can I use meguIvit to re-encode [HQ] videos to 240p?

 

[Vitreous]

how can I use meguIvit to re-encode [HQ] videos to 240p?

Follow the instructions in this post for re-encoding at a different resolution.
However, the lowest resolution x264 presets in MeguIVit are for 360p. That might work, but as I guess it's for playback on a small device there may be limitations on the settings you can use (e.g. bitrate, reference frames, AVC level etc.). You may need to tweak the x264 settings, and for similar reasons you also may need to re-encode the audio too. Still the instructions remain the same.

 

[anandneemish]

in the beginning i too had problems with random crashes. since about 0.2.1 i have not had more than one or two and since switching to beat3 have not had a single one (that wasnt my fault).
i am always careful to:

encode on an internal disk that doesnt contain the os/os partition.
avoid cpu stress during encoding
avoid data transfers to/from the disk being used accessed during encoding (again refraining from using the OS partition disk).
use the prerendering feature (this is actually because i do dual 30/60 rips but stability did also improve).

i also reduced the clock (which you have already done)

this is all very elementary practice but it has had me crash free for at least 6 months (20-30 encodes)

Stability report: I am also VERY happy with beta 3. For me, it has been very stable with no crashes, UNLESS I pre-render.

[The last bit is very odd and flies in the face of your experience and Vit's. I am not technical enough to debug it. But for some reason, my rig will not tolerate a pre-render although it is supposed to provide more stability. It will always crash (as it did last night halfway thru a 10 disk batch - I forgot to uncheck "pre-render").]

While running this version which pegs all my cores at 100%, I am still able to run
- 1 torrenting program, 1 download manager
- multiple Chrome windows
- various applets like Notepad, calculator etc.

...AND at least one (and sometimes several) of the following:
- Photoshop CS5
- up to 3 simultaneous large file transfers (e.g. move from one disk to another, or flatten .iso file)
- Media Player Classic or Vlan
- mkvmerge or another video cropping tool
- a 2D intensive game that loads all textures into memory (very primitively implemented game, but I like)

Seriously, this version is ROCK SOLID!!

BTW Vitreous, I am becoming a 60fps convert. I am re-encoding a number of JIVs to 60fps. Beta 3 coupled with my moderately OC'ed 2600K makes the encode so fast that I no longer even think about the added time to do 60fps.

I am still hesitant to apply 60fps to most AV titles since many of those have low production value to start with, and I am not willing to allocate more space (~30%?) to those titles.

 

[Vitreous]

If pre-render makes things crash then disk access is the problem because pre-render writes 20x more data to the disk. Certainly disk access is sensitive when pre-rendering - writing large files to the same disk as the rip output can cause crashes. Maybe it's the disk you're writing to or other apps/services/background tasks you have running causing the problem. You won't be able to use much higher settings without pre-render, but you seem happy with the quality anyway.

I get crashes but that's because I use insane or experimental settings (e.g. my current rip is being processed with double bit-depth color). On the defaults, I could throw the computer out of the window and still not get a crash. I make intros for my rips, I usually rip these at the same time as the main rip - run a second MeguIVit which is located in another folder (and ignore the warnings). Having said that, the number of threads on a 6-core machine is a little high for my liking and could be prone to problems for some people.

Not sure 60fps is even as much as 30% larger any more, so even low quality material can be worth converting to double rate for... errr... smoother action...

 

[anandneemish]

If pre-render makes things crash then disk access is the problem because pre-render writes 20x more data to the disk. Certainly disk access is sensitive when pre-rendering - writing large files to the same disk as the rip output can cause crashes. Maybe it's the disk you're writing to or other apps/services/background tasks you have running causing the problem. You won't be able to use much higher settings without pre-render, but you seem happy with the quality anyway.

Yes, VERY happy with Preset=Slow, Source Match=1. Most of the times, I increase contrast with levels because the source DVDs look a little muddy.

As for multi-disk, Yes. VIDEO_TS located on disk 1. Temp dir located on disk 2 (this should be the one that has the insane amount data, right?). Final encoded product on disk 3.

All three disks have lots of room so I am not running into a full, fragmented disk prob. Anyway, not worth debugging since the workflow is working fine.

... so even low quality material can be worth converting to double rate for... errr... smoother action...

Smooth as buttah !!!

 

[Konata Izumi]

I'm planning to build a budget PC (really,really low budget)for re-encoding videos with MeguIVit. What are the things I should consider?
I really don't like spending money on GPU card.

I have AMD Phenom II X2 550 Black Edition right now...
but I'm using a motherboard that don't support unlocking cores and only support DDR2 RAM.

should I just upgrade this machine's motherboard that will allow DDR3 RAM and supports unlocking cores? this is cheaper but I'm not sure if its wise to thing to do..


I think my AMD Phenom II X2 550 is very underpowered compare to the new Intel Sandybridge processors

 

[Vitreous]

Despite my software development know-how I'm not much of a hardware fanatic, so others may have better advice for your specific system. However, for efficient performance MeguIVit needs:
- 4 or 6 cores, 6 is not that much better due to the threading issues endlessly discussed above.
- As high a clock speed as you can get stable [but it needs to be VERY stable, MeguIVit is meaner than Prime95, and you'll be running it 24/7]
- Fast memory, DDR3 helps but exactly how much I don't know - I have never compared DDR2 with DDR3 directly
- However, you don't actually need a lot of memory since MeguIVit is a 32-bit app. 4Gb will do (or even 3Gb on a bare system, but that might be awkward)
- Disk drive is used a lot, but I haven't found too much difference between them, so choice here seems less important. SSDs have been reported to have issues with MeguIVit.
- GPU unimportant, it isn't used. Could even use motherboard graphics.

Obviously that still leaves you with a lot of scope to select specific components based on your budget and what you have to hand.

 

[anandneemish]

I'm planning to build a budget PC (really,really low budget)for re-encoding videos with MeguIVit. What are the things I should consider?
I really don't like spending money on GPU card.

As Vitreous said, don't spend money on the GPU.

Unfortunately, "low budget" and "encoding" just don't go together. Unless the PC is a standalone/dedicated encoder and you don't mind many hours per encode.

What is your budget?

You might want to consider an i7 2500K with 4GB of memory and WITH on-board graphics (this will save you money). But, budget motherboards don't facilitate overclocking. The "K" processors just cry out to be overclocked. And fast CPU clock is where you will see the most gain in encode speed (and the additional cores).

 

[youmeus]

That seems slow. Are you using a suitable preset? "Super Fast" is where to start, there isn't so much need for precision on such high resolutions. Typically you need better and better presets the more you intend to upscale. As you don't usually upscale HD, then you can use the faster presets.

Just tested on a i7@2.8Ghz and I get 13-15fps pre-render speed on 1080i with the defaults on MeguIVit 1.0 beta 3. Second pass (x264) is slower at 9-10fps. Done in a single pass (no pre-render) at 4 & 1 threads I get 6-8 fps, which shows that removing pre-render can be an advantage for HD if you can get it stable. My machines are not typical, I have some more recent plugins, and the video was fairly simple content, but this shows that your figures are off somehow...

Edit: One other note, you sometimes need to click the "Switch Parity" checkbox on the "Advanced Config" tab when ripping Blu-ray. Do this if the output is jumpy, not smooth (frame order is 2,1,4,3,6,5 etc.)

Sorry for not following up on your post Vit, I've been in China all month and found that Chinese censor wouldn't let me connect to Akiba-Online so...

I found that the File Indexer corrects the parity issue for me as well. I did a "Super Fast" encode off of the MKV File Indexer generated for me and it ran roughly 5-6fps all the way without pre-render (I'm getting errors with pre-render always, FFMPEG and Mencoder) so it turned out just fine. "Super Fast" is indeed more than good enough for 1080i content so I'll stick with that
Manually decreasing threads ensured that I didn't ran out of memory so Thanks again

 

[Joey007]

Thanks AKIBA for such a great app, not only is it portable, it is also easy to use. I also appreciate the instructions.

 

[isityours]

hi vit.

im doing a 480x720 rip of this
[hide]General
Complete name : IMBD-029_MP4\tomoe.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 3.07 GiB
Duration : 58mn 24s
Overall bit rate : 7 524 Kbps
Encoded date : UTC 2011-08-27 06:15:34
Tagged date : UTC 2011-08-27 06:15:34
Writing application : Yamb 2.1.0.0 [http://yamb.unite-video.com]

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Format settings, GOP : M=1, N=32
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 58mn 24s
Bit rate mode : Variable
Bit rate : 7 310 Kbps
Maximum bit rate : 62.3 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.059
Stream size : 2.99 GiB (97%)
Writing library : x264 core 114 [Rev.1924M-1 Core2]win32
Encoding settings : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x3:0x113 / me=umh / subme=9 / psy=1 / fade_compensate=0.00 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / fgo=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=7310 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=38 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2011-08-27 06:15:34
Tagged date : UTC 2011-08-27 06:16:44

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 58mn 24s
Bit rate mode : Variable
Bit rate : 192 Kbps
Maximum bit rate : 240 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 79.9 MiB (3%)
Encoded date : UTC 2011-08-27 06:16:43
Tagged date : UTC 2011-08-27 06:16:44[/hide]

i demuxed it and am using the h264 stream (current log file)
[hide][Information] Log
-[Information] Versions
--[Information] [8/31/2011 3:11:35 AM] MeGUI Version : 0 (svn)
--[Information] [8/31/2011 3:11:35 AM] OS : Windows Seven Ultimate Edition x64 (6.1.0.7600)
--[Information] [8/31/2011 3:11:35 AM] Latest .Net Framework installed : 4.0 (4.0.30319)
--[Information] [8/31/2011 3:11:35 AM] Avisynth Version : 9/19/2009 1:36:58 PM
-[Information] OneClick
-[Information] Log for job97 (idx, tomoe_track1.h264 -> tomoe track1_Rip.dga)
--[Information] [8/31/2011 3:12:46 AM] Started handling job
--[Information] [8/31/2011 3:12:46 AM] Preprocessing
--[Information] [8/31/2011 3:12:46 AM] Job commandline: "C:\meguIV\MeGUI\tools\dgavcindex\dgavcindex.exe" -i "I:\ripping room\tomoe_track1.h264" -o "I:\ripping room\tomoe track1_Rip.dga" -e -h -a
--[Information] [8/31/2011 3:12:48 AM] Indexing started
--[Information] [8/31/2011 3:14:51 AM] Standard output stream
--[Information] [8/31/2011 3:14:51 AM] Standard error stream
--[Information] [8/31/2011 3:14:51 AM] Postprocessing
--[Information] [8/31/2011 3:14:51 AM] Job completed
-[Information] Log for job98 (oneclick, tomoe_track1.h264 -> )
--[Information] [8/31/2011 3:14:51 AM] Started handling job
--[Information] [8/31/2011 3:14:51 AM] Preprocessing
--[Information] [8/31/2011 3:14:52 AM] OneClick processing started
--[Information] [8/31/2011 3:14:52 AM] Processing thread started
--[Information] [8/31/2011 3:14:52 AM] Desired size:
--[Information] [8/31/2011 3:14:52 AM] Split size:
--[Information] [8/31/2011 3:16:05 AM] Autocrop values
---[Information] [8/31/2011 3:16:05 AM] left: 0
---[Information] [8/31/2011 3:16:05 AM] top: 0
---[Information] [8/31/2011 3:16:05 AM] right: 0
---[Information] [8/31/2011 3:16:05 AM] bottom: 0
--[Information] [8/31/2011 3:16:05 AM] Auto-detect aspect ratio now: False
--[Information] [8/31/2011 3:16:05 AM] Output resolution: 852x480
--[Information] [8/31/2011 3:16:05 AM] Created Avisynth include file for custom processing: I:\ripping room\tomoe track1_Rip.inc
--[Information] [8/31/2011 3:16:05 AM] Automatic deinterlacing: False
--[Information] [8/31/2011 3:16:05 AM] Generated Avisynth script
---[NoImage] global MeGUI_darx = 889
---[NoImage] global MeGUI_dary = 500
---[NoImage] Import( GetScriptName() + ".inc" )
---[NoImage] (Inc_CacheMemory > 0) ? SetMemoryMax( Inc_CacheMemory ) : NOP()
---[NoImage] (Inc_MainThreads != 1) ? SetMTMode( 5, Inc_MainThreads ) : NOP()
---[NoImage] LoadPlugin("C:\meguIV\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
---[NoImage] AVCSource("I:\ripping room\tomoe track1_Rip.dga")
---[NoImage] (Inc_MainThreads != 1) ? SetMTMode(2) : NOP()
---[NoImage] horizCrop = Width() % 2
---[NoImage] vertCrop = Height() % ((Inc_InputType == 0 || Inc_InputType == 2 || Inc_InputType == 3) ? 4 : 2)
---[NoImage] Crop( 0, 0, -horizCrop, -vertCrop )
---[NoImage] ConvertToYV12()
---[NoImage] Inc_Parity ? ComplementParity() : NOP()
---[NoImage] trim(Inc_TrimStart,Inc_TrimEnd)
---[NoImage] (Inc_BlackLevel != 0 || Inc_WhiteLevel != 255 || Inc_Gamma != 1.0) ? Levels( Inc_BlackLevel, Inc_Gamma, Inc_WhiteLevel, 0,255, false) : NOP()
---[NoImage] Inc_PassThrough ? \
---[NoImage] QuickTGMC( InputType=1, TR0=0, TR1=0, TR2=Inc_TR2, Rep0=0, Rep2=0, SMode=0, SLMode=0, Sbb=0, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, EdiThreads=Inc_SubThreads ) : \
---[NoImage] (Inc_TR2 == -1) ? \
---[NoImage] QuickTGMC( Inc_Preset, InputType=Inc_InputType, Sharpness=Inc_Sharpness, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] FPSDivisor=Inc_FPSDivisor, ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, \
---[NoImage] SourceMatch=Inc_SourceMatch, Lossless=(Inc_MatchBoost ? 2 : 0), EdiThreads=Inc_SubThreads ) : \
---[NoImage] QuickTGMC( Inc_Preset, InputType=Inc_InputType, Sharpness=Inc_Sharpness, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] FPSDivisor=Inc_FPSDivisor, ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, TR2=Inc_TR2, \
---[NoImage] SourceMatch=Inc_SourceMatch, Lossless=(Inc_MatchBoost ? 2 : 0), EdiThreads=Inc_SubThreads )
---[NoImage] Inc_EdgeClean ? EdgeClean( Radius=1.0, DehaloRad=2.5 ) : NOP()
---[NoImage] Inc_InterpolateFPS ? QFPSx2() : NOP()
---[NoImage] #crop
---[NoImage] Lanczos4Resize(852,480) # Lanczos4 (Sharp)
---[NoImage] (Inc_MainThreads != 1) ? Distributor() : NOP()
---[NoImage] function GetScriptName()
---[NoImage] {
---[NoImage] try { assert(false) }
---[NoImage] catch(err_msg)
---[NoImage] {
---[NoImage] err_msg = MidStr( err_msg, FindStr(err_msg, "(") + 1 )
---[NoImage] return LeftStr( err_msg, StrLen(err_msg) - FindStr(RevStr(err_msg), ".") )
---[NoImage] }
---[NoImage] }
--[Information] Eliminating duplicate filenames
---[Information] [8/31/2011 3:16:08 AM] Video output file: I:\ripping room\tomoe track1_Rip_Video.264
---[Information] [8/31/2011 3:16:08 AM] Muxed output file: I:\ripping room\tomoe track1_Rip.mkv
--[Information] [8/31/2011 10:31:40 AM] Postprocessing
--[Information] [8/31/2011 10:31:40 AM] Job completed
-[Information] Log for job99 (video, tomoe track1_Rip.avs -> hfyu_tomoe track1_Rip.avi)
--[Information] [8/31/2011 10:31:40 AM] Started handling job
--[Information] [8/31/2011 10:31:41 AM] Preprocessing
--[Information] [8/31/2011 10:31:41 AM] Avisynth input script
---[NoImage] global MeGUI_darx = 889
---[NoImage] global MeGUI_dary = 500
---[NoImage] Import( GetScriptName() + ".inc" )
---[NoImage] (Inc_CacheMemory > 0) ? SetMemoryMax( Inc_CacheMemory ) : NOP()
---[NoImage] (Inc_MainThreads != 1) ? SetMTMode( 5, Inc_MainThreads ) : NOP()
---[NoImage] LoadPlugin("C:\meguIV\MeGUI\tools\dgavcindex\DGAVCDecode.dll")
---[NoImage] AVCSource("I:\ripping room\tomoe track1_Rip.dga")
---[NoImage] (Inc_MainThreads != 1) ? SetMTMode(2) : NOP()
---[NoImage] horizCrop = Width() % 2
---[NoImage] vertCrop = Height() % ((Inc_InputType == 0 || Inc_InputType == 2 || Inc_InputType == 3) ? 4 : 2)
---[NoImage] Crop( 0, 0, -horizCrop, -vertCrop )
---[NoImage] ConvertToYV12()
---[NoImage] Inc_Parity ? ComplementParity() : NOP()
---[NoImage] trim(Inc_TrimStart,Inc_TrimEnd)
---[NoImage] (Inc_BlackLevel != 0 || Inc_WhiteLevel != 255 || Inc_Gamma != 1.0) ? Levels( Inc_BlackLevel, Inc_Gamma, Inc_WhiteLevel, 0,255, false) : NOP()
---[NoImage] Inc_PassThrough ? \
---[NoImage] QuickTGMC( InputType=1, TR0=0, TR1=0, TR2=Inc_TR2, Rep0=0, Rep2=0, SMode=0, SLMode=0, Sbb=0, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, EdiThreads=Inc_SubThreads ) : \
---[NoImage] (Inc_TR2 == -1) ? \
---[NoImage] QuickTGMC( Inc_Preset, InputType=Inc_InputType, Sharpness=Inc_Sharpness, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] FPSDivisor=Inc_FPSDivisor, ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, \
---[NoImage] SourceMatch=Inc_SourceMatch, Lossless=(Inc_MatchBoost ? 2 : 0), EdiThreads=Inc_SubThreads ) : \
---[NoImage] QuickTGMC( Inc_Preset, InputType=Inc_InputType, Sharpness=Inc_Sharpness, ForceTR=(Inc_InterpolateFPS ? 1 : 0), \
---[NoImage] FPSDivisor=Inc_FPSDivisor, ShutterBlur=Inc_ShutterBlur, ShutterAngleSrc=Inc_ShutterAngleSrc, ShutterAngleOut=Inc_ShutterAngleOut, \
---[NoImage] EZDenoise=Inc_Denoise, EZKeepGrain=Inc_KeepGrain, NoisePreset=Inc_NoisePreset, TR2=Inc_TR2, \
---[NoImage] SourceMatch=Inc_SourceMatch, Lossless=(Inc_MatchBoost ? 2 : 0), EdiThreads=Inc_SubThreads )
---[NoImage] Inc_EdgeClean ? EdgeClean( Radius=1.0, DehaloRad=2.5 ) : NOP()
---[NoImage] Inc_InterpolateFPS ? QFPSx2() : NOP()
---[NoImage] #crop
---[NoImage] Lanczos4Resize(852,480) # Lanczos4 (Sharp)
---[NoImage] (Inc_MainThreads != 1) ? Distributor() : NOP()
---[NoImage] function GetScriptName()
---[NoImage] {
---[NoImage] try { assert(false) }
---[NoImage] catch(err_msg)
---[NoImage] {
---[NoImage] err_msg = MidStr( err_msg, FindStr(err_msg, "(") + 1 )
---[NoImage] return LeftStr( err_msg, StrLen(err_msg) - FindStr(RevStr(err_msg), ".") )
---[NoImage] }
---[NoImage] }
--[Information] [8/31/2011 10:31:43 AM] Job commandline: "C:\meguIV\MeGUI\tools\mencoder\mencoder.exe" "I:\ripping room\tomoe track1_Rip.avs" -o "I:\ripping room\hfyu_tomoe track1_Rip.avi" -of avi -forceidx -ovc lavc -nosound -lavcopts vcodec=ffvhuff:vstrict=-2red=2:context=1 -nofontconfig
--[Information] [8/31/2011 10:31:44 AM] Encoding started[/hide]

it is currently processing at about 20fps (first pass) but CPU utilisation is only between 15-40%. is this low? your previous comments suggest that processing speed is about right.
when i tried the same process previously, CPU utilisation was higher (around 80%). also, the first time i set this project running it didnt get above 2 fps. starting again got it going as it is now.

 

[Vitreous]

it is currently processing at about 20fps (first pass) but CPU utilisation is only between 15-40%. is this low? your previous comments suggest that processing speed is about right.
when i tried the same process previously, CPU utilisation was higher (around 80%).

Yes - as resolutions and processing become more extreme, you tend to get CPU under-utilization. I think there are two factors:
- More disk access, threads stall waiting for the disk I/O
- Threads stall waiting for each other. This is hard to explain: If thread 1 and thread 2 try to do the same process or use the same data, then one thread will sometimes need to stall while it waits for the other to finish. With lower settings there are several equally weighted tasks in the algorithm, so each thread tends to be working on a different task and this kind of thing happens less often. With higher settings, one or two tasks become much more complex (the motion and interpolation searches) and the threads end up getting bottlenecked by those processes and stall frequently
Stalled threads can reduce CPU load. Increasing threads might help, but will run you out of memory very fast at HD.

However, exactly how much CPU load you should get at HD I can't recall - I'll test later. Also I can't tell your exact settings from the above, the defaults?

 

[isityours]

thanks for the answer. at least i know its nothing to be concerned about.

i believe i used Very Fast and Quality+1 but it could have just been the default settings.

 

[shank]

Hey Vit, I have a few questions. But first would like to say that the final stability issue was with the number of threads. It hasn't crashed since I started changing it from Auto to 8 everytime. I wish it saved that setting! So maybe the Auto setting was choosing a number that was too high for my cpu. Also, CPU-Z reports that my processer (PhenomII x6 1090T) only has 6 threads. Odd, I thought there's supposed to be more threads than cores.

I noticed Meguivit allows you to choose between creating an mkv or an mp4. I've made everything mkv (partly because I didn't know mp4 was an option), but also because I know it supports practically any video, audio, sub, etc stream. I've been thinking about making mp4's from now on, because even though I believe mkv is the better container, it gets very little commercial support from typical hardware your standard user would buy, so it is useless to a lot of players.

If I were to choose mp4 as the container, does that change any of the settings in meguivit? I'm not sure if mp4 standards have limitations and if you coded the software to automatically change some quality settings if the user chooses mp4 as the container.

If there's no change when creating mp4 instead of mkv, then I would like to go back to the previous mkv's I made, demux the video, audio and chapters, and remux them into an mp4 without re-encoding or quality loss. Is that feasible?