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, 18:30   #181  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
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?
Maybe I misunderstood the FFMPEG help. I think you need to go to .tiff or .png to get the advantage poisondeathray is talking about.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 18:34   #182  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Just to be clear, that ffmpeg command is for the input video into Topaz. I'm saving the output from Topaz as .png images because it's lossless and the only video alternative is an antiquated H.263 encoding in mp4 format. We're all hoping they add better video options in the future.
zapp7 is offline   Reply With Quote
Old 15th May 2020, 18:41   #183  |  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.
It looks like you are conflating two different things. You don't want to feed a lossy compressed intermediate file into Topaz or take a lossy output from Topaz. You would want to take the output from the IVTC script, losslessly compress it and feed that file into Topaz (presuming Topaz can't open the .avs). If you want to go the RGB route you would convert to RGB in the script, export the .avs to .tiff or .PNG, and run those through Topaz. Output from Topaz should be lossless also.

There are pros and cons to converting to RGB. If you want to color grade the episodes after upscaling, then going to RGB probably make sense (presuming Topaz can't accept >8-bit YUV video input). Otherwise, I'd probably steer clear unless you find that Topaz handles the YUV-RGB conversion poorly.

If you are planning to color grade it later those conversion lines I pasted are not the right ones to use. They are full to full. You would want to go full to limited in the first step. You will be compressing the colors range, so you definitely don't want to map it to 8-bit RGB.

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

The step to come back is more complicated and depends on how you've color graded it (and where in the remaining steps you're going to color grade it). Which is why I haven't provided you the line because it's so highly variable on what is correct.

Quote:
Originally Posted by zapp7 View Post
Just to be clear, that ffmpeg command is for the input video into Topaz. I'm saving the output from Topaz as .png images because it's lossless and the only video alternative is an antiquated H.263 encoding in mp4 format. We're all hoping they add better video options in the future.
Understood. Even if it real RGB, it's going to be limited to 8-bits, or 10-bits. If you're trying to get fancy with RGB you'd want to use Topaz on 16-bit .png or tiff files (for the input).
Stereodude is offline   Reply With Quote
Old 15th May 2020, 18:50   #184  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by Katie Boundary View Post
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.
Maybe "judder" would have been a better term

The reason some people in this thread should not do this is duplicate frames. Some filters (many temporal, "artemis" model in upscale AI) do not work as well with hardcoded duplicates. eg. If Joel wants to clean up aliasing sections with temporal antialiasing filters, duplicates will make it less effective

Another reason is why encode ~2x more frames if you don't have to? Upscale AI isn't the fastest, even if you have a monster hardware. You end up with larger filesizes too for intermediates and final versions




Quote:
Originally Posted by zapp7 View Post
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?
It depends on what Enhance AI is using to decode.

You can check the levels before and after.


Quote:
I believe you, but I might as well use a better command if available, even if improvement is marginal.
Fair enough, the main trade off there is the filesize for the intermediates.

If you zoom in 400% - you can barely see the difference. But the other things I mentioned - you can easily see the differences, those are worthwhile
poisondeathray is offline   Reply With Quote
Old 15th May 2020, 19:08   #185  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by Katie Boundary View Post
I never said anything about h.264 or h.265
You did not, but your question to JoelHruska was:
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. Any particular reasons for that?
And from his early posts you can clearly see that his target format is either H.264 or H.265.

Also, calling MKV an exotic container is simply ridiculous.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 15th May 2020 at 20:02.
Groucho2004 is offline   Reply With Quote
Old 15th May 2020, 19:14   #186  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by Stereodude View Post
1) Why would you want to limit yourself to 8-bit RGB color?
Quote:
Originally Posted by Katie Boundary View Post
Because that's already more colors than the human eye and brain can distinguish
You must have a really crappy monitor. For example, I can clearly see differences (on my 10 bit Eizo screen) between 24 bit and 48 bit images, particularly when it comes to banding in gradients.
__________________
Groucho's Avisynth Stuff

Last edited by Groucho2004; 15th May 2020 at 20:01.
Groucho2004 is offline   Reply With Quote
Old 15th May 2020, 20:08   #187  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
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.



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.

I don't know enough to want to make absolute pronouncements, yet, but those clips that were linked are from "Paradise Lost," (Season 4, Ep 12) which means there's just all sorts of fun stuff I haven't seen. At this point, I think the only sane thing to do is to assume that DS9 has basically everything in it, somewhere. We know that most of the show is in 23.976 fps, but even if that's 90-95%+, we also know that the last 4-5% is made of lots of other things. There are interlacing artifacts baked directly into source (I believe this is "hard" telecine?).

