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

[Vitreous]

That's just strange. Ignoring the actual playing time first, the differences between the three extractions are a little inconsistent. Not sure exactly what you did about drop frames there, but the differences there a bit like look like the effect of drop frames, just a few seconds over the DVD. Still a bit odd though...

But that's not the main problem, an error over the entire DVD in minutes is not drop frames. It's like the playback framerate is different or something.

Simple test. Chapter 2 runs for about a minute, but it's 10 seconds shorter on your "actual" chapter points. So drop the ISO itself in VLC, play that chapter and time it on your computer clock (don't trust the player time). Then play back the same chapter on the rip and time it. Same time? Any missing sequences? Audio in sync?

 

[snakeboy]

Your suggestion gave me a great idea and I believe I found the problem.
What I did was load up the ISO in VLC player and hit pause as soon as the Japanese writing at the start of the DVD begins to fade out.
I then loaded up the rip in a copy of VLC portable and played it, as soon as the Japanese text began to fade, I hit "play" on the other window and voila, two instances playing at (almost) the EXACT same time.

Now I could watch to see if anything was different between the rip and ISO as they played together "live", and yes, there was. Very early on, around 43 seconds into the rip there's a distorted frame (in the rip), but it plays as normal except they're out of sync. Big time. But this is the strange part: The footage that plays after the distorted frame is the scene from the DVD which appears at 35 seconds. Clearly some sort of corruption/error in the rip.

I then tried the same thing with the other rip I created earlier to test with default settings. Same glitch, same place.

I then played the extracted VOB used to make the rip directly with VLC, no glitch, so where's it coming from? No (visible) glitch from the VOB no glitch from the ISO.

Is it possible there is a problem there that doesn't appear when the VOB is played? Should I re-rip the ISO? If so, what is my next best choice after DVD Decryptor?

 

[Vitreous]

There must be more than one glitch because it's out by several minutes by the end, not just 35 seconds.

Extracting the ISO should be trivial, it's just an archive. Doesn't seem likely that would go wrong. I just use 7zip.

