Resize error 3074: unrecognized transfer characteristics

[juhok]

VS R35

import vapoursynth as vs

core = vs.get_core()

video = core.ffms2.Source(r'C0019_1.mov')

video.set_output()

=

Error on frame 0 request:
Resize error 3074: unrecognized transfer characteristics

Mediainfo
Complete name : C0019_1.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt 0000.02 (qt )
File size : 540 MiB
Duration : 48 s 0 ms
Overall bit rate mode : Variable
Overall bit rate : 94.4 Mb/s
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
Writing application : Lavf57.56.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 47 s 160 ms
Bit rate mode : Variable
Bit rate : 94.5 Mb/s
Maximum bit rate : 100.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.456
Stream size : 531 MiB (98%)
Language : English
Encoded date : UTC 1904-01-01 00:00:00
Tagged date : UTC 1904-01-01 00:00:00
Color range : Limited
Color primaries : BT.709
Transfer characteristics : IEC 61966-2-4
Matrix coefficients : BT.709

It seems this could've been fixed with SetFrameProp but I can't wrap my head around it and don't want to mess up the video with wrong parameters.

[juhok]

That's the whole script.

edit: No conversion to RGB needed.

[juhok]

VS Editor was the problem. VSPipe works without a hitch. :thanks:

[Mystery Keeper]

VS Editor was the problem. VSPipe works without a hitch. :thanks:VS Editor can encode your script just as good. It just can not preview it without some dirty tricks.

[juhok]

^ works. I needed to quickly denoise and save as prores. Because of the deadline I decided to ignore xvYCC (and hope for the best).

Here's my preset for VS Editor with ffmpeg.

-i pipe:
-c:v prores
-color_primaries bt709
-colorspace bt709
-movflags +write_colr
-threads 0
-v quiet
-y "{sn}"_denoised_prores_noaudio.mov

[dipje]

Isn't 'prores_ks' the only real supported / recommended prores encoder in recent ffmpeg builds? (with all the colorprim / colorspace stuff flags pretty much being ignored). Just asking in case I've been missing something :).

I always use '-i blablabal -vcodec prores_ks -profile:v 4444 -q:v 3 -f mov -y <outputfileblablabla>.mov'
Yes, '-vcodec' is old fashioned writing for -c:v but I can't get it out of my fingers :). And you could change profile:v to 'hq' if you want yuv422p10

[Mystery Keeper]

^ works. I needed to quickly denoise and save as prores. Because of the deadline I decided to ignore xvYCC (and hope for the best).

Here's my preset for VS Editor with ffmpeg.

-i pipe:
-c:v prores
-color_primaries bt709
-colorspace bt709
-movflags +write_colr
-threads 0
-v quiet
-y "{sn}"_denoised_prores_noaudio.mov
I personally prefer to use -nostats instead of -v quiet. Gives me useful information without flooding the log with the progress reporting.

[juhok]

Isn't 'prores_ks' the only real supported / recommended prores encoder in recent ffmpeg builds? (with all the colorprim / colorspace stuff flags pretty much being ignored). Just asking in case I've been missing something :).

I always use '-i blablabal -vcodec prores_ks -profile:v 4444 -q:v 3 -f mov -y <outputfileblablabla>.mov'
Yes, '-vcodec' is old fashioned writing for -c:v but I can't get it out of my fingers :). And you could change profile:v to 'hq' if you want yuv422p10
I can't find any recommendations from recent years for prores. Both seem to be used. Realistically our max use case is 4k 422p10. "-movflags +write_colr" seems to work for prores, but today I've been dealing with slog-2 xavc with VS and at this point I'm just going to ignore the color and force it in the editing sfotware. :)

For curiosity I encoded the same denoised clip with 'prores' and 'prores_ks' with default settings. prores_ks file is 17% bigger and about 30% slower to encode. Overlayed and zoomed in it was very difficult to even find one pixel that was different between the encodes. After subtracting the differences and boosting the levels there are some different pixels beneath the noise floor. Nothing that wouldn't be 100x destroyed when re-encoding to lossy format.

I personally prefer to use -nostats instead of -v quiet. Gives me useful information without flooding the log with the progress reporting.Thanks, this works better for this use also.

[dipje]

If you used my line the '-q:v 3' means that the encoder go more 'variable bitrate' instead of sticking to prores profiles so yeah it can become bigger. If you don't give a '-q:v 3' and you use the same profile, they should end up being the exact same size I guess.

I know why I think it was 'recommended' (wrong word to have used apparently): prores_ks supports more profiles, alpha and the 4:4:4 profiles, that's the diff apparently. The writer of prores_ks recommended to let it go VBR-style with -q:v 3 (or -q:v 4) for a speedup.

