Log in

View Full Version : Problem with videos with variable framerate


SuperLumberjack
19th July 2021, 17:29
Hello everybody :)

I don't know if I am in the good section for my question, but I'm looking for a solution for my problem.

In fact, I recorded a video with Nvidia ShadowPlay, but I noticed that there is a variable framerate, which is a problem for editing with Sony Vegas Pro 12, because I think it only uses constant framerate and so the audio isn't synchronized with the video.

The other thing is that I want to keep a lossless quality until I compress the video with Handbrake (I just use Vegas for editing). For that I need to use the AVI format and the UT Video codec.

But there is only with VirtualDub that I can convert the video stream of my MP4 file without a loss of quality in AVI (because I can choose the same format than the source in the input and the output, so there is no conversion in RGB24 between).
But I think that the AVI format isn't compatible with the variable framerate.


In fact, idealy I would like to edit my videos keeping the variable framerate, export them in a lossless quality and compress them finally with Handbrake.

But the other important question is : what YouTube does with these videos ?
Does it convert the video with a constant framerate or does it keep a variable framerate ?

Of course, if YouTube accepts only constant framerate, I need to find the best way to convert a variable framerate to a constant framerate.

I need to admit that the biggest problem is that ShadowPlay uses a variable framerate :(
The videos are perfectly smooth, so it's too bad if we need to change the framerate mode.


What do you suggest ? Thanks for your help ! ;)

SuperLumberjack
19th July 2021, 18:20
In fact I think that I have no choice. I need to convert the framerate.

I tried with Handbrake. I chose a constant 60 fps framerate with a lossless compression.

The problem is all these steps in addition :(

And the original variable framerate video is definitely smoother. It's a strange choice from Nvidia to have chosen variable framerate :rolleyes:

I'm still open to other suggestions if you have. Thanks ! ;)

SuperLumberjack
19th July 2021, 19:15
Is there a way to convert a variable framerate to a constant with VirtualDub or AviSynth ?

SuperLumberjack
20th July 2021, 00:17
By the way, I have strange issue on my new PC, because when I open an AVS script with VirtualDub, it shows that my video is in YUV 4:2:2 instead of 4:2:0.

What is this ? :confused:

EDIT : I think it's because of that : http://avisynth.nl/index.php/AviSource

Chooses the output color format of the decompressor. Valid values are listed in the table below. This argument has no effect if the video is uncompressed, as no decompressor will be used in that case.

If omitted or "FULL", AviSynth will use the first format supported by the decompressor, in the order shown in the table below.
If "AUTO", AviSynth will use the alternate (older) order as shown.

In other words, if you don't specify anything, it will try to output YV24; if that isn't possible it tries YV16, and if that isn't possible it tries YV12, etc ...

But it's strange, I never had problems with that before and it always chose the good color format :o
I had to add :

pixel_type = "Auto"

SuperLumberjack
21st July 2021, 17:38
Hello,

Is there a way to convert Rec.601 to Rec.709 without a loss of quality please ? :o

In fact, I use ShadowPlay and the videos use a Rec.601 colormatrix instead of Rec.709.

So I have to convert it before I export the video with the UtVideo codec (lossless).

But as we can se here, there is a loss of quality :

https://i1.lensdump.com/i/ZOnd2c.png

Of course, if there is a conversion of YUV 4:2:0 to YUV 4:2:0, I understand this loss of quality.

But wouldn't be possible to change the colormatrix, without recompressing YUV to YUV ?

Thanks for your help ! ;)

kedautinh12
21st July 2021, 17:52
Try avsresize
http://avisynth.nl/index.php/Avsresize

SuperLumberjack
21st July 2021, 20:15
Thanks ! :)

But I don't understand. What do you suggest with this ?

patul
22nd July 2021, 08:16
If you open the wiki page, there's z_ConvertFormat which does scaling, colorspace conversion, and depth conversion. You could try to use it to convert Rec.601 to Rec.709

