Color Bars not completely shown and destroyed by effects


#1

Hello Shotcut Pros and Creators. Thank you for this fine software. I am new to this specific NLE and I am just trying to find my way round so perhaps I am getting it wrong but this seems like a bug to me:

Create SMPTE Color Bars and make a clip of the desired lenght to the playlist
Add that to the Timeline - most of the time only the lower part of the Color bars are shown
[Incomplete Color Bars]
(hxxps://www.dropbox.com/s/pmyu5p4pmxgoj3p/Shotcut%20Incomplete%20Color%20Bars.JPG?dl=0)
Can only post two links so replace xx with tt to get the link to the image…
Sometimes also they are not shown at all but a still image of the following shot
Wrong Preview
If I add a keyframing blur to the color bars the effect does not work as intended - each changing of the parameters seems only to increase the blur until the clip is totally black.
Destroyed Color Bars
This seems also to destroy the clip in the playlist - I can’t readd a unmodified new version of the bars…
I can Blur keyframe real video clips fine and there the effect works as advertised…

Is it just me?

Running on Shotcut 19.04.30


#2

I managed to reproduce the malfunction of the color bars.
I read in Wikipedia that SMPTE is an NTSC pattern.
My default project is created at 1920 x 1080 25 fps.
I opened another (SMPTE color bars) dragged to playlist.
From the playlist, I dragged to timeline.
I changed the video mode to 29.97 fps and the problem disappeared.
After that, I couldn’t simulate the error again.


#3

The color bars have always been a bit problematic. If you search the forum there are a number of threads about color bar issues

Tried different video modes with different color bars. All the bars are buggy. If the RS or S&P filter is applied the bars disappear

Workaround is to open the color bar in the viewer, export 1 frame and use that.


#4

Correct, it is.
If the OP wants PAL, the EBU 100% bars should be chosen.

But I suspect this is not the problem, it’s more like what @sauron described in the previous post.

If it’s for casual work then the workaround is fine.
However for broadcast use, it’s always wise to check that the export/import process does not mess with levels and colours.
Unfortunately, SC is not able to do this and an external unit will need to be used.


#5

If on the other hand you really need to send colour bars to the broadcaster in a rush and all you have is the crew, some paint and several cardboard boxes… :joy:


#6

The only thing that’s out of tune in these color bars are the socks. :rofl:


#7

@ejmillan

They are special D65 socks, very important. :joy:

https://en.wikipedia.org/wiki/Rec._709


#8

I found D65 but all this will explode my head, hahaha.:joy:


#9

Thanks for the valued input. I am not completely dependant on ntsc colors. Pal will do fine. Mainly I was trying to understand how the software works. And to me as a newbie it didn’t seem logical what was happening - especially with the blur keyframing destroying the picture… If the behavior is intended a warning should be given by SC upon adding critical media to the timeline. But perhaps it is also only that - a bug :wink:


#10

Hello,
You make small videos in .gif format of about ten seconds for a file weight of about 300KB as in the example above.
When I export a 10sec video with Shotcut in gif format, I get a file 3 x bigger.
What settings do you use in advanced settings?


#11

The colour bars are neither NTSC nor PAL.

NTSC and PAL are two analogue methods of encoding a colour sub-carrier.


#12

Even with today’s digital video signals, it is common practice to use the same patterns as before in different parts of the world that were originally NTSC 29.97 DF or PAL 25 fps.
If you have ever lined up and calibrated a SDI reference monitor, then you should know that the choice of bars does make a big difference.

If our station had to receive any SMPTE colour bars in a feed or material, it would immediately be rejected.

If you look at the latest HD-SDI Phabrix and Tektronix test generators, arguably the bench marks world wide, you will notice a whole range of test patterns.
Each has it’s own use like pathological physical layer testing, pluge setup and so on.
09%20PM

The standard for countries that use 25 FPS (or PAL in the analogue days), is the EBU 100% Full Field Bars.


#13

Hello:
I use Share X, I don’t use any special settings.
I only do the recording with SC in window mode (1272x720 px instead of full-screen resolution (1920x1080px).
I guess the final size of the file depends on the original source(if there are many color changes or if it is more static).


#14

I am not saying that I understand the technical backgrounds fully to chime in. I am merely noticing that shotcut is aiming not only the broadcast pros but also the more amateur users. And as such the observed behaviour is not helping but intimidating. What I would “expect” from a software not only geared to pros is:

a) Each media that can be added without a warning will be adjusted upon rendering so that I will be displayed as can be expected by the preview - no matter if it makes sense in technical perspective.

b) if a) is not possible due to whichever restrictions of the media or the software a warning is issued like: " You are about to add a NTSC pattern to a PAL timeline. Adjustment of frame rate is not possible. Unexpected results in output are possible" or even only “Media format and timeline format are not compatible - unexpected results in output or filtering possible. Continue Y/N”