Deep Space 9 did not have a formula where non-CGI was 23.976 and CGI was 29.97 or 60i or what have you. It seems to have been more along the lines of "Mostly 23.976, but we do what we have to, in order to make the rest work."

I'm starting to appreciate why TNG, DS9, Stargate, and Babylon 5 are all called out as tricky in the AviSynth wiki.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 20:22   #188  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Quote:
Originally Posted by Groucho2004 View Post
You did not, but your question to JoelHruska was:
And from his early posts you can clearly see that his target format is either H.264 or H.265.

Also, calling MKV an exotic container is simply ridiculous.
My target format is: "Whatever looks the best and works with the most software and lets me do what I want to do."

I am completely agnostic about this entire process, and it's a good thing I am, because the applications I'm using have proven to be far more picky than I am. I output to H.264 because it's convenient. I had intended to test H.265 because it might offer better compression. I'll break out DIVX and .mpeg files if they turned out to be the best way to remaster the show.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 20:33   #189  |  Link
Groucho2004
 
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
Quote:
Originally Posted by JoelHruska View Post
My target format is: "Whatever looks the best and works with the most software and lets me do what I want to do."
Pragmatic approach, I agree.

Quote:
Originally Posted by JoelHruska View Post
I'll break out DIVX and .mpeg files if they turned out to be the best way to remaster the show.
Neither of those are very efficient nowadays. I'd say H.264 is your best bet. For low(ish) bitrates it seems that H.265 is more efficient. Just try them both at the bitrate you're comfortable with.
__________________
Groucho's Avisynth Stuff
Groucho2004 is offline   Reply With Quote
Old 15th May 2020, 20:45   #190  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by Stereodude View Post
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")
So I converted to RGB using:
Code:
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="170m:601:170m:f=>rgb:srgb:170m:f")
Saved that as 16 bit tiffs. Ran through Topaz. Then when I convert back to YV12 using:

Code:
z_ConvertFormat(pixel_type="YV12", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")
it throws an error saying "clip must be planar", likely due to it being RGB48? How can this be tackled?

Also, since I'm saving as tiffs I'm not sure how to apply the SAR of 10:11. The result is that for 2160p, Topaz wants to produce a frame size of 3168x2160, instead of 2880x2160. What is the best point in this workflow to fix that, and how?
zapp7 is offline   Reply With Quote
Old 15th May 2020, 21:02   #191  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 2,493
Quote:
Originally Posted by Katie Boundary View Post
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.
The irony of you telling someone not to insist on doing something odd is off the charts.

Quote:
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.
It absolutely IS jerky to anyone with decent eyes.

It's not necessarily obvious - especially to someone who has grown up watching telecined video - but if you compare it to a video that's truly 24fps the difference is like night and day.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 15th May 2020, 21:14   #192  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
So I converted to RGB using:
Code:
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="170m:601:170m:f=>rgb:srgb:170m:f")
Saved that as 16 bit tiffs. Ran through Topaz. Then when I convert back to YV12 using:

Code:
z_ConvertFormat(pixel_type="YV12", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")
it throws an error saying "clip must be planar", likely due to it being RGB48? How can this be tackled?
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")

What is your plan for the final output resolution? Regardless I would generally suggest that you should not convert to 8-bit YUV here. I would suggest keeping 16-bits (as above).

Use f3kdb to convert down to 10-bits for your HEVC compression.

f3kdb(range=31, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)

Quote:
Also, since I'm saving as tiffs I'm not sure how to apply the SAR of 10:11. The result is that for 2160p, Topaz wants to produce a frame size of 3168x2160, instead of 2880x2160. What is the best point in this workflow to fix that, and how?
You can't force a particular resolution for the output of Topaz? Does it have bars on the sides, or does it fill the entire frame?

If it fills the frame you will have to squeeze it horizontally. I would probably squeeze it in the z_ConvertFormat line.

like:
z_ConvertFormat(width=2880, height=2160, resample_filter="bicubic", pixel_type="YUV420P16", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")

As to which scalar (resample_filter) you should use, I don't know. There will be lots of opinions.

Then it will have a SAR of 1:1 and you can encode it with x265 as 10-bit HEVC.

Last edited by Stereodude; 15th May 2020 at 21:25.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 22:17   #193  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by Stereodude View Post
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV420P16", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")

What is your plan for the final output resolution? Regardless I would generally suggest that you should not convert to 8-bit YUV here. I would suggest keeping 16-bits (as above).

Use f3kdb to convert down to 10-bits for your HEVC compression.

f3kdb(range=31, grainY=15, grainC=10, sample_mode=2, dither_algo=3, dynamic_grain=true, keep_tv_range=false, output_depth=10)


You can't force a particular resolution for the output of Topaz? Does it have bars on the sides, or does it fill the entire frame?

If it fills the frame you will have to squeeze it horizontally. I would probably squeeze it in the z_ConvertFormat line.

like:
z_ConvertFormat(width=2880, height=2160, resample_filter="bicubic", pixel_type="YUV420P16", colorspace_op="rgb:srgb:170m:f=>709:709:709:f")

As to which scalar (resample_filter) you should use, I don't know. There will be lots of opinions.

Then it will have a SAR of 1:1 and you can encode it with x265 as 10-bit HEVC.
Thanks! This all seems to work pretty well and I'm getting a 10 bit HEVC output now.

One other question, I'm using ImageWriter in the IVTC avs script to save the output to 16 bit png images. What's the speediest way to do this? Right now I'm just clicking play in AvsPMod and it takes a long time.
zapp7 is offline   Reply With Quote
Old 15th May 2020, 22:25   #194  |  Link
JoelHruska
Registered User
 
Join Date: May 2020
Posts: 77
Quote:
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.
Not a "perceived need" as such. A desire to explore what outcomes looked like. I went to 119.88 to resolve VFR issues because that's one method of doing it. I also have tried various approaches with QTGMC to fix judder at 23.976 fps. I took the script you posted on Page 1 and combined it with my own repair formula to create a fairly good-looking 48 fps variant (if run through MakeMKV) or 60 fps (if used on a VOB).

Which one of these did I create? All of them. The only reason I didn't showcase far more footage than I did in my last article was because I ran out of time and the article had too many clips in it already. I rendered out six different clips from Sacrifice of Angels using native DVD, a generic upscaled MKV, and then my own work at 23.976 fps output, 48 fps, 60 fps, and 119.88 fps. Then I upscaled all of them in Gaia-CG and Gaia-HQ. (Obviously the DVD didn't get upscaled).

6 clips * 6 outputs * two upscale methods = Nearly 70 videos I created for that story. Turned out to be too much, so I dumped most of it. But I did the work.

The encode methodology I call "Rubicon" is not a 119.88 fps file. It's a 23.976 fps file that was temporarily pushed to 119.88 fps by DaVinci before being decimated back to 23.976 fps by AviSynth using ChangeFPS(24000,1001).

I'm not wedded to VFR. I'm wedded to nuking judder, preferably in a method I can apply across an entire episode at once. All of the container choices I have made have been attempts to work around problems I was having, not some attempt to use a particular file format or codec that I'm in love with.

Last edited by JoelHruska; 15th May 2020 at 22:30.
JoelHruska is offline   Reply With Quote
Old 15th May 2020, 22:26   #195  |  Link
Stereodude
Registered User
 
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
Quote:
Originally Posted by zapp7 View Post
Thanks! This all seems to work pretty well and I'm getting a 10 bit HEVC output now.

One other question, I'm using ImageWriter in the IVTC avs script to save the output to 16 bit png images. What's the speediest way to do this? Right now I'm just clicking play in AvsPMod and it takes a long time.
Well, you can use AVSmeter to process the .avs as fast as possible vs. playing it real time presuming that's limiting factor.

I think you can also use ffmpeg to turn a .avs into a series of images but I've never done it and am not sure of the command syntax.
Stereodude is offline   Reply With Quote
Old 15th May 2020, 22:39   #196  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by zapp7 View Post

One other question, I'm using ImageWriter in the IVTC avs script to save the output to 16 bit png images. What's the speediest way to do this? Right now I'm just clicking play in AvsPMod and it takes a long time.

Probably
Code:
avsr64 script.avs
But it's slow, probably not much faster.

How are you loading the 16bit TIFF's ? If using ImageSource, don't forget pixel_type="RGB48", or they will load as 8bit
poisondeathray is offline   Reply With Quote
Old 15th May 2020, 22:59   #197  |  Link
zapp7
Registered User
 
Join Date: May 2020
Location: Canada
Posts: 49
Quote:
Originally Posted by poisondeathray View Post
How are you loading the 16bit TIFF's ? If using ImageSource, don't forget pixel_type="RGB48", or they will load as 8bit
Good catch! I've added that.

Seems like avsr64 is similar speed to AVSmeter, however I can run multiple instances of avsr64 and run several episodes in parallel!
zapp7 is offline   Reply With Quote
Old 16th May 2020, 03:37   #198  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
Quote:
Originally Posted by poisondeathray View Post
Maybe "judder" would have been a better term