Could be a corrupted download. VLC can quickly recover from a corrupt data (one of it's few strengths) maybe only dropping a frame or two, whereas dgindex (used to read the file when encoding) tends to skip short blocks where it finds problems. That would be consistent with what you're seeing.

To test this type this into a .avs file, updating the paths, then play that file directly in MPC or Virtualdub or something:

LoadPlugin("YourPathTo\DGDecode.dll")
DGDecode_mpeg2source("YourPathTo\TheD2Vfile.d2v")

That will give you dgindex's view of the ISO. Does it have the same corruption?

 

[snakeboy]

Re-indexed the file, ran the .avs script in MPC and yes, I still see the glitch.

 

[Vitreous]

Then it's the source or dgindex.

Try getting the latest dgindex.
Try FFVideoSource instead of DGDecode_mpeg2source.
Try redownloading the file.

 

[snakeboy]

Then it's the source or dgindex.

Try getting the latest dgindex.

Confirmed that the version I have is the latest. (DGMPGDec Version 1.5.8) The SHA-1 of the .dll I have and the one in the 1.5.8 binary are identical.

Try FFVideoSource instead of DGDecode_mpeg2source.

Okay, the .ffindex file produced by the ffms2.dll does NOT contain the glitch. So I'm going to assume it must be a dgindex issue then. I'm going to proceed with an encode now and see what comes out the other side

Try redownloading the file.

It doesn't look like this will be necessary. Fingers crossed.

Edit: OK, easier said than done I guess. Firstly could not get FFVideoSource to process the audio. Solved that, but how do I get a .ffindex file to be processed by a Vit script? The one-click won't accept it as a source and sending it straight to processing after being indexed causes MegUI to spit out all sorts of errors. I'm sure there's an easier way, I just don't know what it is. Point me in the right direction please?

Nevermind, solved it

 

[Vitreous]

What did you do out of interest? I would have suggested starting an encode, stopping it and editing the avs to change the source filter, then restarting.

 

[snakeboy]

Thats pretty much what I did, although I have to admit to referring to some scripts I googled with references to .ffindex files for idea's.

 

[guy]

Some exciting news on the decoding end of things. Intel has been working to enable hardware decoding with its latest QuickSync-compatible processors for ffdshow (the core decoder component for packages like CCCP).

It might not be a huge improvement for the higher-end Core i5-2xxx and i7-2xxx users (since raw CPU performance is already excellent for ffdshow), but it could be a huge boon for lower end i3-2xxx users (particularly bargain laptops), potentially enabling them to watch very high-bitrate/framerate videos with minimal resource usage.

http://www.anandtech.com/show/4895/intel-engineer-ports-quicksync-video-decoding-to-ffdshow

 

[youmeus]

Hi guys

I just decrypted a Blu-ray I purchased off the web, only to find that it contains VC-1 streams. I managed to mux that into an MKV container. However, the One-Click encoder in the latest edition of MeguiVit doesn't support VC-1 even in MKV right? At least that's what MeguiVit tells me, that this type of file can't be processed with One-Click.
Anyway I was able to load the file manually in Avisynth with FFVideoSource. However I am used to encoding with the One-Click in MeguiVit but now that I need to encode this one manually I am wondering, should I just deinterlace with the script QuickTGMC( preset"Fast" ) for a comparable quality to the One-Click encoder? Because the scripts that the One-Click encoder generates are way above my league. I have no need for source matching, edge clean etc.
I use the 1080p 60fps default x264 preset with no pre-render. The source is VC-1 AP@L3 1080i60, now in an MKV container.



EDIT:

Well apparently the video encoding never seems to start, it's been sitting at "Encoding video..." for 10mins now without actually counting any processed frames. Doesn't hang, but just doesn't start to process the video.
When originally loading the video with FFVideoSource it hangs for 10-15mins or so while it creates the ffindex, but this is perfectly normal I take it?
Anyway someone suggested to use DirectShowSource as source filter for VC-1 content in m2ts files so I'll give that a go soon - If I can't the actual encoding process to begin my initial is kinda obsolete andalaugh:

 

[Vitreous]

Never tried VC-1 streams so I can't help you with that except to say that if you can play it in MPC then DirectShowSource should work (or DSS2).
Using QuickTGMC( preset="Fast" ) or whatever will be fine provided you can get the source to load. Can usually skip other processing for blu-rays.

 

[youmeus]

Never tried VC-1 streams so I can't help you with that except to say that if you can play it in MPC then DirectShowSource should work (or DSS2).
Using QuickTGMC( preset="Fast" ) or whatever will be fine provided you can get the source to load. Can usually skip other processing for blu-rays.

Thanks for the fast reply mate

The "Encoding video..." stage hang there without starting for 20 or so and then began processing the video at the same speed as the "Fast" preset with the One-Click encoder. Then it froze at 98% and the output at that time was just black frames basically. I'll give DirectShowSource a go. Thanks

 

[youmeus]

DirectShowSource should work (or DSS2).

DirectShowSource just crashed MeguiVit all together every time.
But DSS2 worked. Avisynth now renders the preview pretty fast and displays the image with pixelated blocks or anything.

This was my script:

LoadPlugin("C:\meguIV\Avisynth 2.5\plugins\avss.dll")
dss2("C:\Users\Users\Desktop\filename.mkv", fps=29.97 )
QuickTGMC( Preset="Fast" )

Should anyone else have to deal with this type of source, interlaced VC-1 in m2ts files (HD-DVD, Blu-ray) I thought I'd just point out what I did.

1. Decrypted the Blu-ray.
2. Remuxed the largest of the m2ts files into an MKV container (eac3to for the AC3 audio) using the File Indexer bundled with MeguiVit.
3. Ensured that I had WMP 11 installed.
4. Installed the latest K-Lite Mega Codec Pack (7.7).
5. Set VC-1 to use wmv9 as decoder in ffdshow video decoder configuration.
6. Checked Microsoft as preferred DirectShow decoder for VC-1 in Win7DSFilterTweaker 4.6.
7. Grabbed the DSS2 plugin file avss.dll from Programs(x86)/K-Lite Codec Pack/Filters/Haali and copied it to my Avisynth plugins folder.

Now I was able to decode the VC-1 stream properly with this script, loading the plugin first and using DSS2 instead of regular DirectShowSource:

LoadPlugin("C:\meguIV\Avisynth 2.5\plugins\avss.dll")
dss2("C:\Users\Users\Desktop\filename.mkv", fps=29.97 )
QuickTGMC( Preset="Fast" )

I hope some you guys can use it.

However, there is one thing that struck me when playing back the sample I encoded, perhaps you know what this phenomena is.
In the two images I attached you see two consecutive frames, frame1 and frame2. In frame2 the bright red color leaves very noticeable strong colored artifacts, particularly near the edges of the girl's sleeve. It doesn't seem to be present when previewing the Avisynth script without deinterlacing but as soon I add QuickTGMC it becomes visible. I believe I read about this somewhere, is it a result of color interlacing or is it just because the movement in the image is so great that the QuickTGMC has a hard time dealing with it? Apparantly there is nothing like this throughout the remainder of the movie, but then again there are no more scenes like this i.e. bright red, very great movement.

Lastly I'd just like to hear whether its fine to leave the threads at 0 (automatic) in your x264 presets? Because I am not pre-rendering but encoding directly to x264 due space issues. In the One-Click encoder of MeguiVit it was easy to just set the threads to your liking but since I am encoding this one manually I thought I'd ask. I am using a 2.2Ghz quad core i7 processor and while previewing the script above I quickly got the C++ runtime error if I advanced the frames too quickly or pulled the skimming slider back and forth.

 

[Vitreous]

Thanks for the detailed information, glad you got it working.

The image is showing some kind of chroma ghosting. Video images are split into luma (brightness) and chroma (color). The chroma is stored at a lower resolution as it is generally less visible except in extreme cases such as this. The faster presets in QuickTGMC simplify chroma processing to gain speed as that won't be so noticeable in general. The example you've given seems surprisingly bad for Preset="fast", which is a decent preset. Maybe it could be fixed with this...?
QuickTGMC( Preset="Fast", ChromaMotion=true )

Threads=0 (automatic) will give you 1 thread per logical core, 8 threads on your machine. That might be OK at "Fast", but it's probably a bit close for comfort. Reducing it a little may help with stability. And/or you could try setting Cache Memory to 400, 600 or 700, one of which may help.

 

[youmeus]

Thanks for the detailed information, glad you got it working.

The image is showing some kind of chroma ghosting. Video images are split into luma (brightness) and chroma (color). The chroma is stored at a lower resolution as it is generally less visible except in extreme cases such as this. The faster presets in QuickTGMC simplify chroma processing to gain speed as that won't be so noticeable in general. The example you've given seems surprisingly bad for Preset="fast", which is a decent preset. Maybe it could be fixed with this...?
QuickTGMC( Preset="Fast", ChromaMotion=true )

Threads=0 (automatic) will give you 1 thread per logical core, 8 threads on your machine. That might be OK at "Fast", but it's probably a bit close for comfort. Reducing it a little may help with stability. And/or you could try setting Cache Memory to 400, 600 or 700, one of which may help.

I tried the script above with ChromaMotion=true but it didn't really seem to make any difference as far as I could see. Setting the preset to slow didn't seem to make a difference either. Anyway its only in this particular scene that these artifacts occur so it doesn't really matter to me.

I set the memory to 700 at the beginning of the script and set the number of threads to 4 in the x264 config pane. That's half of what I'll be using with automatic right? The vid is nearly two hours long so it'll take 24 hours to encode it with the Fast preset. I'll give it a go and see if it can pull through.

Thanks for the help mate

 

[Vitreous]

I tried the script above with ChromaMotion=true but it didn't really seem to make any difference as far as I could see.

Is it maybe a problem in the source? Or perhaps DSS2 is not delivering frames correctly - source filter problems can lead to randomly occurring visual issues. Or it's a bug in QuickTGMC but a very, very rare one... If you see the problem again then it would be helpful to post a snippet of the source.

 

[youmeus]

If you see the problem again then it would be helpful to post a snippet of the source.

Alright I'll be sure to do that. The rest of the encode came out just superb
Thanks

 

[youmeus]

By the way mate if I want to hardcode subtitles into a movie with MeguiVit can I do this at the end of the script that the One Click encoder generates? I.e with SupTitle("C:\subtitle....? That should work shouldn't it?
This particular source that I want to hardsub isn't interlaced, so I thought I'd might try encoding it with progressive postprocessing preset, as I don't want the source cleaned up too much - I assume that's what the progressive repair and stabilise modes do.

Furthermore it's another VC-1 source in 1080p. But I guess it won't have the previous issues of chroma ghosting as it's progressive...

 

[Vitreous]

Not tried it, but you should be able to put extra processing like hard subs just before the line that contains "...Distributor()...". Just don't trim the start if you intend to do this.

By default, progressive post-processing will do nothing other than re-encode your content with x264. You switch on any features you wish to use (smoothing, noise processing, levels etc.), but you don't have to. If you don't switch anything on (or not much), then don't bother with a pre-render pass.

Progressive stabilize will deshimmer and clean up a little (denoise+sharpen). Tweak sharpness and smoothing to taste in this mode.

 

[youmeus]

Progressive stabilize will deshimmer and clean up a little (denoise+sharpen). Tweak sharpness and smoothing to taste in this mode.

I am not sure which preset to use, but as this is a hollywood movie I think I'll try with just the post-processing preset to get as close a resemblance to the original.
I'll definitely try with the SubTitle and see if it works as intended.