Color transfer characteristics unknown (11) error - can I ignore? (Sony x3000 footage)

Hi. I’ve got a project where I’m going to be editing a video with 150+ video clips filmed on a Sony x3000.

When I drop one of the video clips on the timeline, I’m getting an error message:
“This file uses color transfer characteristics unknown (11), which may result in incorrect colors or brightness in Shotcut.”

When I look at the properties for the video clips in Shotcut I see:

Format: yuv420p
Colour space: ITU-R BT.709
Colour transfer: unknown (11)

Firstly, can anyone explain precisely what “unknown (11)” is?

Secondly, how “may” is the “may” in “which may result in incorrect colors or brigtness in Shotcut”?

I mean, is it a one in a million you may encounter problems? Or much more common than that?

Or, is it more likely to be an issue with videos shot in certain situations (e.g. low light). The video clips I’m working on are mostly outdoors in daylight, if that is of any consequence.

I’ve done a visual test. I dragged two videos onto the timeline. Played them in vlc and from the timeline in shotcut and they seem to look about the same.

And when I do an export from shotcut, the video seems to look about the same as the original video.

Clearly it’s going to be a major hassle to convert 150+ files to another format as shotcut is suggesting I do. And take up a massive amount of disk space.

So what can I do here?

Can I ignore the “unknown (11)” error and edit the videos as they are? Or am I likely to encounter problems later on down the line if I do that?

Obviously with 150+ video clips, I want to get this right from the start. So any help appreciated on how to approach this issue.

Thanks
P.S. Using Shotcut version 21.05.18

This value comes from FFmpeg’s API
AVCOL_TRC_IEC61966_2_4 = 11, ///< IEC 61966-2-4

I have never heard of it, but you can read more about it here:

Secondly, how “may” is the “may” in “which may result in incorrect colors or brigtness in Shotcut”?

The color space converter that Shotcut uses from FFmpeg is limited and does not provide tonemapping. There is a separate filter for that not integrated into Shotcut yet except through this convert dialog.

Played them in vlc and from the timeline in shotcut and they seem to look about the same.

I think it will be more reliable to convert one of the shorter clips using the Shotcut convert dialog and then compare the original and the converted in Shotcut while also using the video scopes (suggest to switch to the Color layout).

P.S. Using Shotcut version 21.05.18

Yikes, that is rather buggy version.

1 Like

Thanks for the reply.

I upgraded to the latest version of shotcut.

So I converted one 30 second clip. File size went up from 100MB to about 3GB, so that is my file size nightmare in numbers. I went for the highest conversion setting.

The conversion itself made the converted video look very dark. The original sunny day looks like an overcast day now, so way off what the original looks like.

Here are a few video scopes:

Original:

So not only did it make the file size massive, it made it look way darker than the original.

I am only allowed to add one image as I’m a newbie, but here is the converted

Converted:

When you did the conversion, did you select the option to convert to bt.709 colorspace?

image

This is selected by default when I open the advanced menu in Windows, so I guess it was selected when I did the conversion?

Okay, I did the conversion again and made sure that option was selected.

And it’s the same - very dark, overcast look in the converted file.

Thanks for double checking. I guess the tone remapping is not helpful - or the filter we use for that is not handling these transfer characteristics.

Reading the link that Dan provided some more, I see:

This allows it to travel through existing digital limited range YCC data paths, and any colors within the normal gamut will be compatible.

So it seems like the risk is that there may be some pixel values that would be outside of the legal range. If you watch the video and it looks good to you, then it should be OK.

I wonder if the camera has a setting to change the transfer characteristics that it uses.

1 Like

Yeah, that’s back to the original problem. I’d like to know what those pixel values do, how they change a video, if at all.

Otherwise, I can’t figure out what I’m gaining by doing the conversion?

For sure it’s a lot of time to do the conversion. And I get huge converted file sizes.

And I have to tweak the converted footage to make it look like the original. (With a little playing around I can get the converted file to look similar-ish to the original by adjusting the brightness and contrast.)

But all that work for what benefit?

Yes, this is how I’ve been leaning since running into the problem.

If someone has worked with this type of footage before and found that maybe things like colour grading goes wrong if you don’t work with the converted version, I’d do the conversion.

But for now it seems like a massive amount of extra work and time to convert for no benefit I can put my finger on.

Some google searching doesn’t produce many hints. I think your best path forward is to edit without conversion.

1 Like

Short story:
Color-wise, you can use your videos as they are (no conversion) with imperceptible color differences in most cases.

Longer story:
I dug out my old Sony HDR-CX110 camcorder which also produces videos with this transfer characteristic. The marketing term for xvYCC is x.v.Color, and my camera has a menu option to turn x.v.Color on or off, as seen here:

“Off” would be the recommended option, as x.v.Color by nature can produce colors that are outside the much-more-standard BT.709 color gamut by using negative CbCr values. x.v.Color looks its best only if every device in the chain understands it, including the television, which pretty much never happens. Devices that don’t understand xvYCC will most likely clip/clamp the illegal out-of-gamut colors to the nearest legal color, and the video will look like everybody else’s “boring” BT.709 footage instead of the “snazzy rich” colors offered by xvYCC (Sony marketing department talking here).

