Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Usage

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th May 2020, 02:33   #161  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
I do not yet understand the organizing principle behind this TV show's use of various frame rates and content sources. All of the statements below are 100% true and I can back them up with specific scenes.

1). Much of the CGI footage is encoded at 23.976 progressive in Season 6. In other places, however, the CGI footage is 29.97 interlaced. This appears to be more common in Season 7.

2). The non-CGI sections of the show are mostly -- but not entirely -- in 23.976 fps. There are at least two places in "Sacrifice of Angels," where footage bounces up to 29.97 fps and then back to 23.976 fps in the middle of shooting a conversation between characters.

3). Sometimes, space shots are interlaced footage. Sometimes they are not. Sometimes, they are 29.97 fps. Sometimes they are not.

4). The credit sequence of the show is the ugliest, *ugliest* part of it, by far. The original DVD looks like it was recorded off someone's VHS. Watch when the camera pans over the station, in particular: https://www.youtube.com/watch?v=xL8nPEmLKLE

Fixing the credits the way you did is amazing, if only because they were so awful before.

I can *show* you something of the effect I am trying, specifically, to create. I created both of the videos below (please set YT to 4K -- and yes, while video takes a hit, you can still see the effect I'm specifically going for, so I'm not worried about it).

https://www.youtube.com/watch?v=DzeENB9JKmE

