VapourSynth Script Problem

[jay123210599]

I am having the same problem from here for VapourSynth scripts. How do I make it have the same keyframes as the input video?

Here's my script, by the way.

from vapoursynth import core
clip = core.ffms2.Source(r"video.mkv")
clip = core.sub.ImageFile(clip, file = r"subtitle.sup")
clip.set_output()

[poisondeathray]

Originally Posted by jay123210599

I am having the same problem from here for VapourSynth scripts. How do I make it have the same keyframes as the input video?

Here's my script, by the way.

from vapoursynth import core
clip = core.ffms2.Source(r"video.mkv")
clip = core.sub.ImageFile(clip, file = r"subtitle.sup")
clip.set_output()

See this reply

Originally Posted by poisondeathray

When you use a script, video is decoded to uncompressed frames. The original keyframes are "gone" because video is uncompressed. Another way of saying this is now every frame is a keyframe in the script or uncompressed state. When you re-encode you can place new keyframes, or you can control where you put new keyframes. Placing keyframes is a function of the encoder, not the script

You cannot keep exactly the same keyframes because video is decoded to uncompressed with scripts, including vpy scripts

Or do you mean same position of keyframes , but re-encoded as new keyframes ? If so, you need to do that with the encoder - specifying keyframes has nothing to do with scripts because everything is uncompressed . For example, if you were using something like x264, x265 to encode - you can specify keyframe positions with a --qpfile . Use search for more information, it has been discussed in other threads

[jay123210599]

@poisondeathray For VapourSynth scripts, how do I make the script include 709 if the video has it? What would be its equivalent to AviSynth's PropSet?

One more thing, what does Y410 mean in terms of YUV?

[poisondeathray]

Originally Posted by jay123210599

@poisondeathray For VapourSynth scripts, how do I make the script include 709 if the video has it? What would be its equivalent to AviSynth's PropSet?

If source already has flags, source filters like lsmash, ffms2 should automatically read the flags and put it into the script

Otherwise you can use core.std.SetFrameProp to set or override them

http://www.vapoursynth.com/doc/funct...frameprop.html

eg.

clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=1) #mark 709
clip = core.std.SetFrameProp(clip, prop="_Transfer", intval=1) #mark 709
clip = core.std.SetFrameProp(clip, prop="_Primaries", intval=1) #mark 709

One more thing, what does Y410 mean in terms of YUV?

Y410 is the fourcc code for 10bit 4:4:4 YUV

[jay123210599]

Originally Posted by poisondeathray

Y410 is the fourcc code for 10bit 4:4:4 YUV

So it's the same thing? Where can I find more information about fourcc codes like Y410?

I also added core.std.SetFrameProp to get 709, but when I added the script to VirtualDub2, I still got YUV420 without it by default.

[poisondeathray]

Originally Posted by jay123210599

So it's the same thing? Where can I find more information about fourcc codes like Y410?

Functionally it's "10bit444", but "Y410" specifically refers to the packed representation. You can store/arrange the data in different ways. See this for more information
https://learn.microsoft.com/en-us/wi...-video-formats

Y410 Packed, 4:4:4, 10-bit.

You can dig around that microsoft page for more info, or https://fourcc.org/yuv.php

I also added core.std.SetFrameProp to get 709, but when I added the script to VirtualDub2, I still got YUV420 without it by default.

709 has nothing to do with YUV420 vs. YUV444 . Both can be either 709 or something else. They are independent variables. 420 vs. 444 refers to the chroma subsampling

How are you determining it's YUV420 ? Is it the same script as above ? Is the source 10bit444? When you open the vpy script in vdub2, what does file=>file information say under decompressor ? If it's Y410 , then it's correct. Whatever you're doing afterwards is convert it from Y410 to YUV420

[jay123210599]

Originally Posted by poisondeathray

709 has nothing to do with YUV420 vs. YUV444 . Both can be either 709 or something else. They are independent variables. 420 vs. 444 refers to the chroma subsampling

