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 > Video Encoding > MPEG-4 Encoder GUIs

Closed Thread
 
Thread Tools Search this Thread Display Modes
Old 28th September 2019, 10:23   #961  |  Link
suarsg
Registered User
 
Join Date: Dec 2018
Posts: 21
Quote:
Originally Posted by jlw_4049 View Post
Pretty sure @stax76 said the program was required to say 8 bit at some point and it really was encoding in 10 bit.
Holy sh*t, is that true?
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
suarsg is offline  
Old 28th September 2019, 11:18   #962  |  Link
Atlantis
Registered User
 
Join Date: Feb 2002
Posts: 758
Quote:
Originally Posted by jlw_4049 View Post
Pretty sure @stax76 said the program was required to say 8 bit at some point and it really was encoding in 10 bit.
It was encoding in 10bit, that was not the problem. We got 10bit encoded files.

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.
Atlantis is offline  
Old 28th September 2019, 11:23   #963  |  Link
Atlantis
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.
Atlantis is offline  
Old 28th September 2019, 12:56   #964  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 391
Quote:
Originally Posted by Atlantis View Post
It was encoding in 10bit, that was not the problem. We got 10bit encoded files.



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.
Keep in mind he updates the ffmpeg, x264, x265 versions everytime. Which could be seeing your speed benefit.

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
jlw_4049 is offline  
Old 28th September 2019, 13:37   #965  |  Link
suarsg
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.
suarsg is offline  
Old 28th September 2019, 13:43   #966  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 391
Quote:
Originally Posted by suarsg View Post
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.
@stax76 will be around eventually and he can respond to you in more depth. Staxrip has been having a 10 bit pipeline since v 2xxx

Sent from my SM-G965U1 using Tapatalk
jlw_4049 is offline  
Old 28th September 2019, 13:53   #967  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 221
high bit depth pipelining support was always there, you just had to order your encoding script correctly. i had no problem ever pipelining 16bit correctly to encoder.
Natty is offline  
Old 28th September 2019, 14:39   #968  |  Link
suarsg
Registered User
 
Join Date: Dec 2018
Posts: 21
Quote:
Originally Posted by Natty View Post
high bit depth pipelining support was always there, you just had to order your encoding script correctly. i had no problem ever pipelining 16bit correctly to encoder.
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).
suarsg is offline  
Old 28th September 2019, 14:47   #969  |  Link
-QfG-
QfG Group Germany
 
-QfG-'s Avatar
 
Join Date: Oct 2018
Location: Germany
Posts: 245
YV12 Colorspace (YUV420) is correct. But you must tunneling with a 10-Bit Pipeline. I use DGindexNV for this.
-QfG- is offline  
Old 28th September 2019, 15:07   #970  |  Link
suarsg
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.
suarsg is offline  
Old 28th September 2019, 15:12   #971  |  Link
stax76
Registered User
 
stax76's Avatar
 
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.

Last edited by stax76; 28th September 2019 at 15:20.
stax76 is offline  
Old 28th September 2019, 15:22   #972  |  Link
-QfG-
QfG Group Germany
 
-QfG-'s Avatar
 
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:
LoadPlugin("E:\VIDEOTOOLS\AVIS riPPen\StaxRip-x64-2.0.4.4-beta\Apps\Plugins\both\L-SMASH-Works\LSMASHSource.dll")
LSMASHVideoSource("D:\VIDEO\HDR\Untitled2.mov", format = "YUV422P10") <--- INPUT and activating 10-Bit Pipeline
ConvertToYV12() <--- Change Colorspace from YUV422 to YUV420.
I used this a long time and ConverttoYUV never changes the pipeline. If i use this:

Quote:
LSMASHVideoSource("D:\VIDEO\HDR\Untitled2.mov")
I have activated the 8-Bit Pipeline all the same the input file has another bitdepth.

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.
-QfG- is offline  
Old 28th September 2019, 15:43   #973  |  Link
stax76
Registered User
 
stax76's Avatar
 
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
stax76 is offline  
Old 28th September 2019, 16:11   #974  |  Link
Natty
Noob
 
Join Date: Mar 2017
Posts: 221
Quote:
Originally Posted by suarsg View Post
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.
yeah ffvideosource is also a part of your encoding script. i think everyone just ignored it and left it as default, and never bothered to see what commands are being used during encoding, read documentations, etc.

you can not specify anything and just leave it blank to keep it same as source. works for normal sources which we use.
Natty is offline  
Old 28th September 2019, 16:33   #975  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 391
So has the encoder been doing 10 bit hdr with ffvideosource this whole time or does something more need to be edited?



Sent from my SM-G965U1 using Tapatalk
jlw_4049 is offline  
Old 28th September 2019, 16:45   #976  |  Link
suarsg
Registered User
 
Join Date: Dec 2018
Posts: 21
Quote:
Originally Posted by jlw_4049 View Post
So has the encoder been doing 10 bit hdr with ffvideosource this whole time or does something more need to be edited?
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.
suarsg is offline  
Old 28th September 2019, 17:00   #977  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 391
Quote:
Originally Posted by suarsg View Post
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.
Which version changed this?

Sent from my SM-G965U1 using Tapatalk
jlw_4049 is offline  
Old 28th September 2019, 17:07   #978  |  Link
suarsg
Registered User
 
Join Date: Dec 2018
Posts: 21
Quote:
Originally Posted by jlw_4049 View Post
Which version changed this?
2.0.3 ... but the issue will still persist if you upgraded from a previous version. Hence my comment on what you need to do.
suarsg is offline  
Old 28th September 2019, 17:23   #979  |  Link
jlw_4049
Registered User
 
Join Date: Sep 2018
Posts: 391
Quote:
Originally Posted by suarsg View Post
2.0.3 ... but the issue will still persist if you upgraded from a previous version. Hence my comment on what you need to do.
Shit. Wonder how many I've encoded with older versions. I've been using 2.0.4.0 for a while now. I just do a fresh install each time but normally copy over my profile settings so I don't have to reset it all up. I never change the default script settings though.

Sent from my SM-G965U1 using Tapatalk
jlw_4049 is offline  
Old 28th September 2019, 17:48   #980  |  Link
-QfG-
QfG Group Germany
 
-QfG-'s Avatar
 
Join Date: Oct 2018
Location: Germany
Posts: 245
Quote:
FFVideoSource("%source_file%", cachefile = "%source_temp_file%.ffindex", colorspace = "YUV420P10")
Use this Source Filter for force YUV 4.2.0 10-Bit (HEVC Input) and 10-Bit pipeline.
-QfG- is offline  
Closed Thread

Tags
aac, hdr, hevc, nvenc, staxrip, x264, x265

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 03:38.


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