kedautinh12
22nd July 2021, 08:59
If you open the wiki page, there's z_ConvertFormat which does scaling, colorspace conversion, and depth conversion. You could try to use it to convert Rec.601 to Rec.709

I shared link above

patul
22nd July 2021, 11:20
I shared link above

Yes, I was referring to your link. :D

SuperLumberjack
22nd July 2021, 12:30
Thanks !

Yes, but why is it better than the classic conversion function ? :)
http://avisynth.nl/index.php/Convert

And how can I avoid the loss of quality when I convert Rec.601 to Rec.709 ?

I think the real problem is when a YV12 source is reconverted to YV12 one more time. Is it possible to avoid this reconversion when I come from Rec.601 to Rec.709 ?

kedautinh12
22nd July 2021, 12:51
Please read example and test
http://avisynth.nl/index.php/Avsresize

Boulder
22nd July 2021, 13:20
Somehow I think YT will convert to a constant framerate, and it probably wants some standard framerate like 60 fps.

What about loading both video and audio in the script and then using something like AssumeFPS(60) to just speed up or slow down the video. If the difference to the base framerate is small, it might be quite unnoticable.
If it's an MP4 file, better do the loading like FranceBB shows here: https://forum.doom9.org/showthread.php?p=1920368#post1920368

ChaosKing
22nd July 2021, 13:21
Are you using fast-recompress in vdub? Otherwise it could be converted first to rgb and then back to yuv by vdub.
http://www.digital-digest.com/~jmet/reencode/reencode3.png

SuperLumberjack
22nd July 2021, 16:06
Somehow I think YT will convert to a constant framerate, and it probably wants some standard framerate like 60 fps.

What about loading both video and audio in the script and then using something like AssumeFPS(60) to just speed up or slow down the video. If the difference to the base framerate is small, it might be quite unnoticable.
If it's an MP4 file, better do the loading like FranceBB shows here: https://forum.doom9.org/showthread.php?p=1920368#post1920368

Thanks ! :)

But in fact the solution with Handbrake to output with a MP4 is lossless is really quick and perfect I think ;)

But it's important to select "60 fps" or "30 fps" instead of "Same as source" for the constant framerate.

In addition, to get a CRF 0 with Handbrake, we have to set the encoder profile on "Auto". Otherwise the CRF will be 1 and so it won't be lossless.

Are you using fast-recompress in vdub? Otherwise it could be converted first to rgb and then back to yuv by vdub.
http://www.digital-digest.com/~jmet/reencode/reencode3.png

In fact, I tried several solutions.


I took this picture in RGB24 :

https://i.lensdump.com/i/ZH6vBH.md.png (https://lensdump.com/i/ZH6vBH)

I converted it with the "UtVideo YUV420 BT.601 VCM" codec (lossless) in VirtualDub :

https://i1.lensdump.com/i/ZH6Lo1.md.png (https://lensdump.com/i/ZH6Lo1)

Here is the RGB24 picture zoomed to 800% :

https://i2.lensdump.com/i/ZH6Y2c.md.png (https://lensdump.com/i/ZH6Y2c)

The Rec.601 picture :

https://i3.lensdump.com/i/ZH6oJK.md.png (https://lensdump.com/i/ZH6oJK)

For the moment everything is normal.


But it looks like after, when I convert the Rec.601 to the Rec.709 colormatrix, the loss of quality is inevitable...

Here is the Rec.601 picture to Rec.709 with the "UtVideo YUV420 BT.709 VCM" codec (lossless) directly with VirtualDub :

https://i.lensdump.com/i/ZH6ueZ.md.png (https://lensdump.com/i/ZH6ueZ)

In the reds we can instantly see that it's more blurry.

Here I converted the Rec.601 picture in RGB24 to Rec.709 with the "UtVideo YUV420 BT.709 VCM" codec :