That's an upscaled MKV file of DS9. I took a pre-existing encode of the show and ran it through Topaz VEAI Gaia-CG. That's the result. When the clip starts, watch the leading edge of the Galaxy ship and how smoothly it moves towards the viewer. Watch the level of noise on the ship hulls. (I mostly care about the first 10 seconds of the clip as far as a demonstration of what I'm looking for).

Now compare it to this video (set for 4K) -- particularly how smoothly the approaching edge of the Galaxy saucer moves, but also hull noise and the like.

https://www.youtube.com/watch?v=8DwfHADU0QY

The file I call "Rubicon" is much smoother than the upscaled MKV, even though it's still running at 23.976 fps. But the production process for this image quality is whack as *hell*, and it can't be good for the file.

Start with a Handbrake CFR rip. Encode in AviSynth with the QTGMC process I posted originally + daa3mod. Run the result through DaVinci Studio Resolve, increasing the framerate to 119.88 fps. Then, run the result of *that* encode through AviSynth again via "ChangeFPS(24000, 1001)" filter to change the frame rate back to 23.976 fps.

Then upscale in Topaz VEAI.

This is obviously rather tortured, and there's evidence. The very first frame of the video (you may need to rewind to see it) shows a distorted stardrive deflector shield on the approaching Galaxy-class ship for a single frame.

What I like about Rubicon, specifically, is how it removes noise, has excellent smooth motion (to my eye, anyway -- I am not saying it couldn't be better), reduces flicker on the hulls of the ships (check the Galaxy-class vessel in the upper left for window flicker), and antialiases the hulls. Is there a gentler way to achieve this kind of frame rate improvement via IVTC?

Last edited by JoelHruska; 15th May 2020 at 03:10.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 04:43   #162  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
Originally Posted by JoelHruska View Post
Start with a Handbrake CFR rip. Encode in AviSynth with the QTGMC process I posted originally + daa3mod. Run the result through DaVinci Studio Resolve, increasing the framerate to 119.88 fps. Then, run the result of *that* encode through AviSynth again via "ChangeFPS(24000, 1001)" filter to change the frame rate back to 23.976 fps.

Then upscale in Topaz VEAI.

Sorry if I missed it, but what is the reason for Resolve ? Are you only using resolve for optical flow 23.976=>119.88 ? ChangeFPS is just dropping what you just interpolated (*5 , /5). But what is the purpose ?

If Resolve resamples all frames (does not keep the original set of frames in the interpolation), then you will get slightly different no matter where in the cycle you choose. If it keeps original frames, then it depends where in the cycle the you select (0,1,2,3,4) . You have more control over the offset with SelectEvery .

There might be some other options to get what you want, and avisynth has optical flow options if you needed it for some reason



Quote:
This is obviously rather tortured, and there's evidence. The very first frame of the video (you may need to rewind to see it) shows a distorted stardrive deflector shield on the approaching Galaxy-class ship for a single frame.
You would expected contamination and blending, if there is no built in scene detection for some types of temporal filters and optical flow.

Or you can control the application of filters to specific sections to avoid those sorts of issues

Quote:
What I like about Rubicon, specifically, is how it removes noise, has excellent smooth motion (to my eye, anyway -- I am not saying it couldn't be better), reduces flicker on the hulls of the ships (check the Galaxy-class vessel in the upper left for window flicker), and antialiases the hulls. Is there a gentler way to achieve this kind of frame rate improvement via IVTC?
Using IVTC only - will not smooth over the flicker from aliasing. But possibly IVTC + other filters you might get similar (or maybe better) results . Post the original clip and someone will give you some suggestions
poisondeathray is offline   Reply With Quote
Old 15th May 2020, 04:48   #163  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
One more note. I tested the following script from back on page 7:

Quote:
FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex", rffmode=1)
#AssumeFPS(25)
Crop(8,0,-8,0)

Clip = last

Y = nnedi3(field=-2)
A = Y.Selecteven()
B = Y.Selectodd()
C=Tfm(field=0,mode=0,cthresh=2,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=1,mode=0,cthresh=2,mthresh=2,clip2=B,micmatching=0)
Interleave(C,D)

TDecimate(mode=7, rate=24.0/1.001).AssumeFPS(24000,1001)

QTGMC2 = QTGMC(Preset="Very Slow", SourceMatch=3, InputType=2, MatchEnhance=0.75, Sharpness=0.7, MatchPreset="Very Slow", MatchPreset2="Very Slow")
QTGMC3 = QTGMC(preset="Very Slow", inputType=3, prevGlobals="Reuse")
Repair(QTGMC2, QTGMC3, 1)

E = last

F = Clip.TFM().TDecimate().MCDegrainSharp()

E.Trim(0,75)++\
F.Trim(76,2971)++\
E.Trim(2972, 0)

GradFun3()
This did not work very well, as far as reducing judder or smoothing motion -- the judder was quite poor from frame to frame. Some of the CGI scenes were flawless, others were quite badly affected. I will obviously test the other code ideas -- just wanted to report back on the first one.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 07:54   #164  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by JoelHruska View Post
2). The non-CGI sections of the show are mostly -- but not entirely -- in 23.976 fps. There are at least two places in "Sacrifice of Angels," where footage bounces up to 29.97 fps and then back to 23.976 fps in the middle of shooting a conversation between characters.
This may have been done to seamlessly alter the timing of the conversation and shorten a pause.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 15th May 2020, 08:06   #165  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
Quote:
Originally Posted by ryrynz View Post
TBH that result speaks for itself, just drop it.
Any results that you might perceive of as wonky, are that way because that's exactly the way the DVD is encoded. My method perfectly preserves field-accuracy.

Quote:
Originally Posted by JoelHruska View Post
Hey all,

Just thought I'd post here and introduce myself. I'm Joel Hruska, from ExtremeTech, and I've been working to upscale Deep Space 9.
Hi Joel! World Domination Studios here. As you can see, most people here are hell-bent on making this process much more complicated than it really is. I see that you're still using Handbrake and Staxrip instead of Smartripper, DGindex, and AVIsynth, and you're also trying to encode to exotic containers like MKV instead of the more well-supported AVI. Any particular reasons for that?

Also, we did get your email about the retrograde field behavior. We apologize for not responding to it earlier. To use the trim command to get rid of it, the script would look something like this:

Code:
mpeg2source("arbitrary ds9 episode.d2v")

A=nnedi3(field=-2).selecteven()
B=nnedi3(field=-2).selectodd()
C=Tfm(field=1,mode=0,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,clip2=B,micmatching=0)
E=Tfm(field=1,mode=0,pp=5,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,micmatching=0)
F=Tfm(field=0,mode=0,pp=5,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,micmatching=0)


X=interleave(C,D)
Y=interleave(E,F)

Trim(X,0,82)+trim(Y,83,247)+trim(X,248,0)
...where frames 0 through 82 are in a "sane" order, frames 83 through 247 are the ones with the retrograde field behavior, and then frames 248 onward are clean again ("0" means "last frame" when used as the second parameter for trim). This will produce blended frames where the retrograde field behavior used to be, but it will at least preserve all of the original fields in their original locations in the timeline. If you're willing to sacrifice some orphaned fields to kill the blending, the script would look more like this:

Code:
mpeg2source("arbitrary ds9 episode.d2v")

A=nnedi3(field=-2).selecteven()
B=nnedi3(field=-2).selectodd()
C=Tfm(field=1,mode=0,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,clip2=A,micmatching=0)
D=Tfm(field=0,mode=0,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,clip2=B,micmatching=0)

X=interleave(C,D)
Y=separatefields().doubleweave().tfm(field=1,mode=0,slow=2,cthresh=2,MI=40,blockx=8,mthresh=2,clip2=A,micmatching=0)

Trim(X,0,82)+trim(Y,83,247)+trim(X,248,0)
Just remember that your sole priority here is to deinterlace so that when you upscale the footage, you're not upscaling combed frames. Any and all other bullshit, like denoising or trying to convert to variable frame rate, is a distraction, and should be dealt with after deinterlacing - not as part of a single process that tries to do 20 different things at once and sucks at all of them.

__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.
Katie Boundary is offline   Reply With Quote
Old 15th May 2020, 08:59   #166  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by Katie Boundary View Post
you're also trying to encode to exotic containers like MKV instead of the more well-supported AVI.
You're funny.

Just in case you weren't joking and suggesting to stuff H.264 / H.265 into AVI - You appear to operate in a different reality than most of us.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 15th May 2020 at 09:43.
Groucho2004 is offline   Reply With Quote
Old 15th May 2020, 09:34   #167  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by Katie Boundary View Post
Any results that you might perceive of as wonky, are that way because that's exactly the way the DVD is encoded. My method perfectly preserves field-accuracy.
Your method failed spectacularly on the sample clip. Don't blame the DVD; you posted an untested script and falsely claimed that it worked.

JoelHruska, I really can't stress enough how little credence you should give to anything Katie Boundary says. This is not me being rude; it's simply that more often than not, they just don't know what they're talking about, often insist on using objectively worse methods for nothing other than arbitrary reasons, and simply refuse to listen to any dissenting advice.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 15th May 2020, 16:12   #168  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
So before feeding into Topaz, I do ConvertToRGB24(matrix="PC.601"), and after upscaling with Topaz I convert back with ConvertToYV12(matrix="PC.601"). Is that right?
1) Why would you want to limit yourself to 8-bit RGB color?

2) The built in functions have chroma positioning errors. Using z_ConvertFormat would be preferred.

