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. |
28th September 2019, 10:23 | #961 | Link | |
Registered User
Join Date: Dec 2018
Posts: 21
|
Quote:
This is the exact kind of thing I was hoping for. @stax76 can you please please chime in regarding this, I really want to avoid redoing all my 2160p "Slow" encodes |
|
28th September 2019, 11:18 | #962 | Link | |
Registered User
Join Date: Feb 2002
Posts: 758
|
Quote:
The problem was that it converted the 10bit source to 8bit. So it did this 10bit->8bit->10bit. So it converted to 8bit and we lost a lot of information and quality. This is clear like day. I said this before take the same test file. Encode it 2 times, once with the bad old version and the second time with the new version. You will see that the encoding time of the old bad version is a lot faster. So this also proves that the old version had less information to encode. |
|
28th September 2019, 11:23 | #963 | Link |
Registered User
Join Date: Feb 2002
Posts: 758
|
Also when you encode the same file 2 times, you will see that the encode with the new Staxrip gives a smaller size. So that also proves it had less artifacts and compressed better. With the old version and conversion to 8bit, it produced artifacts and the resulted encode is a little bigger.
|
28th September 2019, 12:56 | #964 | Link | |
Registered User
Join Date: Sep 2018
Posts: 391
|
Quote:
I'm 99% sure Stax went over this once before already. It just said 8 bit to work correctly and it was actually 10 bit. Sent from my SM-G965U1 using Tapatalk |
|
28th September 2019, 13:37 | #965 | Link |
Registered User
Join Date: Dec 2018
Posts: 21
|
I have now done some test encodes with the exact same settings in 2.0.4.0 vs 2.0.2.1 vs source. What I previously thought were just "encoding artefacts" turned out to be the result of some weird conversion. The 2.0.4.0 encoded sample, when comparing frame for frame zoomed in, looks much much closer to the original source. For example I can see there's some slight red banding in the source. The banding in the newer encode looks pretty much the same. The banding in the "8bit"-version looks very different and is even shifted. So there was definitely something wonky going on.
|
28th September 2019, 13:43 | #966 | Link | |
Registered User
Join Date: Sep 2018
Posts: 391
|
Quote:
Sent from my SM-G965U1 using Tapatalk |
|
28th September 2019, 14:39 | #968 | Link |
Registered User
Join Date: Dec 2018
Posts: 21
|
The AVS script of FFMS2(?) had code in it to just assume YV12-colorspace for everything. So unless you actually edited the scripts, it didn't matter what you had configured inside your application if it used FFMS2 as a source provider (which is the auto/default setting).
|
28th September 2019, 15:07 | #970 | Link |
Registered User
Join Date: Dec 2018
Posts: 21
|
The thing is, specifying colorspace="YV12" resulted in the video being (silently) converted to 8bit. Not specifying any colorspace however, results in correctly auto-detecting the colorspace and not converted to 8bit before being piped.
In other words, specifying the correct colorspace lead to a 8bit pipeline, not specifying any colorspace lead to an actual 10bit pipeline. And StaxRip was, by default, specifying a colorspace in its AVS script. |
28th September 2019, 15:12 | #971 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Truth is I'm retired from encoding anything and as a result am by no means an expert in modern settings such as high bit depth and HDR, fortunately Revan made much improvements in this regard and I hope he will continue to do so.
StaxRip allows to use almost any setting that can be used in avs, vs, x265, nvenc etc. and it's easy to find out what settings it uses because there is everywhere a script or command line preview feature and the log file is very clean and readable. I don't think there are or was many limitations, one limitation is the drawing code used in the preview and the crop dialog, it's imitated both in performance and color accuracy. How it works is staxrip modifies the avs/vs script, this modification can be seen in the file _preview.avs/_preview.vpy, with that it uses the avifile api and System.Drawing.Bitmap, this can't obviously compete with madvr, people can use mpv for previewing, this will only work with avs because mpv don't support vpy, using mpc with madvr for preview is possible I guess but not many people have the required time and knowledge required to do it, PowerShell is needed because the script needs to be written to disc first. If somebody has interest in doing this please create a ticket and I will take care of it, it could take me some time because at the moment I spend time improving my .NET knowledge because .NET Core 3.0 and C# 8.0 was released this week and I still have some enthusiasm about dotnet, did my first tiny app ShellNew with .NET Core 3.0 and C# 8.0.
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists Last edited by stax76; 28th September 2019 at 15:20. |
28th September 2019, 15:22 | #972 | Link | ||
QfG Group Germany
Join Date: Oct 2018
Location: Germany
Posts: 245
|
I don't know, i specified always INPUT and OUTPUT in the script. I never used "Standard Settings". Example for a DNxHR YUV422 HEVC Encode:
Quote:
Quote:
You must choose the pipeline with the source string. If you encode from HEVC to HEVC you don't need the line "ConvertToYV12()", because your source is YUV420.
__________________
Last edited by -QfG-; 28th September 2019 at 15:28. |
||
28th September 2019, 15:43 | #973 | Link |
Registered User
Join Date: Jun 2002
Location: On thin ice
Posts: 6,837
|
Info() can be added in the script editor to show the colorspace and bitdepth, Info() supports font size for High DPI:
Info(size=40) I don't know what is the VapourSynth equivalent but vspipe info was added to the main menu some time ago: Main Menu > Apps > Media Info > vspipe It prints: Width: 1920 Height: 1080 Frames: 6172 FPS: 30000/1001 (29.970 fps) Format Name: YUV420P8 Color Family: YUV Alpha: No Sample Type: Integer Bits: 8 SubSampling W: 1 SubSampling H: 1
__________________
https://github.com/stax76/software-list https://www.youtube.com/@stax76/playlists |
28th September 2019, 16:11 | #974 | Link | |
Noob
Join Date: Mar 2017
Posts: 221
|
Quote:
you can not specify anything and just leave it blank to keep it same as source. works for normal sources which we use. |
|
28th September 2019, 16:45 | #976 | Link |
Registered User
Join Date: Dec 2018
Posts: 21
|
It has been doing 10bit HDR encoding, but it was being fed an 8bit input instead of the correct 10bit. You need to update to the latest StaxRip and either completely reset your settings or reset to defaults under AVS Filters -> Profiles ... just make sure it doesn't have the colorspace parameter anymore.
|
28th September 2019, 17:00 | #977 | Link | |
Registered User
Join Date: Sep 2018
Posts: 391
|
Quote:
Sent from my SM-G965U1 using Tapatalk |
|
28th September 2019, 17:23 | #979 | Link | |
Registered User
Join Date: Sep 2018
Posts: 391
|
Quote:
Sent from my SM-G965U1 using Tapatalk |
|
28th September 2019, 17:48 | #980 | Link | |
QfG Group Germany
Join Date: Oct 2018
Location: Germany
Posts: 245
|
Quote:
__________________
|
|
Tags |
aac, hdr, hevc, nvenc, staxrip, x264, x265 |
Thread Tools | Search this Thread |
Display Modes | |
|
|