https://i1.lensdump.com/i/ZH6DxP.md.png (https://lensdump.com/i/ZH6DxP)

Here I converted the picture in YV24 to Rec.709 with the "UtVideo YUV420 BT.709 VCM" codec :

https://i2.lensdump.com/i/ZH6PRm.md.png (https://lensdump.com/i/ZH6PRm)

And to finish, I tried to open the video with an AVS script simply with the "AviSource" function.
And then I used the "UtVideo YUV420 BT.709 VCM" codec too :

https://i3.lensdump.com/i/ZH6FFo.md.png (https://lensdump.com/i/ZH6FFo)

But it's strange, because in this case VirtualDub recognizes the "UtVideo YUV420 BT.709 VCM" codec as YV16, and not YV12 :

https://i1.lensdump.com/i/ZH6Xm2.md.png (https://lensdump.com/i/ZH6Xm2)

I think the best solutions are the 2 last ones.
But there is a shift of pixels when we convert the picture in RGB24 or YV24 before exporting it with the "UtVideo YUV420 BT.709 VCM" codec directly with VirtualDub.

What do you think ?

SuperLumberjack
22nd July 2021, 18:12
In fact, for the AVS script, I think it's a hazard if it looks good on the picture above. Maybe everything falls into place after I export the video with the "UtVideo YUV420 BT.709 VCM".

But if we change the pixel type in the AviSource function like that, we get this :

AviSource("C:FILE.avi", pixel_type = "Auto")
(Decoded in YUV 4:2:0)

https://i2.lensdump.com/i/ZHCHVC.md.png (https://lensdump.com/i/ZHCHVC)

AviSource("C:FILE.avi", pixel_type = "Full")
(Decoded in YUV 4:2:2)

https://i3.lensdump.com/i/ZHCln5.md.png (https://lensdump.com/i/ZHCln5)


As we can see, it's a mess with the pixel type set on Full (by default). And in this case I get a YV16 colorspace in the input. So I think it's wrong.


Therefore, the best option for the moment looks to be the conversion :

Rec.601 > YV24 > Rec.709

But with a shift of pixels to the left...

SuperLumberjack
22nd July 2021, 18:23
It would be more easy if we could just change the tag of the colormatrix in the end :p

Or if Nvidia didn't choose the Rec.601 instead of the Rec.709 maybe... :o

Boulder
22nd July 2021, 18:46
Perhaps a silly question but: why do you need to convert?

SuperLumberjack
22nd July 2021, 18:58
Because I use Nvidia ShadowPlay to capture my desktop or some games.

The problem is that the MP4 files are tagged with a Rec.601 colormatrix. But I need Rec.709 because sometimes I upload some videos on YouTube.

Here is for example the MediaInfo of a capture done with ShadowPlay :

General
Complete name : O:\Desktop 2021.07.21 - 00.06.50.01.mp4
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (isom/mp42)
File size : 2.32 GiB
Duration : 5 min
Overall bit rate : 66.1 Mb/s
Recorded date : 2021
Encoded date : UTC 2021-07-20 22:11:52
Tagged date : UTC 2021-07-20 22:11:52

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Format settings, GOP : M=1, N=30
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 5 min
Source duration : 5 min
Bit rate : 65.9 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 59.831 FPS
Minimum frame rate : 3.261 FPS
Maximum frame rate : 63.380 FPS
Original frame rate : 60.000 FPS
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.133
Stream size : 2.32 GiB (100%)
Source stream size : 2.32 GiB (100%)
Title : VideoHandle
Encoded date : UTC 2021-07-20 22:11:52
Tagged date : UTC 2021-07-20 22:11:52
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.601
Matrix coefficients : BT.601
mdhd_Duration : 301815

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 5 min
Source duration : 5 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Nominal bit rate : 96.0 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 spf)
Compression mode : Lossy
Stream size : 6.94 MiB (0%)
Source stream size : 6.94 MiB (0%)
Title : SoundHandle / System sounds
Encoded date : UTC 2021-07-20 22:11:52
Tagged date : UTC 2021-07-20 22:11:52
mdhd_Duration : 301695