How are you determining it's YUV420 ? Is it the same script as above ? Is the source 10bit444? When you open the vpy script in vdub2, what does file=>file information say under decompressor ? If it's Y410 , then it's correct. Whatever you're doing afterwards is convert it from Y410 to YUV420

Sorry, I was using my other video, the 1080p YUV420 Blu-Ray one. This is what I got when I put my script in VirtualDub2.

https://imgur.com/TxKC0aW

[poisondeathray]

Originally Posted by jay123210599

Sorry, I was using my other video, the 1080p YUV420 Blu-Ray one. This is what I got when I put my script in VirtualDub2.

https://imgur.com/TxKC0aW

It works for me and shows Y410

In general, to debug a script you check the output of each line of the script , 1 at a time . You can comment out lines then uncomment them 1 at a time. You can use vspipe or if you prefer vdub2.

Maybe your video wasn't 10bit444 to begin with. eg. check just the source filter, comment out the sub

Maybe you mixed up videos or scripts (again). Double check before posting

from vapoursynth import core
clip = core.ffms2.Source(r"video.mkv")
#clip = core.sub.ImageFile(clip, file = r"subtitle.sup")
clip.set_output()

[jay123210599]

Originally Posted by poisondeathray

It works for me and shows Y410

In general, to debug a script you check the output of each line of the script , 1 at a time . You can comment out lines then uncomment them 1 at a time. You can use vspipe or if you prefer vdub2.

Maybe your video wasn't 10bit444 to begin with. eg. check just the source filter, comment out the sub

Maybe you mixed up videos or scripts (again). Double check before posting

from vapoursynth import core
clip = core.ffms2.Source(r"video.mkv")
#clip = core.sub.ImageFile(clip, file = r"subtitle.sup")
clip.set_output()

I told you I was using the video with this information with core.sub.ImageFile.

Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Format settings, Slice count             : 4 slices per frame
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 24 min 27 s
Bit rate mode                            : Variable
Bit rate                                 : 21.6 Mb/s
Maximum bit rate                         : 39.0 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.435
Time code of first frame                 : 00:59:59:00
Stream size                              : 3.70 GiB (85%)
Language                                 : English
Default                                  : No
Forced                                   : No
Original source medium                   : Blu-ray

I followed the script exactly and I never got the 709 part by default, even with core.std.SetFrameProp.

[poisondeathray]

Originally Posted by jay123210599

I followed the script exactly and I never got the 709 part by default, even with core.std.SetFrameProp.

vdub2 does not read props such as 709 colorimetery data in the script. Again, script frame props are the least reliable method of conveying the information

Refer your other post and the replies, especially #11
http://forum.doom9.org/showthread.php?t=185812

Originally Posted by poisondeathray

It's most reliable to add it to the encoder , at the encoding step. Works 100% of the time and what I would do

Not all software will read the prop in the script (least reliable) , and not all tools will pass or read it from the source if you adjust the metadata for the source (depends on how you use the tools)

[jay123210599]

Originally Posted by poisondeathray

vdub2 does not read props such as 709 colorimetery data in the script. Again, script frame props are the least reliable method of conveying the information

Refer your other post and the replies, especially #11
http://forum.doom9.org/showthread.php?t=185812

I tried adjusting the metadata to include 709 and it still didn't get it by default. What other tools can read the colormetery data from scripts if VirtualDub2 can't?

[poisondeathray]

Originally Posted by jay123210599

I tried adjusting the metadata to include 709 and it still didn't get it by default. What other tools can read the colormetery data from scripts if VirtualDub2 can't?

ffmpeg with avs scripts

I don't think either vpy demuxer (there are 2 versions) for ffmpeg can do it yet

[jay123210599]

Originally Posted by poisondeathray

ffmpeg with avs scripts

I don't think either vpy demuxer (there are 2 versions) for ffmpeg can do it yet

Anything else?

[_Al_]

Acknowledging or not reading "709" color flag is NOT that important, you can do things manually flagging it during encoding in your encoder, you should be in a habit to do that anyway. I wish a set that flag decades ago for SD videos every time, which I did not.