So I use it for the 4444 profile support. I know of others still using ffmbc for a certain reason (it writes the files in a format that helps them). Isn't bad, just use what works for you :P

[xekon]

Resize error 3074: no path between colorspaces

I am having a similar issue, the weird thing is, this exact same video and script works without issue on my main computer, but for some reason it wont work on my laptop, my laptop has a fresh install of everything so maybe something changed along the line at some point?

here is the source file im trying (d2v + m2v):
http://www.mediafire.com/file/9nc2etdr9i1tc9j/gradcurve.7z

here is the script:
import vapoursynth as vs
core = vs.get_core()
src = core.d2v.Source(input=r'G:/moon/enc/GradCurve/003b.d2v', rff=False)
src = core.resize.Bicubic(clip=src, format=vs.RGB48)
src.set_output()

I have tried RGBS, RGB24, RGB27, RGB30, RGB48, without success, this is not the full script, just enough to show the problem.

I need to convert to RGB so that I can test the plugin i am writing, its so odd that it works on my main pc, I think I must be doing something wrong that is causing it to not work.

fresh install of:
python-3.6.0-amd64
VapourSynth-R36
VapourSynthEditor-r14-64bit

VSedit error log:
2017-01-29 05:04:54.737
Error on frame 0 request:
Resize error 3074: no path between colorspaces

If theres anything you need me to check or report back, please let me know, I am grateful for any help I can get.
I tried uninstalling everything and installing python 3.5.3 with vapoursynth R35 thinking that might solve the problem but it did not, so i uninstalled everything again and installed the latest again.

EDIT: I copied the entire vapoursynth and vsedit folder from my main PC, and the error is gone now, but for some reason installing everything fresh from the latest available was giving me that error, unsure why.

[shader]

VS Editor can encode your script just as good. It just can not preview it without some dirty tricks.

I tried to figure out that dirty trick of my own. But I did not get any idea, what I should do. Should I add some command line arguments to VS edit or do I have to build a private version of vs edit ffmpeg?!?

Maybe somebody could give me some hint.

Thanks!!!

[Mystery Keeper]

I tried to figure out that dirty trick of my own. But I did not get any idea, what I should do. Should I add some command line arguments to VS edit or do I have to build a private version of vs edit ffmpeg?!?

Maybe somebody could give me some hint.

Thanks!!!clp = core.std.SetFrameProp(clp,prop="_Matrix",delete=True)
clp = core.std.SetFrameProp(clp,prop="_Transfer",delete=True)
clp = core.std.SetFrameProp(clp,prop="_Primaries",delete=True)

Don't use it when encoding.

[TheFluff]

Be aware though that if you do that, what you see might not be what you get. The error originates with the VS standard resizers in the zimg library (which VSEdit uses to convert frames to RGB for display), and is caused by zimg being unable to figure out the correct way to convert from whatever the input format is, given what it knows about the image. Unlike the Avisynth builtin resizers which do a naive conversion and only take color matrix (BT601, BT709 and friends) etc into account if you explicitly tell them to, VS passes the clip colorimetry metadata along with the clip and on to zimg if it is available, and if zimg doesn't support the conversion it will error out. That's what happened to the OP of this thread, who had an xvYCC extended gamut clip - zimg doesn't support xvYCC and so it refused the conversion even though the pixel data itself looked like standard YUV. MysteryKeeper's suggestion will solve the problem by simply telling zimg to do the conversion naively so you can get a preview, but that might end up looking quite weird depending on what the input is. Whether whatever encoding program you're using will handle it correctly is a different question.

[feisty2]

except primaries have nothing to do with YUV->RGB conversion, actually they stay irrelevant unless u wanna convert it to CIE
the zimg library should not even care about primaries for such conversion

[shader]

Thank you Mystery Keeper !!!

I just use VS Edit for preview.

Is it possible to read out some variable/status/property inside the script to encapsulate that part? Something similar to command line arguments automatically set by VS Edit?
I like such automatisms.

[TheFluff]

except primaries have nothing to do with YUV->RGB conversion, actually they stay irrelevant unless u wanna convert it to CIE
the zimg library should not even care about primaries for such conversion

xvYCC usually has standard BT709/601 primaries, it's the transfer function that's different.

If you want to argue zimg is doing something wrong you can do so, but you'd better come armed with citations from the standards. The issue tracker for that lib is full of maths and tl;dr.

[feisty2]