SuperLumberjack
22nd July 2021, 20:41
In fact, I wonder if I shoudn't stay with the Rec.601. In the end I have these kind of characteristics after I encoded the video with Handbrake :

Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601

I did a test on YouTube and uploaded one of these videos. The colors were correct.

But after, I was curious to see the characteristics of the video on YouTube.

So I downloaded with 4k Video Downloader the 1080p with the AVC codec and the 2160p with the VP9 codec.

Here is the 1080p AVC :

General
Complete name : K:\Result 1080p YouTube AVC.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 942 KiB
Duration : 15 s 47 ms
Overall bit rate : 513 kb/s
Writing application : Lavf58.29.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.2
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 14 s 984 ms
Duration_FirstFrame : -17 ms
Bit rate : 374 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Variable
Frame rate : 60.067 FPS
Minimum frame rate : 60.000 FPS
Maximum frame rate : 60.080 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.003
Stream size : 685 KiB (73%)
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 15 s 47 ms
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Stream size : 235 KiB (25%)
Default : Yes
Alternate group : 1

Here is the 4k VP9 :

General
Unique ID : 179254094655322349137670286850917467233 (0x86DB1535FD6BF1EB37BECA159D310461)
Complete name : K:\Result 2160p YouTube VP9.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 2.30 MiB
Duration : 15 s 46 ms
Overall bit rate : 1 284 kb/s
Writing application : Lavf58.29.100
Writing library : Lavf58.29.100 / Lavf58.29.100
ErrorDetectionType : Per level 1

Video
ID : 1
Format : VP9
Codec ID : V_VP9
Duration : 15 s 50 ms
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Default : Yes
Forced : No
DURATION : 00:00:14,999000000

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 15 s 46 ms
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 kHz
Frame rate : 43.066 FPS (1024 spf)
Compression mode : Lossy
Default : Yes
Forced : No
DURATION : 00:00:15,046000000

As you can see, the AVC keeps the original tags and the VP9 has no tag, but the colors are correct on YouTube.

By principle, I would rather want to have Rec.709 everywhere, but if it works with Rec.601.

I don't know...

What do you think ?

ChaosKing
22nd July 2021, 20:55
For compatibility Youtube probably assumes rec709 for higher res and rec609 for lower res (like dvd).

You could try ffmpeg with copy + this parameters https://stackoverflow.com/questions/37255690/ffmpeg-format-settings-matrix-bt709
Or try mkvmerge (if mkv is ok)
https://mkvtoolnix.download/doc/mkvmerge.html
--colour-transfer-characteristics TID:n
The transfer characteristics of the video.

0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 extended colour gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1; 18: ARIB STD-B67 (HLG)

--colour-primaries TID:n
Sets the colour primaries of the video.

0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1, 22: JEDEC P22 phosphors

If youtube produces correct colors, why bother at all?

Boulder
22nd July 2021, 22:07
I was also thinking that if re-encoding is needed after editing, why not just put the "expected" properties to the encoded file and avoid any unnecessary conversions. Hence my question.

SuperLumberjack
22nd July 2021, 23:02
For compatibility Youtube probably assumes rec709 for higher res and rec609 for lower res (like dvd).

You could try ffmpeg with copy + this parameters https://stackoverflow.com/questions/37255690/ffmpeg-format-settings-matrix-bt709
Or try mkvmerge (if mkv is ok)
https://mkvtoolnix.download/doc/mkvmerge.html
--colour-transfer-characteristics TID:n
The transfer characteristics of the video.

0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: gamma 2.2 curve, 5: gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: linear, 9: log, 10: log sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 extended colour gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1; 18: ARIB STD-B67 (HLG)

--colour-primaries TID:n
Sets the colour primaries of the video.