Last edited by Stereodude; 15th May 2020 at 16:14.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 16:40   #169  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by Stereodude View Post
1) Why would you want to limit yourself to 8-bit RGB color?

2) The built in functions have chroma positioning errors. Using z_ConvertFormat would be preferred.
I'm a noob and still just learning about color spaces. It seems the original DVD footage is 8-bit (at least as reported by MediaInfo on the .M2V file), so is there any advantage to going higher?
zapp7 is offline   Reply With Quote
Old 15th May 2020, 16:51   #170  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
a colorsapce doesn't have a bit deep but a DVD is 8 bit.
if you do math with pixel you can end up with fraction so you need more bit deep to store these result accurately or you will get side effect like banding.

the "colorspace" used on DVD is usually BT 601 and what was the name SMPTE 170M there was more i can't remember EBU or something. so you have to check first what it is the sample was matrix bt 601 and primaries SMPTE 170M.
huhn is offline   Reply With Quote
Old 15th May 2020, 16:57   #171  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Quote:
Your method failed spectacularly on the sample clip. Don't blame the DVD; you posted an untested script and falsely claimed that it worked.

JoelHruska, I really can't stress enough how little credence you should give to anything Katie Boundary says. This is not me being rude; it's simply that more often than not, they just don't know what they're talking about, often insist on using objectively worse methods for nothing other than arbitrary reasons, and simply refuse to listen to any dissenting advice.
I don't know who knows what. The attitude I'm taking is that the code will either prove to work or prove not to work. Right now, I haven't found an IVTC-based approach that could be run against the entire episode to both fix the random impact of interlacing and 29.97 fps but *doesn't* really obviously create other frame timing issues, like people walking backwards in the middle of movement. I'm trying to avoid having to program frame-by-frame comparisons, though I'm going to test this approach on Sacrifice of Angels over the weekend, because that's the episode I've worked on by far the most.

