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. |
15th May 2020, 18:34 | #182 | Link |
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.
|
15th May 2020, 18:41 | #183 | Link | ||
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
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:
|
||
15th May 2020, 18:50 | #184 | Link | |||
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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:
You can check the levels before and after. Quote:
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 |
|||
15th May 2020, 19:08 | #185 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
You did not, but your question to JoelHruska was:
Quote:
Also, calling MKV an exotic container is simply ridiculous.
__________________
Groucho's Avisynth Stuff Last edited by Groucho2004; 15th May 2020 at 20:02. |
|
15th May 2020, 19:14 | #186 | Link |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
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. |
15th May 2020, 20:08 | #187 | Link | |
Registered User
Join Date: May 2020
Posts: 77
|
Quote:
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. |
|
15th May 2020, 20:22 | #188 | Link | |
Registered User
Join Date: May 2020
Posts: 77
|
Quote:
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. |
|
15th May 2020, 20:33 | #189 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
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 |
|
15th May 2020, 20:45 | #190 | Link | |
Registered User
Join Date: May 2020
Location: Canada
Posts: 49
|
Quote:
Code:
z_ConvertFormat(pixel_type="RGBP16", colorspace_op="170m:601:170m:f=>rgb:srgb:170m:f") Code:
z_ConvertFormat(pixel_type="YV12", colorspace_op="rgb:srgb:170m:f=>709:709:709:f") 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? |
|
15th May 2020, 21:02 | #191 | Link | ||
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,496
|
Quote:
Quote:
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. |
||
15th May 2020, 21:14 | #192 | Link | ||
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
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:
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. |
||
15th May 2020, 22:17 | #193 | Link | |
Registered User
Join Date: May 2020
Location: Canada
Posts: 49
|
Quote:
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. |
|
15th May 2020, 22:25 | #194 | Link | |
Registered User
Join Date: May 2020
Posts: 77
|
Quote:
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. |
|
15th May 2020, 22:26 | #195 | Link | |
Registered User
Join Date: Dec 2002
Location: Region 0
Posts: 1,436
|
Quote:
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. |
|
15th May 2020, 22:39 | #196 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
Probably Code:
avsr64 script.avs How are you loading the 16bit TIFF's ? If using ImageSource, don't forget pixel_type="RGB48", or they will load as 8bit |
|
15th May 2020, 22:59 | #197 | Link | |
Registered User
Join Date: May 2020
Location: Canada
Posts: 49
|
Quote:
Seems like avsr64 is similar speed to AVSmeter, however I can run multiple instances of avsr64 and run several episodes in parallel! |
|
16th May 2020, 03:37 | #198 | Link | |||
Registered User
Join Date: Jan 2015
Posts: 1,056
|
Quote:
Quote:
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:
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. |
|||
16th May 2020, 03:59 | #199 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,377
|
Quote:
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 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 |
|
16th May 2020, 04:48 | #200 | Link |
Registered User
Join Date: Jan 2015
Posts: 1,056
|
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. |
Thread Tools | Search this Thread |
Display Modes | |
|
|