0: reserved, 1: ITU-R BT.709, 2: unspecified, 3: reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1, 22: JEDEC P22 phosphors

If youtube produces correct colors, why bother at all?


Thanks! :)

But it's more this that I have to change I think:

--colour-matrix-coefficients TID:n

Sets the matrix coefficients of the video used to derive luma and chroma values from red, green and blue color primaries. The parameter n is an integer rangeing from 0 and 10.

Valid values and their meaning are:

0: GBR, 1: BT709, 2: unspecified, 3: reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: BT2020 non-constant luminance, 10: BT2020 constant luminance

I tried with MKVMerge, but the problem is that I don't know where to change that. I never did that in fact.

For my video-test, I have this command line:

"C:\Program Files (x86)\MKVToolNix\mkvmerge.exe" -o "G:\\Test Rec 601 to Rec 709\\Rec.709.mkv" "--default-track" "0:yes" "--forced-track" "0:no" "--display-dimensions" "0:1920x1080" "-d" "0" "--track-tags" "0" "-A" "-S" "--no-chapters" "(" "G:\\Test Rec 601 to Rec 709\\Rec.601.mkv" ")" "--track-order" "0:0"

What is the good place to add the function above and how can I do please?

And otherwise, maybe you are right, I should stay with Rec.601 ;)

But I still want to try your idea, just by curiosity :p


I was also thinking that if re-encoding is needed after editing, why not just put the "expected" properties to the encoded file and avoid any unnecessary conversions. Hence my question.


Yes, I thought the same thing, but I never knew if it's possible ;)

And in fact, I didn't expect a reconversion of the colorspace with the change of the colormatrix, it's why I simply begin with VirtualDub and lossless codecs.

SuperLumberjack
23rd July 2021, 11:01
Hi ! :)

I just wanted to test something by curiosity.

I tried to convert a clip from "YV12 lossless Rec.601" (UtVideo YUV420 BT.601 VCM) to "YV12 lossless Rec.709" (UtVideo YUV420 BT.709 VCM), but with Sony Vegas.

And to my great surprise, the result is much better than with VirtualDub ! :eek:

Here is the original Rec.601 lossless image :

https://i3.lensdump.com/i/ZH6oJK.md.png (https://lensdump.com/i/ZH6oJK)

Here is the result from VirtualDub with the Rec.601 to Rec.709 :

https://i.lensdump.com/i/ZH6ueZ.md.png (https://lensdump.com/i/ZH6ueZ)

And the result from Sony Vegas with the Rec.601 to Rec.709 :

https://i.lensdump.com/i/ZljJTv.md.png (https://lensdump.com/i/ZljJTv)

It's almost identical to the original Rec.601 with Vegas, so it's more intelligent than VirtualDub in this case :p

SuperLumberjack
23rd July 2021, 15:12
In fact, if we choose Rec.601, the colors aren't correct on YouTube with the AVC codec :

https://i3.lensdump.com/i/Zlt0To.md.png (https://lensdump.com/i/Zlt0To)

They are only correct with the VP9 codec :

https://i.lensdump.com/i/ZltIO9.md.png (https://lensdump.com/i/ZltIO9)

So the best solution is to convert the Rec.601 to Rec.709, but with Sony Vegas (and the "UtVideo YUV420 BT.709 VCM" codec), not VirtualDub !

SuperLumberjack
26th July 2021, 11:00
Hello :)

Is there a way to change the gamma of a video with AviSynth but like the "Levels" filter in VirtualDub when "Operate in luma instead of RGB" is unchecked please ?

I tried the "Levels" function with AviSynth, but the result is the same than the VirtualDub filter with "Operate in luma instead of RGB" checked.

The problem is that the result is different with "Operate in luma instead of RGB" checked/unchecked and I need the same result than this option unchecked.

I try to avoid the conversion from "YUV" to "RGB32" to "YUV" too.

