Hi all, this is my first post here. I'm absolutely zero tech-savvy (the litte I know, I learned it in the last few days reading this forum) and English isn't my mother language, so please be patient! Also, I'm not sure if this is the proper way to create a thread, as there are a few things I'd like to ask which could be treated separately, so feel free to correct me and I'll edit the thread accordingly.
My goal: Convert some old 4:3 NTSC DVDs into any type of format that makes sense (for PC / TV playback).
As far as I can see, playback deinterlacing isn't very reliable. I get different results in VLC than PotPlayer even after fiddling with the deinterlace settings (which I'd rather not do every time), so I'll probably need to deinterlace at encoding. I've read about the subject here and general consensus seems to be that QTGMC at double frame rate is usually the best option for purely interlaced material. Without really knowing what I was doing (I still don't), I was able to apply QTGMC with StaxRip (because I read that I didn't need to deal with AviSynth, which scares the hell out of me, although I'm eager to learn). I was impressed with the results. Whatever the filter does, it looks much smoother compared to the original no matter what player deinterlacer I use.
The only problem I've had is some weird artifact/flickering thing that happens in a specific part with QTGMC or other deinterlacing methods that use double frame rate. I think it's because the original segment itself is weird, sort of an early-'90s cheap motion effect. Only double-rate versions have that flicker (which seems to be because each two fields become two distinct frames repeated a few times, instead of being blended together into one blurry frame as probably intended... jeez, I hope that makes sense when you watch the samples). I know it's a small nuance (the original doesn't look too good, either) but my concern is I have a bunch of these and I remember there were a lot of cheesy effects, graphics, etc. Is there anything that could be done to prevent things like these?
I'll attach a very small sample of:
1- interlaced video
2- an EEDI3 same-rate version I did
3- the QTGMC version (where the flicker is present).
Note that I cut the samples using FFMpeg in a very crude fashion, so please let me know if that's no good and which the right procedure would be.
b. Aspect Ratio
Ok, so I read a lot about PAR, SAR, ITU, non-ITU until my head exploded. I think I'm starting to understand it. But just to be sure, I wanted to ask something that's been bugging me. I tried cropping to 704x480 (2 pixels left, 14 pixels right) and letting StaxRip deal with the PAR calculations. I want to use ITU because it looks better to my eye, at least for this video. But I don't know what that Aspect Ratio Error is, why it is so high (9,69%) and if it should be a concern. I tried googling about it but I couldn't find anything that clarified this. I'm attaching an image of what the settings look like.
[Attachment 47458 - Click to enlarge]
c. Playback compatibility
This is a last-minute addition. I don't yet own the TV in which I'll be playing this yet, but I copied a few of the test files I've been making to a USB stick and tried playing them in a TV. For some reason, only the MKV made with MakeMKV and an interlaced version made with ffmpeg worked. The other ones (made with StaxRip) were deemed 'invalid files'. I know my process is all over the place (like this thread), so could you point out to any reason why this could happen or -even better- suggest a method to carry out the whole process as smoothly as possible?
Thanks in advance!
[Edit: I guess attachments don't work or need to be approved, so here's a WeTransfer link for the samples and the screen capture: https://we.tl/t-Z1SCjhm0bO ]
+ Reply to Thread
Results 1 to 30 of 96
Last edited by MGRV; 12th Dec 2018 at 04:03.
A) The flickery result of QTGMC is what you would see on an interlaced NTSC TV when viewing the source. The interlaced source consists of interlaced frames repeated for a total of 5 frames. Since the frames are interlaced and there was motion between the fields, the final picture on the TV bounces back and forth 5 times. With digits representing the field numbers: 010101010123232323234545454545... Your eedi sample discards every other field so you're left with 000002222244444...
B) Cropping the frame doesn't change the PAR. Think of a piece of graph paper. No matter how much you cut off the edges the remaining blocks remain the same shape. What changes is the overall shape of the paper (the SAR). The PAR for 4:3 NTSC video is 10:11.
DAR = SAR * PAR DAR is the final display aspect ratio, the shape of the final displaed picture SAR is the storage aspect ratio, the dimensions of the video frame, width:height PAR is the pixel aspect ratio, the width:height of individual pixels DAR = 704:480 * 10:11 DAR = 704 / 480 * 10 / 11 DAR = 1.3333... DAR = 4:3
Note: you may find confusing information about aspect ratios because the older terms DAR, SAR, PAR where changed in later documents to DAR (still Display Aspect Ratio), FAR (Frame Aspect Ratio), SAR (Sampling Aspect Ratio) to more correctly represent what they really mean (pixels have no shape, they are theoretically points with spaces between them horizontally and vertically). Also many programs don't differentiate between ITU and MPEG aspect ratios.
C) The videos made with StaxRip are encoded with 10 bits per channel. Very few devices support 10 bit h.264. Switch to 8 bit if you want wide compatibility.
Last edited by jagabo; 12th Dec 2018 at 10:00.
- My sister Ann's brother
I really didn't pay too much attention to the clip's length (I couldn't see the running time in DGIndex) but I guess it's long enough to see the pattern I was referring to.
Thanks for your reply!
StaxRip was using. It looks like I missed some of the acronyms when I updated the post. The post should have said "Cropping the frame doesn't change the PAR". I'll review the post and fix any remaining errors.
The ITU spec results in a non-integer frame size for the 4:3 image, 703.? by 480. Actually the active picture is 485 scan lines: 484 full lines, half a scan line at the top, and half a scan line at the bottom. In practice a few lines at the top and bottom are not captured and that remaining ~703x480 is rounded to 704x480. So none of the usual pixel aspect ratios is exact. 10:11 is value used for 704x480 -- I gave the math earlier. 8:9 is the value when following the DVD spec:
DAR = 720:480 * 8:9 DAR = 720 / 480 * 8 / 9 DAR = 1.3333... DAR = 4:3
In my experience DVD players are schizophrenic. They upscale the full 720x480 frame to 1440:1080 or 1920x1080 for HDMI output (following the DVD/MPEG2 spec) but At the composite/s-video outputs they follow the ITU spec.
Last edited by jagabo; 12th Dec 2018 at 10:02.
FFMpeg and then with either StaxRip or Handbrake (don't remember) and noticed the output was slightly wider and looked much better to me. I did some research (I didn't even know how to google it... "DVD aspect ratio conspiracy"?) and that's when I fell into the rabbit hole of aspect ratios and came across very informative posts, many by you. That's how I got to understand a bit of the whole deal about anamorphic video and this PAR/SAR/DAR nightmare. But I'm dumb, and it's a cofusing subject! So, aside from the fact that there seems to be no way to know for sure the exact aspect ratio of a commercial DVD, am I safe to assume what I'm doing is fairly accurate? I'm cropping 16 pixels in total (not 8 and 8 because the padding black bars in this one aren't equally distributed) to make it 704 and then using ITU PAR 10:11. I think I read that usually applies for NTSC 4:3 DVDs. If TVs or certain players don't use the ITU I'm setting, which one would they use? 8:9?
Last edited by jagabo; 12th Dec 2018 at 11:58.
So, with that out of the way, let me ask you a few more things about the process. I used MakeMKV to get -as I understand it- the same stream as the VOB files in a workable container. That MKV is what I used as the input in StaxRip. Is that an acceptable way to do it? I've never done any video encoding before, aside from a few basic (and probably wrong) things with FFMpeg. That means, I'm not familiar with any software, so I'm open to suggestions about better ways to handle the process. I'm just going by trial and error but I wouln't want to mess things up and find out later.
As I mentioned, the reason I used StaxRip was that I wanted to try QTGMC without having to delve too deep into so much new information. I just went whatever-whatever-QTGMC Medium-Next and didn't care much about the other options (except for the AR thing). Now, having seen the improvements, I'm sold on QTGMC, but wonder if I need to change any other settings on StaxRip (for instance, the 10-bit thing you mentioned, which I can't find yet!) or learn to do it some other way.
Thanks a lot for your help!
Last edited by LMotlow; 12th Dec 2018 at 16:24.- My sister Ann's brother
DVDFab (free version) to rip the DVD to a VIDEO_TS folder, DgIndex/Mpeg2Source/AviSynth to access the VOB files and to perform any filtering, x264 CLI to encode the video, and MkvToolnix to mux the resulting video and AC3 audio. This gives me full control of the processing and encoding. StaxRip seems to be doing a lot of this for you but you may occasionally run across DVDs that it can't handle properly. One example might be PAL/NTSC converted DVD -- see if StaxRip has the AviSynth filter called SRestore.
I couldn't find SRestore under the list of StaxRip AviSynth filters. Is that used specifically for PAL/NTSC converted DVDs or does it have other uses? I don't know how I would detect such a case, if I came across something like that.
$50 - $100 - Android Box or Raspberry Pi . Stick with the 4 star+ boxes on Amazon and the build quality is generally solid with higher cost giving you additional streaming features that you may not need.
$100 - $150 - Blu-Ray player. Be sure the player will play DVD .ISOs (if you have them) and .MKVs. Newer players may not support all types of video files.
$150+ - KDLinks, Nvidia Shield, laptop, HTPC. Note that the newer KDLinks models (e.g. A400) run Android and IMHO, doesn't warrant the premium over a $100 Android Box. While the Nvidia Shield is highly praised, most of the praise is for it's gaming capabilities, not the video capabilities.
Any these will play just about any video file you have and you won't have to fuss with having to reencode your videos to play on your TV's media player.
I do travel quite often though, and would like to have a copy of these DVDs that I can play pretty much anywhere. I'm not fanatical about it either, just trying to avoid something as my recent 10-bit depth fiasco that jagabo spotted.
Post what type of device you're planning to playback on, i.e. smartphone, tablet, Android, IPhone, etc. If you don't mind that large file size ~4 to 8GB, you could use VOBtoMPG to convert your ripped discs to mpeg files that will play on just about any device. If you want to make them smaller, which most people do, others here can recommend good programs and settings to compress your DVD rips (which are an exact copy and size as the files on the disc).
I have a few (interrelated... or interlaced?) questions about QTGMC.
1. I've noticed it removed a lot of noise from the original, but it's not clear to me whether that's just a by-product of deinterlacing itself or if it's actually applying some denoising as well (I read it can be set to do both). I don't know how much I can play around with its settings via StaxRip (I'll check later once it's done encoding my current test), but I'm ready to bang my head against the wall and struggle with AviSynth if need be. I'm very pleased with the results I got from just leaving it set to whatever the default is. If anything, I'd like to try a few variants with a tad less aggressive approach on noise reduction just to compare the results and see if it makes any difference to me. I don't think the noise on this DVD adds much of a 'natural' feel to it, so it's not something I want to keep, and I don't think too much detail gets lost. But just to try it out and judge it for myself.
2. Related to that, I've noticed QTGMC results are consistently smaller than other approaches given the same CRF (even those at half the frame rate). Is it possible that noise reduction plays an important role in such a noticeable difference? Just curious. I won't complain about lower filesizes!
3. Usually, I read the same thing regarding presets: "go as slow as you're willing to tolerate". However, I've also read that it's possible QTGMC reduces more noise in slower presets (or at least does a different job). Is that correct? Should I take speed into consideration aside from the usual "the slower, the more efficient" mantra?
Last edited by MGRV; 13th Dec 2018 at 02:13.
Just curious: I'm (still) Avisynth-illiterate. It took me a while to figure out what that script is doing, because it seemed counterintuitive that it crop 4 & 16 instead of 2 & 14 (which it makes up for in the 704 version adding 2 & 2). I suspect there's a technical reason for doing it that way?
Am I correct assuming FPSDivisor=2 is pretty much the same as SelectEven?
VirtualDub, there are 4 pixels of black on the left. On the right there are actually 15 pixels of border and noise, but you want at least 2 pixels in cropping, and there is also another pixel of ragged noise on the right, so 16 clears it all up without taking too much off the image. It also makes for even borders when you add new black borders. New black borders are also handy after color correction, which can affect border color that becomes obvious against the black backgrounds of wide screen displays.
FPSDivisor=2 is faster than SelectEven because it eliminates one field earlier in the processing (that's what I've read, anyway). It works both ways.- My sister Ann's brother
VirtualDub some time ago and probably couldn't get it to work), so let me ask you: I attached a m2v file here as you requested, but I see you somehow produced a d2v file from it, which is what the script calls. Is that correct? If I want to try your script, do I have to cut a sample again (and use the resulting d2v file which I previously discarded) or should I do whatever you did to get that file?
Also, I assume you meant it's always recommended to crop a minimum of 2 pixels per side? I get what you mean about borders and color correction. I don't plan to color-correct (unless it's being done without me even knowing) so I guess I shouldn't worry too much.
DgIndex to create a d2v (index) file.
* Mpeg2Source() is not included with AviSynth, it is a third party filter. You'll need to download the TIVTC package and put a copy of TIVTC.dll in AviSynth's plugins folder.
Last edited by jagabo; 13th Dec 2018 at 16:33.
When you download and unzip the DGMPGdec package, you'll find DGDecode.dll in the DGMPGdec folder. Copy DGdecode.dll into your Avisynth plugins folder. DGdecode.dll contains the Mpeg2Source function.
If you already downloaded TIVTC, keep it. It's used to reverse telecine in telecined video.
Last edited by LMotlow; 13th Dec 2018 at 17:39.- My sister Ann's brother
Thank you both for your help!
So, I used my own uploaded m2v file in DgIndex to get a d2v file.
I already had DGMPGDec installed, but I didn't know. I guess it's one of the many tools I installed while reading suggestions to other people's questions in the forum. I previously made the m2v file using DGIndex from an "Apps" folder that came with my StaxRip download (has fewer files compared to the DGMPGDec folder). Now I see it called "DGMPGDec DGIndex" in the download page. Are they the same thing?
Anyway, I followed the steps you provided but got an error message when trying to open the file in VirtualDub. It's complaining there is no "QTGMC" function. I only got QTGMC via StaxRip, so I assumed there had to be a QTGMC.dll file somewhere that I could throw into the AviSynth plugins folder. I checked but could only find the file QTGMC.avsi under \\StaxRip\Apps\Plugins\AVS\QTGMC so I'm not sure how to fix this (I'm not even sure I should be looking for a dll at all, I'm just aping what I was told to do before with the DGdecode.dll file).
Thanks again for your patience!
The problem is StaxRip has it's own private version of AviSynth and all its filters. Other programs don't know it's there. Opening an AVS script in VirtualDub requires a system installed version of AviSynth and all the required 3rd party filters. You have AviSynth installed so you should be able to use StaxRip's versions by manually importing them with import("X:\Path\toStatxrip's\plugins\QTGMC.avs") and LoadPlugin("X:\Path\toStatxrip's\plugins\plugin.na me.dll") for each of the required dll files. Or you can copy QTGMC.AVS and any missing dll files from StaxRip's plugins folder to AviSynth's plugins folder.
QTGMC.avsi would be a copy of the code for QTGMC, but the plugin actually requires several support plugins, a Windows system library file, and some VisualC runtimes. I don't use StaxRip except to encode occasionally but I don't use its Avisynth functions. It seems you should be able to edit the Avisynth script that StaxRip uses. If not, I'll attached a .zip file (NOTE: not attached. see EDIT and link below) of all the requirements updated as of Nov 2017, which uses the original QTGMC and is current except for some 16-bit versions of the plugin that you don't want at this point anyway. The .zip has subfolders with everything you need.
Create a new folder or subfolder somewhere for the .zip file, then download it to that folder. When unzipped, look first at the "READ ME FIRST.txt" file.
[EDIT] Videohelp's uploader isn't working, so use this link below for the original zip file compiled by an acquaintance of mine at digitalfaq.com:
When you have QTGMC and its support files you'll also have a handy bunch of popular standalone filters that are also used in several other high-octane plugins.- My sister Ann's brother
Thank you both.
Last edited by MGRV; 13th Dec 2018 at 21:39.
MeGUI that use Avisynth internally have customized their setup for their own use -- which might not always agree with the current state of a user-installed Avisynth setup. Also, the plugin support packages for QTGMC will differ for different versions of QTGMC. To date, the "safest" version of QTGMC.avsi is the "original" version 3.32. The support files in the .zip package are updates for that version. Later QTGMC versions are mostly compatible with those support files, but later versions require additional support pieces. For myself, I like playing it safe most of the time with the old "3.32" and storing updated and matching support filters in the official plugins folder. When I want to play with later and more experimental versions I have separate plugin folders for those, where I keep the new .avsi's and all of their support files, and which I explicitly load and import into a script by name and location.
It's been so long since I used freebies like StaxRip, Avidemux, etc., I don't recall in detail how they worked. I might be confusing Avisynth usage in StaxRips with usage in MeGUI or some other ancient app, I don't remember. Meanwhile I use and update my main in-system Avisynth installation "by the book", so to speak. This doesn't interfere with the free apps, and the free apps don't interfere with my Avisynth.
Two tips about building up Avisynth plugins:
First, don't download plugin packages into your plugins folder. Downloads usually have a bunch of files that aren't filters and that don't belong in the plugins folder. Make subfolders for those packages so you'll know where to find spare copies and documentation. Then, just copy the .dll, the .avsi, or the .avs plugin itself into the official folder. Otherwise you'll have a huge mess on your hands.
Sometimes a plugin in one of those packages will be older than the plugin you already have. It's safest to use the newer version. But keep the old one in a safe place. You never can tell. Sometimes the newest comes with a bug.
Last edited by LMotlow; 13th Dec 2018 at 22:12.- My sister Ann's brother