I have only barely started testing IVTC, however, and the functions written by hello_hello and others are far more complex than anything I tested, so I want to look at this carefully before I start saying what will or won't work. What I want, ideally, is a function that will fix the occasional instances of interlacing and 3:2 pulldown without overly changing anything else, and I'm *really* hoping for something I can run against every DS9 episode as a global script.

Quote:
see that you're still using Handbrake and Staxrip instead of Smartripper, DGindex, and AVIsynth, and you're also trying to encode to exotic containers like MKV instead of the more well-supported AVI. Any particular reasons for that?
Tons. In fact, you should assume every single decision I've made has been made deliberately, in an attempt to solve a problem. That doesn't mean I'm solving it in the best way, but there's no part of my process that isn't deliberate.

Handbrake: Handbrake is being used because StaxRip will not properly align a MakeMKV VFR file. Handbrake is also being used because DaVinci Resolve Studio will not read MPEG-2 or MKV. Handbrake will output M4V files. M4V files are acceptable to DaVinci Studio Resolve.

StaxRip: StaxRip is being used because it offered access to the filters I wanted to run at the time, and the front-end makes it easier to launch multiple encode instances simultaneously. I do not like StaxRip very much and it is not really in active development. It has bugs. But I have not found a better front-end GUI yet. I am not wedded to StaxRip at all. I just want something that works and is relatively easy to use when launching multiple instances of the application at once.

MKV over AVI: I couldn't care less about container format, except that certain dependency chains must be fulfilled. StaxRip cannot encode a native M4V file without extracted timecodes. DaVinci Studio Resolve cannot ingest MPEG-2 or MKV. StaxRip also cannot align A/V playback when using FFVideoSource.

Last edited by JoelHruska; 15th May 2020 at 16:59.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 17:04   #172  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
I'm a noob and still just learning about color spaces. It seems the original DVD footage is 8-bit (at least as reported by MediaInfo on the .M2V file), so is there any advantage to going higher?
8-bit YUV isn't the same as 8-bit RGB. Converting back and forth between color spaces isn't a perfectly lossless operation in most cases. The color space conversion math is decimal based matrix math and doesn't map exactly to the 255 discrete steps 8-bit has. The more bits you keep through your process generally the better the final output will be. Additionally, you're upscaling the chroma in that conversion. RGB has full chroma resolution. DVD uses 4:2:0 YUV color, so the chroma resolution is 1/4 of the luma. The Luma is 720x480 and the chroma is 360x240. So you are upsampling the chroma in the step converting to RGB with a very rudimentary algorithm (compared to what Topaz uses).

I'm not familiar with Topaz and what color formats and bit depths it accepts. It may be better to feed it the 8-bit 4:2:0 YUV video directly (if it accepts it) and save the upscaled output from Topaz in >8-bit losslessly compressed video.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 17:41   #173  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by Stereodude View Post
I'm not familiar with Topaz and what color formats and bit depths it accepts. It may be better to feed it the 8-bit 4:2:0 YUV video directly (if it accepts it) and save the upscaled output from Topaz in >8-bit losslessly compressed video.
I was initially feeding it the YUV footage, however according to poisondeathray Topaz Video Enhance AI will convert to RGB and in the process it will clip the range to 16:255 instead of preserving the full range. That's why I was trying to convert to RGB first, and convert back to YUV after the upscale.

The z_ConvertFormat is a bit over my head, but based on the doc, my guess is the command I need to go from YUV -> RGB is:

Code:
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="470bg:601:470bg:full=>rgb:601:470bg:full")
After upscale, to go from RGB back to YUV with Rec.709:
Code:
z_ConvertFormat(pixel_type="YUV420PS",colorspace_op="rgb:601:470bg:full=>709:709:709:full")
I should also discuss the command I'm using to make a video out of the avs script (uses the override file workflow StereoDude helped develop). This video will then be fed to Topaz.

Code:
ffmpeg -i inputfile.avs -c:v libx264rgb -preset ultrafast -crf 0 -vf scale=-2:480,setsar=10/11 outputfile.mkv
I'm encoding instead of using the copy command because I want to set the SAR to 10:11. I read in the ffmpeg docs that -crf 0 is essentially lossless encoding. The libx264rgb is used since the format is rgb.