Thanks ! ;)

Sharc
26th July 2021, 13:21
Hello :)

Is there a way to change the gamma of a video with AviSynth but like the "Levels" filter in VirtualDub when "Operate in luma instead of RGB" is unchecked please ?

I tried the "Levels" function with AviSynth, but the result is the same than the VirtualDub filter with "Operate in luma instead of RGB" checked.

The problem is that the result is different with "Operate in luma instead of RGB" checked/unchecked and I need the same result than this option unchecked.

I try to avoid the conversion from "YUV" to "RGB32" to "YUV" too.

Thanks ! ;)
For changing the gamma in Avisynth:

ColorYUV() when you are in YUV color space
http://avisynth.nl/index.php/ColorYUV
RGBAdjust() when you are in RGB color space
http://avisynth.nl/index.php/RGBAdjust

SuperLumberjack
26th July 2021, 14:26
Thank you very much ! ;)

But for the moment I have some troubles to understand "ColorYUV" :p

In fact I need an increase of the gamma of 50%.

So, I tried this:

ColorYUV(gamma_y=128, gamma_u=128, gamma_v=128)

But I got a purple image :D

So I just tried this :

ColorYUV(gamma_y=128)

But the blacks are grey... :confused:
Maybe it's a problem with the levels.

How can I do please ?
Thanks !



Edit: I can see with this that in fact, the value of the black moves to the right:

Histogram("levels")

So I don't think that I use the function in the right way to correct the gamma.

StainlessS
26th July 2021, 14:56
Dont use gamma on U and V, they [are implemented to] do nothing I think. [gamma is an RGB only thing really]
Problem probably down to being TV levels, starting at 16, need to use the TV->PC levels thing of ColorYUV, before use.
Then ColorYUV Gamma_y=128 [or other number].
Then ColorYUV PC->TV levels thing afterwards.
I dont have AVS access at the moment.

EDIT: ColorYUV(Levels="TV->PC") and ColorYUV(Levels="PC->TV")
EDIT: "Gamma_u/v does nothing", nobody knows how to implement it.

SuperLumberjack
26th July 2021, 14:56
In fact, this is:

ColorYUV(gamma_y=128)

Like this:

Levels(0, 1.5, 255, 0, 255, coring=false)

Sharc
26th July 2021, 15:09
Try gain_y. Or a combination of gamma_y with gain_y and off_y.

It may be easier to use Levels() or Tweak() though.

SuperLumberjack
26th July 2021, 15:12
Yes, you are right StainlessS ! :) It's better to use the gamma with RGB, so I think that I have no choice. I have to accept the conversion from YUV to RGB and use the "levels" filter of VirtualDub.


Because in fact, if I do this:


ColorYUV(levels="TV->PC")
ColorYUV(gamma_y=128)
ColorYUV(levels="PC->TV")

I have the same result than this:

Levels(0, 1.5, 255, 0, 255)

or this:

Levels(0, 1.5, 255, 0, 255, coring=true)

Or the "levels" filter of VirtualDub with gamma 1.500 with "Operate in luma instead of RGB" checked.

Thank you very much for your help! ;)

SuperLumberjack
26th July 2021, 15:16
Try gain_y. Or a combination of gamma_y with gain_y and off_y.

It may be easier to use Levels() or Tweak() though.

Thanks! ;)

I tried but the blacks moves too.


In fact, I tried to change the gamma in the Nvidia control panel too, just to test, but it's not taken into account with the capture of ShadowPlay.

With an ICC profile maybe...

But with Windows I can't choose a precise value for the gamma when I create a profile.
And even with an ICC profile, I don't think it will work, because only Fraps takes the profiles into account. It's why it's the only software to capture videos which can keep the right gamma.

In fact, I didn't explain, but it's for old OpenGL games (like "Deus Ex") and they often change the gamma or contrast of the desktop. But the video capture softwares don't record these changes of profiles.