Whatever, u said it had an "extended gamut", which is the synonym for "unusual primaries", now ur switching to gamma curve, hell why do I even care, any colorspace other than CIE is garbage

[Stephen R. Savage]

Whatever, u said it had an "extended gamut", which is the synonym for "unusual primaries", now ur switching to gamma curve, hell why do I even care, any colorspace other than CIE is garbage

xvYCC is an encoding scheme intended to increase gamut (i.e. primaries), but it is actually implemented as a transfer function. The working principle is that after inverting the transfer function, the linear RGB signal will now have imaginary colors (negative/super-positive RGB) in the assumed primaries. z.lib rejects matrix operations when the transfer characteristics or color primaries are not recognized, because ITU may specify unconventional semantics for those values.

Be aware though that if you do that, what you see might not be what you get. The error originates with the VS standard resizers in the zimg library (which VSEdit uses to convert frames to RGB for display), and is caused by zimg being unable to figure out the correct way to convert from whatever the input format is, given what it knows about the image. Unlike the Avisynth builtin resizers which do a naive conversion and only take color matrix (BT601, BT709 and friends) etc into account if you explicitly tell them to, VS passes the clip colorimetry metadata along with the clip and on to zimg if it is available, and if zimg doesn't support the conversion it will error out. That's what happened to the OP of this thread, who had an xvYCC extended gamut clip - zimg doesn't support xvYCC and so it refused the conversion even though the pixel data itself looked like standard YUV. MysteryKeeper's suggestion will solve the problem by simply telling zimg to do the conversion naively so you can get a preview, but that might end up looking quite weird depending on what the input is. Whether whatever encoding program you're using will handle it correctly is a different question.
Mapping xvYCC to Rec.709 for the purposes of RGB/YUV conversion will yield the correct result. For colorspace operations, it will cause the extended gamut component to be lost in the most common configuration, because z.lib will use LUTs that lose the negative/super-positive component.

[TheFluff]

xvYCC is an encoding scheme intended to increase gamut (i.e. primaries), but it is actually implemented as a transfer function. The working principle is that after inverting the transfer function, the linear RGB signal will now have imaginary colors (negative/super-positive RGB) in the assumed primaries. z.lib rejects matrix operations when the transfer characteristics or color primaries are not recognized, because ITU may specify unconventional semantics for those values.


Mapping xvYCC to Rec.709 for the purposes of RGB/YUV conversion will yield the correct result. For colorspace operations, it will cause the extended gamut component to be lost in the most common configuration, because z.lib will use LUTs that lose the negative/super-positive component.

Good clarification, thanks.

[george84]

I have the same problem as in post #10, so I tried this dirty trick, but there is no change:

import vapoursynth as vs
from vapoursynth import core
video = core.ffms2.Source(source='PhotoDirList xml smil.mkv')
video = core.std.SetFrameProp(video,prop="_Matrix",delete=True)
video = core.std.SetFrameProp(video,prop="_Transfer",delete=True)
video = core.std.SetFrameProp(video,prop="_Primaries",delete=True)
video = core.resize.Bicubic(video, format=vs.RGBS)
video.set_output()

error is:


2017-09-16 11:00:55.651
Error on frame 0 request:
Resize error 3074: no path between colorspaces

Media Info:

General
Unique ID : 218886105148576968411312676409627252066 (0xA4ABEE30C3D2524AA6189759E0061562)
Complete name : C:\Users\Walter\Documents\SMIL\BSG23\testsuite\OLED\ColorCheck\PhotoDirList xml smil.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 5.58 MiB
Duration : 35 s 93 ms
Overall bit rate mode : Variable
Overall bit rate : 1 335 kb/s
Movie name : PhotoDirList xml smil
Encoded date : UTC 2017-09-16 08:34:41
Writing application : mkvmerge v14.0.0 ('Flow') 32bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, RefFrames : 2 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 35 s 0 ms
Bit rate mode : Variable
Bit rate : 1 206 kb/s
Maximum bit rate : 25.0 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.006
Stream size : 5.03 MiB (90%)
Writing library : x264 core 152 r2851 ba24899
Encoding settings : cabac=1 / ref=1 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=240 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=25000 / vbv_bufsize=25000 / crf_max=0.0 / nal_hrd=vbr / filler=0 / ip_ratio=1.40 / aq=1:1.00
Default : Yes
Forced : No

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 35 s 93 ms
Bit rate : 128 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 : 548 KiB (10%)
Default : Yes
Forced : No

Is there even a dirtier trick?

[george84]

You need to specify matrix_in or matrix_in_s in resize filter for YUV to RGB conversion when the _Matrix frame property isn't available.

Thank you. That works.