I'm sure I messed up a bunch and would appreciate any advice.
zapp7 is offline   Reply With Quote
Old 15th May 2020, 17:50   #174  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by JoelHruska View Post
I don't know who knows what. The attitude I'm taking is that the code will either prove to work or prove not to work. Right now, I haven't found an IVTC-based approach that could be run against the entire episode to both fix the random impact of interlacing and 29.97 fps but *doesn't* really obviously create other frame timing issues, like people walking backwards in the middle of movement. I'm trying to avoid having to program frame-by-frame comparisons, though I'm going to test this approach on Sacrifice of Angels over the weekend, because that's the episode I've worked on by far the most.

I have only barely started testing IVTC, however, and the functions written by hello_hello and others are far more complex than anything I tested, so I want to look at this carefully before I start saying what will or won't work. What I want, ideally, is a function that will fix the occasional instances of interlacing and 3:2 pulldown without overly changing anything else, and I'm *really* hoping for something I can run against every DS9 episode as a global script.



Tons. In fact, you should assume every single decision I've made has been made deliberately, in an attempt to solve a problem. That doesn't mean I'm solving it in the best way, but there's no part of my process that isn't deliberate.

Handbrake: Handbrake is being used because StaxRip will not properly align a MakeMKV VFR file. Handbrake is also being used because DaVinci Resolve Studio will not read MPEG-2 or MKV. Handbrake will output M4V files. M4V files are acceptable to DaVinci Studio Resolve.

StaxRip: StaxRip is being used because it offered access to the filters I wanted to run at the time, and the front-end makes it easier to launch multiple encode instances simultaneously. I do not like StaxRip very much and it is not really in active development. It has bugs. But I have not found a better front-end GUI yet. I am not wedded to StaxRip at all. I just want something that works and is relatively easy to use when launching multiple instances of the application at once.

MKV over AVI: I couldn't care less about container format, except that certain dependency chains must be fulfilled. StaxRip cannot encode a native M4V file without extracted timecodes. DaVinci Studio Resolve cannot ingest MPEG-2 or MKV. StaxRip also cannot align A/V playback when using FFVideoSource.
My personal opinion having played around with the first few episodes of Season 6 is that there's no compelling reason to get a VFR output. The show is for all intents and purposes is (24/1.001)fps. Just because the DVDs have p24 encoded sections with a soft pulldown applied and i60 encoded sections with a hard pulldown applied doesn't mean the output should be VFR.

There are some i60 text graphics inserted on top of it, fades in and out of black at the commercial breaks that are i60 (on top of the telecined p24), and the end credits are not 24fps. The show intro is i60 edited telecined film so you can't perfectly IVTC the intro where it fades between shots. However, no one is watching the show for the end credits or the intro (that's in every episode). You're not losing anything of importance with p24 (drop frame) output. You can blend the end credits to p24. So what if the star field behind the credits is blended? And the intro ends up with a few 5 frame segments that gets blended to p24 instead of decimated to p24. Hardly a loss. That leaves you with very few frames in an episode where an IVTC can't perfectly restore the underlying footage. The underlying footage is the concern not the titles that are faded in and out on top of it right?

I haven't found any actual i60 content (that should be turned into p60 by deinterlacing) in the show itself in the episodes I've looked at that. It's all p24 content that was edited as video (i60) after the p24 content was turned into i60 via a telecine.

The IVTC works. The problem is that the extra things done to the show when it was edited as i60 video occasionally break the IVTC pattern detection algorithms and require per episode override files if you want the best possible output to fix the few frames that it gets wrong per episode. That blows up your desire to be able to treat every episode the exact same and just run them through an entirely automated process.

You might also get marginally better output on the frames that get blended to p24 (instead of decimated to p24) if you waited to blend them until after they were upscaled by Topaz, but that further complicates the whole process.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 18:11   #175  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
I was initially feeding it the YUV footage, however according to poisondeathray Topaz Video Enhance AI will convert to RGB and in the process it will clip the range to 16:255 instead of preserving the full range. That's why I was trying to convert to RGB first, and convert back to YUV after the upscale.
I will have to go back and look at the posts closer. I only skimmed some of the earlier posts. It may or may not be a problem. Or the fix may be worse than the problem.