Like this you would know it is not a bug and at best the message would even tell you why. Perhaps thats a naive approach but I think this is more likely to convince a user that is about to decide if Shotcut is worth the time getting to know it.


#15

@mcconnor

You make some valid points, especially about the warnings.
However, where do the developers draw the line between “guiding” a new user and too many warnings which will very quickly become irritating?
It’s a tough call.

As regards the colour bar problem, I suspect it’s more about the problem/s that @sauron mentioned earlier in this thread and less to do about which pattern is technically correct for the frame rate or video system.

Shotcut will convert the frame rate of any clip to the project’s setting on export, SMPTE bars included, and in this situation, I do agree that some kind of warning would be suitable.

I also think that a potential new user to SC, or any software for that matter, should take some responsibility and research it as much as possible before settling on it.
This does mean that a certain amount of time and effort will need to be spent, or wasted on it.
It’s certainly not everyone’s cup of tea and of course it will have bugs, but at the same time, one cannot compare SC to something like Windows Movie Maker which is much easier to learn but also much more limited in almost every way.


#16

Totally with you paul2. One should spend a lot of time trying to sort out stuff on their own before bugging other people…

As to the warnings - they could be decorated with a check mark “do not show this again” which will help new users and otherwise only show up once unless there is a setting in preferences “disable all warnings”

I think SC looks and feels great as is so I am taking on the challenge to get to know it better but at same time next to this issue I had other weird stuff where I asked myself: is that me being dumb, a bug, a feature? Good to know there is a friendly and competent community to help out freshlings. Thanks.


#17

:+1:


#18

The so-called SMPTE color bars in Shotcut are out of spec anyway.

The SMPTE standard for color bars is called RP 219. Here is the spec:

[http://car.france3.mars.free.fr/HD/INA- 26 jan 06/SMPTE normes et confs/rp219 mirehd.pdf]

People don’t bother to read and understand the spec and do the math, then post rubbish on the Internet or incorporate faulty test signals into their “prosumer” programs.

If you’re posting videos of junior’s birthday party on YouTube then you needn’t bother with color bars.

But don’t cry too much if a network, syndicator or even Netflix rejects your material because the bars are out of whack. All of their scopes and test equipment are expecting bars that conform to RP 219. PBS is particularly strict about this.If your bars are non-conformant then expect your program or commercial to be bounced.

Here are the correct values in R-G-B:

Gray (leftmost bar): 180-180-180
Yellow: 180-180-16
Cyan: 16-180-180
Green: 16-180-16
Magenta: 180-16-180
Red: 180-16-16
Blue: 16-16-180
White (bottom row): 235-235-235

Here are some bmp files with the correct levels that you can import:

1280 x 720 bars

1920 x 1080 bars

As we know, BT.709 levels are in the range 16 - 235.

Here is the equation for the primaries and secondaries above. According to the RP 219 spec the bars are 75%.

0.75 * (235 - 16) + 16 =180

I’ll leave it to the developers to decide how to handle color bars in Shotcut.


#19

Your RGB values are based on limited range, but RGB in Shotcut is full range sRGB, which is then scaled down to limited range Rec. 709 YUV video (or Rec. 601 if SD). Likewise, when converting limited range YUV video to sRGB, it is scaled out to full range. As you can see, the code (in frei0r) is using 75%:


#20

I was able to reproduce this. Looks like a strange bug to me. I haven’t had a chance to look for a solution yet. @shotcut does any explanation come to mind for you? If not, I will add it to my list.