The reason some people in this thread should not do this is duplicate frames. Some filters (many temporal, "artemis" model in upscale AI) do not work as well with hardcoded duplicates. eg. If Joel wants to clean up aliasing sections with temporal antialiasing filters, duplicates will make it less effective
An interesting point, but the only frames that should require temporal filtering are the ones derived from orphaned fields to begin with.

Quote:
Originally Posted by poisondeathray View Post
Another reason is why encode ~2x more frames if you don't have to? Upscale AI isn't the fastest, even if you have a monster hardware. You end up with larger filesizes too for intermediates and final versions
That's actually a very good point. I'm not sure it justifies complicating the workflow to the edge of unusability, but rescaling the same frame 3x does seem like a huge waste of CPU cycles.

Quote:
Originally Posted by Groucho2004 View Post
Also, calling MKV an exotic container is simply ridiculous.
It's not an industry standard like MP4 is, and it's not compatible with most video editing programs like AVI is. It's as exotic as a format can get without being some proprietary bullshit that you'd never see outside a digital camera.

Quote:
Originally Posted by JoelHruska View Post
My target format is: "Whatever looks the best and works with the most software and lets me do what I want to do."
Well container format doesn't really have anything to do with how good the video looks. For working with the most software, AVI is pretty much the format that every program can import and every program can export. MPEG can be correctly interpreted by a very slightly broader range of hardware and software, but AVI can be exported by a vastly broader range of programs, like Premiere and Virtualdub; if you want to create a .mpg file, you'd have to create an AVI file or AVIsynth script or something and then load it into Tsunami MPEG Encoder, also known as TmpegEnc, to convert it to .mpg.

Quote:
Originally Posted by JoelHruska View Post
I'm not wedded to VFR. I'm wedded to nuking judder
That is unfortunate, because your approach of decimating an entire episode down to 23.976 FPS will create problems in 30 FPS or 60 FPS sections that are much worse than judder. Many years ago, I attempted to apply standard IVTC to an episode of War Planets, and noticed an odd skipping effect, as if decimate() was decimating the wrong frames. Looking at the source stream more closely, I discovered that the episodes were originally rendered at 25 frames per second, not 24, and were converted to NTSC by duplicating every fifth frame, not every fourth. I was decimating one frame per second too many, and it was already noticeable. Cutting 30 FPS content down to 24 fps kills 6 frames per second too many.

Judder in the 24 fps parts is the lesser of those two evils... by far.

If you think VFR is the lesser of all three evils, I won't try to dissuade you from that opinion, but conversion to VFR should be done as a separate step, after you've ripped, indexed, and deinterlaced in CFR. Worrying about judder when you're trying to deinterlace, or even just trying to get video from a VOB file into an AVS script, is like trying to decide what color your next Ferrari should be when your house is on fire.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.

Last edited by Katie Boundary; 16th May 2020 at 04:44.
Katie Boundary is offline   Reply With Quote
Old 16th May 2020, 03:59   #199  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 5,346
Quote:
Originally Posted by Katie Boundary View Post
An interesting point, but the only frames that should require temporal filtering are the ones derived from orphaned fields to begin with.
"should" is not the same thing as reality.

The sad fact is this series has some garbage sections full with aliasing .

And I noticed some people were using some temporal filtering on "normal" sections as well

Whatever their reasons are, unique frames are going to be more conducive for their goals

Quote:
Originally Posted by Katie Boundary View Post
That's actually a very good point. I'm not sure it justifies complicating the workflow to the edge of unusability, but rescaling the same frame 3x does seem like a huge waste of CPU cycles.
It's not for me; but for those people doing it, upscaling "x" amount AND having "y" times more frames is going to be worse on the CPU and GPU for both encoding and decoding
poisondeathray is offline   Reply With Quote
Old 16th May 2020, 04:48   #200  |  Link
Katie Boundary
Registered User
 
Katie Boundary's Avatar
 
Join Date: Jan 2015
Posts: 1,048
All right, PDR, you've made your case. Nonetheless, getting the video from the VOB file to the AVS script and then deinterlacing it can be more easily done in CFR. There's no benefit to bothering with VFR during those steps. Once that's done, it can be converted to VFR, and then temporal cleanup can be applied.
__________________
I ask unusual questions but always give proper thanks to those who give correct and useful answers.

Last edited by Katie Boundary; 23rd May 2020 at 00:10.
Katie Boundary 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 00:11.


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