In theory, the extended colors of x.v.Color are supposed to allow for more saturated colors than BT.709 on its own. At worst, this higher saturation is what you would lose by not watching the video on an xvYCC-compatible television. Converting the video won’t gain much of anything because BT.709 itself doesn’t support those extra-saturated colors, meaning BT.709-compliant televisions can’t even display them. The only thing conversion will do is make an educated guess about the closest legal color and encode the video with all legal values instead of the video containing illegal xvYCC values (“legal” meaning within the BT.709 color gamut).

I put this to the test by using my Sony camera to record a box with highly-saturated colors on it, with x.v.Color turned on then off, then extracted a frame from each version and put them side-by-side. See the results here:

The bad news is that I can’t make a truly fair comparison unless I have a video editor and television that both understand xvYCC and support the wider gamut. The good news is that the real world must contain some extremely saturated colors before the difference between BT.709 and xvYCC becomes visible. Looking at the photo above, I can’t detect any color shift between modes, which would be the main concern in the case of your videos.

So then I took it a step further. What if I used FFmpeg to do a proper conversion into 709 gamut and compared the results again?

ffmpeg ^
-i 00000.MTS -t 00:00:01.000 ^
-filter:v bwdif,zscale=^
primariesin=709:^
matrixin=709:^
transferin=iec61966-2-4:^
rangein=limited:^
primaries=709:^
matrix=709:^
transfer=709:^
range=limited:^
filter=spline36:^
dither=error_diffusion ^
-codec:v dnxhd ^
-profile:v dnxhr_hq ^
-an ^
-y ^
00000.mov

By using zscale to respect the xvYCC transfer characteristics, I got a new video file that had effectively been “color tonemapped” into traditional BT.709 color space. Putting the xvYCC original video and this converted video side-by-side also showed imperceptible difference.

All that to say, it probably isn’t necessary to convert any of your videos in terms of color fidelity.

However, if a camera made an xvYCC file, it’s probably kinda old, and may have made an interlaced MPEG transport stream file. The filename would end with .TS or .MTS or .M2TS if it did. Those files do not seek well with FFmpeg/Shotcut, and interlaced footage is a pain in general. Hence, the FFmpeg command I wrote above was designed to deinterlace the video with bwdif and then save it in a format other than MTS. If your footage falls into this category, then conversion could have some benefits to you after all, and the “good” conversion level in Shotcut should be sufficient, which should be a manageable file size.

2 Likes

Wow! Thanks for that excellent report.

I am wondering if there is anything I should do in Shotcut to handle these files better. I think of 3 options:

  1. No change to current behavior
  2. Detect and display “IEC 61966-2-4” and do not prompt the user to convert
  3. Detect and display “IEC 61966-2-4”, prompt the user to convert, and improve the conversion process to make a better conversion (based off of Austin’s ffmpeg command line)

I am leaning toward #2 because it seems like that will produce good results with the least effort. Thoughts?

Austin - that’s a great both technical and practical answer to my question!

No option to change this in the Sony x3000. This proprietary Sony “x.v.Color” seems to be the default if you choose to film in the 1080p mp4 mode.

I guess they aren’t going to let their proprietary format die lol.

This must be what’s happening.

And as my first post mentioned, shotcut recognises this footage as “Colour space: ITU-R BT.709”. So it’s not coming up as some unrecognisable format.

The x3000 is pretty new, came out in 2017. It creates mp4 files, so don’t think there will be any of these interlacing issues.

This is the crux of it really - I can’t see any difference. They are probably cases where you can, but as yet I don’t know what they are. I’d be surprised if it was general outdoors video with normal sunlight - you’d assume that’s all within a regular color space.

Thanks again for the comprehensive answer to my question. I feel a lot more confident now editing the footage as-is without conversion.

Found this post from 2010 about xvYCC:

Shooting in xvYCC

So it seems there are subtle differences in yellow, green, cyan and violet.

This can cause those colours to “pop” more. It gives examples of a car and some flowers of these colours and you can indeed identify the “pop” factor.

So I can see why Sony insist on continuing to use this format, especially for an action camera.

Maybe if I played some of the footage I have directly off the camera onto a compatible Sony xvColor TV, some things might “pop”.

But I guess I’ll never know because I don’t have that kind of TV :grinning_face_with_smiling_eyes:

So I’m kinda thinking with this footage “what you see is what you get”. Any extra cool stuff provided by xvColor I won’t miss because I won’t ever see it.

In other words, you can’t miss what you never had.

So I’m pretty convinced now that conversion is pointless and extra work for no gain. I can just edit the footage in shotcut as-is. I presume the xyColor data will get lost in the process but that hardly matters as so few devices actually show this proprietary format.

Based on @Austin’s research and testing, I feel confident that we do not need to convert files with IEC 61966-2-4 transfer characteristics.

In the next Shotcut release, the transfer characteristics will display properly in the properties panel and the user will not be prompted to convert.

Yes, my conclusion is converting is pointless and creates extra work for no reason.

The only question is whether you want perhaps a one-off prompt to mention these types of files contain certain data (as I said above, the “extra cool stuff provided by xvColor”) that will be lost once exported from shotcut?

This topic was automatically closed after 90 days. New replies are no longer allowed.