Quote:
The z_ConvertFormat is a bit over my head, but based on the doc, my guess is the command I need to go from YUV -> RGB is:

Code:
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="470bg:601:470bg:full=>rgb:601:470bg:full")
After upscale, to go from RGB back to YUV with Rec.709:
Code:
z_ConvertFormat(pixel_type="YUV420PS",colorspace_op="rgb:601:470bg:full=>709:709:709:full")
Not quite...

z_ConvertFormat(pixel_type="RGBPS", colorspace_op="170m:601:170m:f=>rgb:srgb:170m:f")

&

z_ConvertFormat(pixel_type="YV12", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")

Also, I suspect that Topaz may not accept RGBPS video, but it might.

Quote:
I should also discuss the command I'm using to make a video out of the avs script (uses the override file workflow StereoDude helped develop). This video will then be fed to Topaz.

Code:
ffmpeg -i inputfile.avs -c:v libx264rgb -preset ultrafast -crf 0 -vf scale=-2:480,setsar=10/11 outputfile.mkv
I'm encoding instead of using the copy command because I want to set the SAR to 10:11. I read in the ffmpeg docs that -crf 0 is essentially lossless encoding. The libx264rgb is used since the format is rgb.

I'm sure I messed up a bunch and would appreciate any advice.
I'm pretty sure this doesn't do what you think it does. You will still get a YUV encoded output.mkv file. It will not be RGB.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 18:15   #176  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
Originally Posted by zapp7 View Post
I was initially feeding it the YUV footage, however according to poisondeathray Topaz Video Enhance AI will convert to RGB and in the process it will clip the range to 16:255 instead of preserving the full range. That's why I was trying to convert to RGB first, and convert back to YUV after the upscale.

The z_ConvertFormat is a bit over my head, but based on the doc, my guess is the command I need to go from YUV -> RGB is:

Code:
z_ConvertFormat(pixel_type="RGBPS",colorspace_op="470bg:601:470bg:full=>rgb:601:470bg:full")
After upscale, to go from RGB back to YUV with Rec.709:
Code:
z_ConvertFormat(pixel_type="YUV420PS",colorspace_op="rgb:601:470bg:full=>709:709:709:full")
Yes, Enhance AI clips data if you feed it YUV. Internally it works in RGB (all neural net based algorithms work in RGB)

You can't use float formats in Upscale AI (and avisynth can't export float formats anyways) , but it will accept 16bit PNG's and can export 16bit TIFFS . You would use "RGBP16" if you wanted 16bit RGB for the RGB step, and "YV12" for 8bit 4:2:0 for the YUV 8bit 4:2:0 step

There is a negligible difference between 8bit vs. 16bit in this workflow given this source. Chroma upsampling/down for 1 generation using internal avs function vs. zlib is pretty negligible too
poisondeathray is offline   Reply With Quote
Old 15th May 2020, 18:19   #177  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,345
Quote:
Originally Posted by Stereodude View Post
My personal opinion having played around with the first few episodes of Season 6 is that there's no compelling reason to get a VFR output. The show is for all intents and purposes is (24/1.001)fps. Just because the DVDs have p24 encoded sections with a soft pulldown applied and i60 encoded sections with a hard pulldown applied doesn't mean the output should be VFR.
At least one space battle definitely has 29.97p content. Someone posted in another forum a sample. How many scenes like this ? I never got into watching DS9 compared to the other series

https://forum.videohelp.com/threads/...SC#post2578796

Some people reported "interlaced" . But is there actually any real interlaced content in this series ? By that I mean actual content with 59.94 different moments in time . Not some interlaced fade, not text overlays, or some orphan field.



My opinion #1 - Single rate anything - IVTC, deinterlace, whatever - will be jerky in sections because you have mixed content. VFR is the only way to have everything run at the correct frame rate.

My opinion #2 - One filter for everything is works good on some sections, but not so good on others. Definitely I would filter the problem aliasing sections selectively , otherwise you kill the details on 95% of the other sections. Counterproductive when upscaling. Analogy - A F1 car is great on a track, but sucks on city streets with potholes or offroading. A 4x4 is great for off roading but sucks on the track.