If your virtualdub is not able to set preview for BT709, and it is "hardcoded" to BT601, then do not use it for preview or perhaps even using its filters.
Encoding your vapoursynth script AND flagging "709" color space in encoding settings should be ok.
And as you were told, there is also uncertainty on a customer side, where previewing app would not read that flag or decided to use BT601 instead.

Learn to use vspipe command lines for vapoursynth scripts. That is why vspipe was created by vapoursynth author, to serve vapoursynth video or audio nodes to other apps\encoders.

[jay123210599]

Originally Posted by _Al_

Acknowledging or not reading "709" color flag is NOT that important, you can do things manually flagging it during encoding in your encoder, you should be in a habit to do that anyway. I wish a set that flag decades ago for SD videos every time, which I did not.

If your virtualdub is not able to set preview for BT709, and it is "hardcoded" to BT601, then do not use it for preview or perhaps even using its filters.
Encoding your vapoursynth script AND flagging "709" color space in encoding settings should be ok.
And as you were told, there is also uncertainty on a customer side, where previewing app would not read that flag or decided to use BT601 instead.

Learn to use vspipe command lines for vapoursynth scripts. That is why vspipe was created by vapoursynth author, to serve vapoursynth video or audio nodes to other apps\encoders.

I know how I to flag colorspace, but how do I encode my vapoursynth script?

[GeoffreyA]

Originally Posted by jay123210599

I know how I to flag colorspace, but how do I encode my vapoursynth script?

Usually, you would run the script with VSPipe, piping the output to an encoding application such as FFmpeg.

vspipe -c y4m Script.vpy - | ffmpeg -i - -c:v libx264 -crf 18 OUTPUT.mp4

[jay123210599]

Originally Posted by _Al_

Acknowledging or not reading "709" color flag is NOT that important, you can do things manually flagging it during encoding in your encoder, you should be in a habit to do that anyway. I wish a set that flag decades ago for SD videos every time, which I did not.

If your virtualdub is not able to set preview for BT709, and it is "hardcoded" to BT601, then do not use it for preview or perhaps even using its filters.
Encoding your vapoursynth script AND flagging "709" color space in encoding settings should be ok.
And as you were told, there is also uncertainty on a customer side, where previewing app would not read that flag or decided to use BT601 instead.

Learn to use vspipe command lines for vapoursynth scripts. That is why vspipe was created by vapoursynth author, to serve vapoursynth video or audio nodes to other apps\encoders.

How about this? I put my script in VirtualDub2, then I use its "Decode Format' setting to the add the 709 manually, then I use its encoding settings from "Compression" for the rest. Is that okay? Will that work?

[_Al_]

Yes, that seems to flag matrix as BT709 into AVC stream.
Or if using x264 encoder, you can add in settings, using configure button, into Extra command line:
--colormatrix bt709 --colorprim bt709 --transfer bt709
to flag color primaries and transfer also

[jay123210599]

Originally Posted by _Al_

Yes, that seems to flag matrix as BT709 into AVC stream.
Or if using x264 encoder, you can add in settings, using configure button, into Extra command line:
--colormatrix bt709 --colorprim bt709 --transfer bt709
to flag color primaries and transfer also

Oh, but do I still need to add this to my script in order for my solution to work in VirtualDub2?

clip = core.std.SetFrameProp(clip, prop="_Matrix", intval=1) #mark 709
clip = core.std.SetFrameProp(clip, prop="_Transfer", intval=1) #mark 709
clip = core.std.SetFrameProp(clip, prop="_Primaries", intval=1) #mark 709

[_Al_]

If you do what was just confirmed in VirtualDub2, then strictly no.

But it is important for a vapoursynth previewers, because they have to present video on screen, so there has to be conversion to rgb, and you need at least matrix to convert to rgb. If not provided, matrix is defaulted/guessed.
Also if not set, vapoursynth will object if changing formats to rgb within script.
It might be a good habit to set those props like that if you are sure those values are proper, even if VirtualDub2 ignores them.