Last edited by poisondeathray; 15th May 2020 at 18:22.
poisondeathray is offline   Reply With Quote
Old 15th May 2020, 18:21   #178  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
Quote:
Originally Posted by Groucho2004 View Post
You're funny.

Just in case you weren't joking and suggesting to stuff H.264 / H.265 into AVI - You appear to operate in a different reality than most of us.
I never said anything about h.264 or h.265

Quote:
Originally Posted by Stereodude View Post
1) Why would you want to limit yourself to 8-bit RGB color?
Because that's already more colors than the human eye and brain can distinguish

Quote:
Originally Posted by JoelHruska View Post
I'm *really* hoping for something I can run against every DS9 episode as a global script.
Unfortunately, if the episodes do contain retrograde field behavior as you say, then there's no script that you can copy and paste 176 times, changing nothing but the episode number each time, that will deliver anything close to a perfect result. The only methods that exist to fix retrograde field behavior are very destructive and should not be used on other kinds of interlaced video. You're going to have to choose a poison here: damaging perfectly salvageable content by blending it, damaging perfectly salvageable content by discarding fields, or going through every episode frame by frame to find the RFB and using Trim to fix it. RFB is a curse straight from the pits of Hell.

Quote:
Originally Posted by JoelHruska View Post
Handbrake: Handbrake is being used because StaxRip will not properly align a MakeMKV VFR file. Handbrake is also being used because DaVinci Resolve Studio will not read MPEG-2 or MKV. Handbrake will output M4V files. M4V files are acceptable to DaVinci Studio Resolve.

StaxRip: StaxRip is being used because it offered access to the filters I wanted to run at the time, and the front-end makes it easier to launch multiple encode instances simultaneously. I do not like StaxRip very much and it is not really in active development. It has bugs. But I have not found a better front-end GUI yet. I am not wedded to StaxRip at all. I just want something that works and is relatively easy to use when launching multiple instances of the application at once.

MKV over AVI: I couldn't care less about container format, except that certain dependency chains must be fulfilled. StaxRip cannot encode a native M4V file without extracted timecodes. DaVinci Studio Resolve cannot ingest MPEG-2 or MKV. StaxRip also cannot align A/V playback when using FFVideoSource.
It sounds like the vast majority of your dependency and compatibility problems are being caused by your insistence on odd container formats like M4V, which in turn I'm assuming is the result of a perceived need to make this a VFR project.

If that's correct, then you could get rid of the vast majority of your problems by just making this a flat 59.94 FPS constant frame rate project. AVI works with everything and its only drawback that is relevant to this project is that it can't do VFR, which shouldn't even be a priority anyway.

Quote:
Originally Posted by poisondeathray View Post
My opinion #1 - Single rate anything - IVTC, deinterlace, whatever - will be jerky in sections because you have mixed content.
A pattern of frames that alternate between lasting 1/20th of a second and 1/30th of a second is NOT jerky, at least not to anyone with human eyes and a human brain.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.

Last edited by Katie Boundary; 15th May 2020 at 18:28.
Katie Boundary is offline   Reply With Quote
Old 15th May 2020, 18:26   #179  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by Stereodude View Post
I'm pretty sure this doesn't do what you think it does. You will still get a YUV encoded output.mkv file. It will not be RGB.
Even if I convert to RGB in the avs script and encode with libx264rgb? MediaInfo also reports that the outputted file has RGB color space. Is there another way to verify?

Quote:
Originally Posted by poisondeathray
There is a negligible difference between 8bit vs. 16bit in this workflow given this source. Chroma upsampling/down for 1 generation using internal avs function vs. zlib is pretty negligible too
I believe you, but I might as well use a better command if available, even if improvement is marginal.
zapp7 is offline   Reply With Quote
Old 15th May 2020, 18:28   #180  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by poisondeathray View Post
At least one space battle definitely has 29.97p content. Someone posted in another forum a sample. How many scenes like this ? I never got into watching DS9 compared to the other series

https://forum.videohelp.com/threads/...SC#post2578796

Some people reported "interlaced" . But is there actually any real interlaced content in this series ? By that I mean actual content with 59.94 different moments in time . Not some interlaced fade, not text overlays, or some orphan field.
I'm not sure what episode that's from. I didn't look at all of them. I looked at about half a dozen. I didn't find any true i60.
Stereodude is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 14:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.