Broadcast safe levels

Do you have questions about Desktop Video, Converters, Routers and Monitoring?
  • Author
  • Message
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 11:50 am

File which you say is bad after AME.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 11:55 am

I am not sure if I am allowed to share a link here, this is the original WITHOUT FILTER:
https://wetransfer.com/downloads/c9bdaa ... 317/8368ff
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:01 pm

...and here are THREE Files, filtered with AME Limiter, FCPX Broadcast Safe and Avid Safe Color.
https://we.tl/t-I5LCO5Tz5W
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:05 pm

Your sample fails on ZDF Vidchecker test.
Fails still after 105% AME preset.
Fails on luma/chroma and passes gamut on 103% preset.
Passes after 100% preset.

ZDF uses Luma/Chroma tolerances: -1% and +3%.
105% preset passes gamut test with 6% threshold instead of 5%, so it's on the edge.
Last edited by Andrew Kolakowski on Thu Nov 24, 2022 12:09 pm, edited 1 time in total.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:09 pm

Do you mean the first sample WITHOUT filter or do you mean one of the three samples WITH filter?
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:10 pm

First bad source. I limit myself in AME.
AME seems to be quite mild and doesn't go slightly above thresholds, so 105% preset may still fail after compression overshoots are added.
If your source is graded properly without extremes all should be fine every time after 103% preset.

It's this low luma 1% threshold which cause most issues here (but YUV levels are easy to handle before final export).
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:15 pm

Andrew Kolakowski wrote:First bad source. I limit myself in AME.
AME seems to be quite mild and doesn't go slightly above thresholds, so 105% preset may still fail after compression overshoots are added.
If your source is graded properly without extremes all should be fine every time after 103% preset.

It's this low luma 1% threshold which cause most issues here.


Thanks a lot, for some strange reason, FCPXs RGB parade always shows me negative values in the blue channel when I reimport my already limited files. No matter if its AME, AVID or FCPXs own broadcast filter..
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:21 pm

Andrew Kolakowski wrote:PSE is about purely UK thing. I think only Japan requires it as well. Not sure who else.


No it's not. https://partnerhub.warnermediagroup.com/specifications-and-guides/originals/originals-sdr for,example.

I don't know why this is being made so complicated. If you set your software limiter properly and with due reference to the waveform scope, RGB fails should be the least of your problems. It's very very rare for such fails via Vidchecker, normally I see here. You have a huge amount of fails in the check from Andrew, Peter - this shouldn't be the case. I would advise you to use Avid at least to follow a standard procedure. I know of no other pure NLE that is used for finishing.
Last edited by Steve Fishwick on Thu Nov 24, 2022 12:22 pm, edited 1 time in total.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:21 pm

and this is what QCTools tells me for all of the files for BRNGAV - first is without filter. AME has the stronges spikes - even with the very conservative 100-setting, but they all seem quite low. I guess I will apply a "broadcast safe" effect in FCPX set to 1 and then convert in AME with this 100 setting to be sure.
Attachments
Screenshot 2022-11-24 at 13.19.41.png
Screenshot 2022-11-24 at 13.19.41.png (33.67 KiB) Viewed 1581 times
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:26 pm

Told you many times- forget about 100% perfect signals or you will go mad. Scopes are rather "sensitive" as 1 pixel with slightly off value is enough to be visible ( I assume).
Unless you work with DPX, EXR, etc. you will never get perfect signals.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:35 pm

Andrew Kolakowski wrote:First bad source. I limit myself in AME.
AME seems to be quite mild and doesn't go slightly above thresholds, so 105% preset may still fail after compression overshoots are added.
If your source is graded properly without extremes all should be fine every time after 103% preset.

It's this low luma 1% threshold which cause most issues here (but YUV levels are easy to handle before final export).


Thanks a lot again for all your effort!!! :)
Thats a great help to have some peace of mind.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:44 pm

There is one more thing in R103. Signal goes over low pass filter before testing values, so this again removes some overshoots and gives different results than scopes itself.

For PSE legalisation (if you need it 1 time a year) you can use https://hardingtest.com.
Most European broadcasters don't need PSE compliancy though. Also don't trust anyone who says it can fix it automatically (like Vidchecker for example). Results are far from usable.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:47 pm

Peter, it might be useful for you to know too, that what happens when you have a fail in QC, is you are normally required to correct it and deliver only a 'patch', i.e. the error plus 1 or 2 shots either side. These are then dropped into the final delivery file. There is no need to output the whole show again.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostThu Nov 24, 2022 12:53 pm

Andrew Kolakowski wrote:For PSE legalisation (if you need it 1 time a year) you can use https://hardingtest.com.
Most European broadcasters don't need PSE compliancy though. Also don't trust anyone who says it can fix it automatically (like Vidchecker for example). Results are far from usable.


It is by far the most common and biggest fail in QC and is required every time, especially when editors love their flashy FX. We don't just deliver for the UK either. It is integral to Vidchecker in any case and Videchecker fixes nothing. There is no automatic fix I know of. Usually a BCC vignette will fix about 90% of them but there are stationery fails for PSE too, such as a multi-paned window or many parallel boxes.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 1:13 pm

It's either in broadcaster spec or not and in Europe it's about nowhere required.
ZDF for example doesn't check for it. If they have some other guidance (not mandated by PSE test report) for flashing then this is a different story.

You turn it on or off (like any other check) in Vidchecker- nothing is mandated or forced.
Vidchecker offers auto PSE fix (which uses patented algorithms). They use to be so proud of it, but its results are far from perfect.

Whole PSE thing is problematic because experiments on which Harding established it are now forbidden. Only Harding tools were allowed for testing for long time, but later more tools were qualified and they did not have to operate on Harding algorithm anymore. Vidchecker doesn't use Harding SDK, but its own implementation.
PSE issues are annoying as it's not as simple as "fix flashing". Patterns are specific and something which you think is going to be a problem passes without issue and then others (which look nothing big) fail.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 1:39 pm

Steve Fishwick wrote:Peter, it might be useful for you to know too, that what happens when you have a fail in QC, is you are normally required to correct it and deliver only a 'patch', i.e. the error plus 1 or 2 shots either side. These are then dropped into the final delivery file. There is no need to output the whole show again.

Thats good to know, I heard that some stations let you pay for their time and a second QC - or let you pay to fix this locally. I wouldnt worry if I just had to render out and upload the film again.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 1:41 pm

..and still I would love to have access to Vidchecker cloud qualify.. But still no answer. On the website it says "limited availability".
Attachments
Screenshot 2022-11-24 at 14.40.10.png
Screenshot 2022-11-24 at 14.40.10.png (33.47 KiB) Viewed 1547 times
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostThu Nov 24, 2022 1:56 pm

Have you tried this link to create TS cloud account:
https://cloud.telestream.net/console/signup

I see other services, but no Qualify. I think I use to be able to use it. Maybe it's gone.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostThu Nov 24, 2022 2:18 pm

Andrew Kolakowski wrote:PSE issues are annoying as it's not as simple as "fix flashing". Patterns are specific and something which you think is going to be a problem passes without issue and then others (which look nothing big) fail.


Thanks Andrew, I never knew that :lol:
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostThu Nov 24, 2022 2:46 pm

Andrew Kolakowski wrote:Have you tried this link to create TS cloud account:
https://cloud.telestream.net/console/signup

I see other services, but no Qualify. I think I use to be able to use it. Maybe it's gone.

Yes I registered and have only services like transcription. I will wait, maybe they can offer me a slot to try it out.
Online
User avatar

Marc Wielage

  • Posts: 9024
  • Joined: Fri Oct 18, 2013 2:46 am
  • Location: Hollywood, USA

Re: Broadcast safe levels

PostFri Nov 25, 2022 5:16 am

Steve Fishwick wrote:It is by far the most common and biggest fail in QC and is required every time, especially when editors love their flashy FX. We don't just deliver for the UK either. It is integral to Vidchecker in any case and Videchecker fixes nothing. There is no automatic fix I know of. Usually a BCC vignette will fix about 90% of them but there are stationery fails for PSE too, such as a multi-paned window or many parallel boxes.

In cases where we've had films with lots of explosions and/or flashing lights that triggered a potential PSE (Photosensitive Epilepsy situation), generally the director stood firm and refused to allow it to be edited or changed. They generally ran the film with a disclaimer that said something like:

Image

When you think about it, every major action film of the last 25 years has had sequences (usually short ones) with flashing lights ad/or explosions. I'm reminded of the famous "flashing red light" sequence in the classic sci-film The Andromeda Strain, where a character in the film literally goes into epileptic shock when warning lights go off, which becomes a major plot detail.

If it's a luma or chroma excursion, we just go in and fix it -- it's going to happen, but hopefully not too often. After too many years of broadcast experience, I generally try to keep white titles down to maybe 95-96 ire, but it's not really relevant in 2022.
marc wielage, csi • VP/color & workflow • chroma | hollywood
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostFri Nov 25, 2022 9:58 am

Marc Wielage wrote:They generally ran the film with a disclaimer that said something like:


I think that's the most sensible approach, I wish it were so - a lot of good creative editing gets watered down sometimes IMV. Unfortunately the UK system is largely a public broadcasting one, not a commercial environment, therefore the strictures are defined legally and ultimately by government. It's the same with language and adult themes. We have a 'watershed' which is from 9pm. Disclaimers are not enough for terrestrial broadcasting here.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostSat Nov 26, 2022 9:45 am

Warning, stupid question coming once again:
After reading this, I am not sure, what the RGB-Parade actually represents.
viewtopic.php?f=21&t=56381&p=902666#p902666
Does it represent the "real" RGB values with 16 at the 0-axis or does it represent just the perceived color brightness? If its the latter than values which are less than 0 shouldnt be an issue at all.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSat Nov 26, 2022 7:06 pm

AVID (FCP, Edius not sure about Premiere) seems to use YUV internal processing, so this is very different. You easier get out of gamut or negative values. Also- looks like scopes there shift scale below 0, where in Resolve it's always 0-100% and if any data is there then it's 'hidden' (you can use Offset or Curves to see if any data is outside 0-100).
I would still expect scale to be 0-1023, not 16 at axis 0 (that would be more confusing?).
Resolve is RGB + "fake" Y channel. Not sure if people do really use this Y info.
In Resolve typically everything is full range, so forget about 16/64 on Resolve scopes. Black in Resolve is 0 and white 1023. It's during export where Resolve converts data properly to YUV according to settings/codec requirements.
When you import YUV based file to Resolve is does opposite- normalises everything to RGB, so accurate info in file about YUV data range (one tools always assume limited- which is far from ideal) is required. Some codecs store range inside codec, others don't. Range info can be also stored in container as well, but things like ProRes MOV don't have range info (neither on codec nor container level) and this is why exporting full range ProRes is "risky". ProRes by definition should be limited range. It can be full, but then you have to tell your tool that it's full range (in Resolve you overwrite in clip attributes, but in Premiere no way to change it from hard coded rules!). This is very important. DNxHR has range flag inside codec metadata. You just need tools which set/read it properly. Resolve (after few fixes) now seems to do it accurately.

Resolve is not really a typical NLE as it's coming from grading. Everything imported is converted to RGB internally, unless you do direct exports without any touches (this is for speed and to preserve YUV when possible). RGB processing is typical for high-end finishing/grading tools as then it makes more sens.

Imagine this case.
Source - v210 (YUV 422 10bit) going back to v210 after lets say simple edge crop.

If tool operates in YUV then this will be done on YUV and be fairly fast. It won't involve YUV->RGB->YUV conversion either, which is desired behaviour.
In case of Resolve you will get YUV->RGB on import, processed on RGB and then converted back to YUV for export. In this case Resolve is actually "worse". It's not that important, but it can alter original YUV data, so there is some argument here.
In old Resolve (somewhere <v16) conversion to RGB use to happen always, regardless if it was needed or not. Currently if you do no processing (just eg. edit) Resolve during export will pass YUV data to export module (unless export codec is RGB), so this way it will avoid pointless YUV->RGB->YUV conversion.
Old Resolve had poor YUV->RGB->YUV conversion, so after exporting v210 back to v210 few times you were getting totally messed-up file (even if you were exporting uncompressed format!). You can find old post about it. Current version is better and also YUV->RGB->YUV is improved as well.

Things look differently when you work with RAW (which is not RGB nor YUV, but becomes RGB after debayering) or high quality source (DPX, EXR etc.) as then Resolve RGB processing is desired. You do all operations in RGB (with proper color space, gamut management, etc) and then quite often you export back to RGB master (DPX etc). If you need YUV based master (typical broadcast format) then this is just single (final) conversion to YUV (it's also unavailable). In this case you have no chance for bad YUV file as you are protected by math. Resolve produces only valid RGB values, so there is no way RGB->YUV->RGB can be invalid (if we forget about unpredictable/unavoidable internal codec overshoots due to compression). Only processing in YUV (eg. Edius) can produce new YUV values which converted to RGB can create out of range signal. It's that reverse YUV->RGB step which can causes out of gamut errors in case of YUV signal is not coming directly from RGB source. In this conversion there is also colro space info (matrix) involved so it matters if we go to Rec.709 or Rec.2020.

YUV could be today always full levels and it would make thing way easier and less confusing.
Whole idea of limited range is a legacy from analog world where things were never perfect, so those "buffers" were important.
We could use RGB all he way, except this is not compression efficient as it links chroma with luma (and we want them separated), so not good. This is the reason why ProRes is always YUV based internally (DNxHR/Cineform can be YUV or RGB).
There are other color models, better than YUV/RGB (eg. new Dolby ICtCp), but it would be so hard to make them universal. We are so deeply buried in YUV and limited levels :)

This is why high-end production/grading/finish is rather RGB based, but once your produce YUV master for further deliveries in the chain (broadcast, etc.) then this typically should be processed in YUV without going back to RGB. With todays 32bit float processing this is way less important though.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostSat Nov 26, 2022 9:18 pm

Thanks a lot Andrew! :)
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostSun Nov 27, 2022 7:51 am

Andrew Kolakowski wrote:AVID (FCP, Edius not sure about Premiere) seems to use YUV internal processing, so this is very different.


Avid does not use YUV internal processing - it is 32bit float RGB, and has been for some time especially since you can choose this, up to 12bit (timeline, render higher), as your complete workflow.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSun Nov 27, 2022 11:27 am

This is why I said ‘seems’. Fact you can do 12bit doesn’t mean it can’t be YUV. It can be 32bit float YUV. It’s internal pixel format which typically has not much to do with export etc. formats. Apple uses special YUV4444 32bit float format.
I still suspect that when possible AVID will stay with YUV processing as it’s desired. Their documents suggest so as they have both RGB and YUV 32bit float formats. For ages AVID was always purely YUV internally.
Offline

Lucius Snow

  • Posts: 490
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Broadcast safe levels

PostSun Nov 27, 2022 12:14 pm

Andrew Kolakowski wrote:There are other color models, better than YUV/RGB (eg. new Dolby ICtCp)

Is that te one used in Dolby Vision Profile 5 for Blu-Ray UHD? I wonder by the way why profile 5 only.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSun Nov 27, 2022 12:33 pm

Yes, it’s.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostSun Nov 27, 2022 1:51 pm

Andrew Kolakowski wrote:This is why I said ‘seems’. Fact you can do 12bit doesn’t mean it can’t be YUV. It can be 32bit float YUV. It’s internal pixel format which typically has not much to do with export etc. formats. Apple uses special YUV4444 32bit float format.
I still suspect that when possible AVID will stay with YUV processing as it’s desired. Their documents suggest so as they have both RGB and YUV 32bit float formats. For ages AVID was always purely YUV internally.

As far as I know Andrew, all NLEs convert YUV to RGB computer space for processing. Avid works as I say. If SDI YUV in/out is necessary it is converted from and to. Avid is exactly like Resolve in this respect. The only difference between the two processing wise is the latter relies on GPU heavily and the former not. The way Avid now operates is very different from 2018 (old interface) and now as I say it is 32bit float.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:04 pm

32bit float has nothing to do with RGB vs YUV.
Old days most NLEs ( specially AVID, Edius) were purely YUV, where now they use RGB as well, but only when needed. New AVID has both 32bit float YUV and RGB presets.

Should we ask each company for statement? Then we know for sure.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:11 pm

Andrew Kolakowski wrote:Avid was all YUV as well which you can read about as stated by AVID support. Now it’s hybrid.


You talk so much nonsense Andrew, my friend :) get out of your bedroom and off forums and stop arguing with people who actually work professionally with these programmes day in day out. Sometimes instead of just trying to demonstrate theoretical knowledge, it would be preferable.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:17 pm

I already asked Adobe as it happens I have direct email to Premiere product manager.
Then we can see who talks nonsense on forums and who should leave them.
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:21 pm

Andrew Kolakowski wrote:I already asked Adobe as it happens I have direct email to Premiere product manager.
Then we can see who talks nonsense on forums and who should leave them.


Andrew, does it matter, what are you trying to prove? Nobody cares. Nobody really reads much into these kind of things. I don't know about Premiere, I don't work in it.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:34 pm

It’s 3rd time you accused me talking nonsense ( and already failed twice).
Told you. We will check based on facts who talks nonsense.
You and your professionalism…
Offline

Steve Fishwick

  • Posts: 976
  • Joined: Wed Mar 11, 2015 11:35 am
  • Location: United Kingdom

Re: Broadcast safe levels

PostSun Nov 27, 2022 4:37 pm

Andrew Kolakowski wrote:It’s 3rd time you accused me talking nonsense ( and already failed twice).
Told you. We will check based on facts who talks nonsense.
You and your professionalism…


I apologise, I shouldn't have said that in that way, but you do. Good advice about getting off the forums, though I rather think your 10x + posts to mine would be good advice, for both of us. And sorry I don't care what you find out since I know what I need to know, perhaps too little as all of us. All the best Andrew :D
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostFri Dec 02, 2022 2:25 pm

Andrew Kolakowski wrote:Have you tried this link to create TS cloud account:
https://cloud.telestream.net/console/signup

I see other services, but no Qualify. I think I use to be able to use it. Maybe it's gone.


I am afraid Telestream Vidchecker is not availabel (anymore) as a pay per use.
Instead they offer "qualify", but its only for users with a server based workflow.
So you need something like an Amazon AWS Storage to scan your files, its not possible to just select and upload files from your computer.
You have to post a link and it cannot be password protected, so as I am not allowed to publish any content that I produce for broadcast-stations - especially before being broadcasted - I cannot submit my files..

The only way seems to be Pulsar, but you need a Windows machine and pay 100 Euros minimum every six months.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostFri Dec 02, 2022 3:44 pm

I have not tested Qualify, but Transform (transcoding service) takes either local file or S3 link.
It can be secure storage, there are settings for S3 credentials (keys or IAM role).
You can also use pre-signed S3 links if I'm not wrong.
Telestream always runs EC2 machines which do the job in the same region, so no extra egress fees are involved.

Was Vidchecker ever available as pay per use?
Qualify will do needed checks and there is pure per minute cost without any extra charges. For single checks this is affordable.
Qualify is currently in beta, so if you need an account you need to talk to Telestream.
I can't see Qualify going anywhere if you can't use protected storage :) Telestream may as well never offer it as all their potential clients have strict security rules.
When did you try it ?
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostFri Dec 02, 2022 5:18 pm

I had an account but I have no s3 webspace. So I couldnt use it an canceled my account.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostFri Dec 02, 2022 5:35 pm

You need some storage. Upload is free, storage for the time of the test will cost not much at all.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostSat Dec 03, 2022 8:58 am

5 gb AWS is free, but for a 30 min file thats not enough. You have to ask AWS for a price if you need more. It gets more and more complicated as creating a template in telestream qualify by copying all the settings from an old vidchecker template has already cost me a lot of time. I think its not really worth investing much more time..

I will try a bit with pulsar which works on premise.
I guess there are a lot of false alarms, for example "Video clipping Chroma (Cb) level exceeded 255.00 for frame index 0 to 17958”. 255 should be thee maximum possible value for my 8 bit file, so how can it exceed?

I tried it with two files so far which were exported from avid or transcoded via adobe media encoder, so they should meet ARD_ZDF_HDF01a requirements.
However I received some error messages when scanning with your ARD_ZDF_HDF01a preset as "Index Table segements not present in the footer partition" or “Headeer metadata size in header partition is lesser than the user input” or “MXF version nuber does not match, user-defines 1.3 but fount 1.2.” or “Sample height does not match, user-defined 540 but found 544.”

I constantly get “Audio Mute zone” warnings, but audio in the first two mono tracks of my eight-track-op1a-file are perfectly fine. And the Loudness-range displays a wrong value.
I guess its not set up correctly to scan only track one and two as a stereo pair.

Then I got a lot of “Digital hits detected” errors, but I cant find none. What I can find is some moiré effect in some areas due to camera sharpening and downscaling from UHD to an interlaced format in my drone shots. So I guess “digital hits” find moiré as well".

And there is a "Field Dominance issue” in the middle of a whot where my graphics show up onsceen - the graphics is visible a few seconds before the error message as well so I guess this is a false alarm as well

And then it can scan for loudness, but I like to scan with "youlean loudness meter 2" much better as it offers much more detail.
I think most of those errors are false alarm or not very useful. I think that automated quality check is only a first check if you have to control massive amount of data on a server - not a tool for post..

For my personal use I think the free "QC Tools" is enough - it only doesnt find moiré issues, but cropping, luma and overall brightness levels over time and so on...
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSat Dec 03, 2022 10:10 am

You don’t need to ask for anything. Add card and that’s it.
If you do check and delete file not sure if AWS will charge you anything at all.
Basic cost is 0.023$/GB per month. If you keep 50GB file for few days then it’s <1$.

ZDF has few presets so you need to choose correct one. Same for export and check.
Those QC tools going to show you plenty false-positive, so you have to learn how to quickly interpret them.
I don’t use presets, don’t check for dropouts or anything like it with those tools as they are useless in this matter.
I just check for gamut, levels and loudness ( maybe MXF detailed check if required).
Rest is manual QC.
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostSat Dec 03, 2022 2:47 pm

You are right. But if I can trust broadcast safe filters from Adobe or Avid, and the other scan tools are worthless, then the QC Tool doensnt have any real benefit, as for loudness control there are better options which work on premise.
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSat Dec 03, 2022 3:42 pm

Yes. It doesn't matter how you check it as long as you know file will be fine. It's all what you need.

It's only an issue if you have urgent deadline and need to be sure files are definitely good. Problem is that most delivery places run on "clueless" juniors who operate on RED vs. GREEN flag only. They get eg. peak at -2.99 where spec says -3.0. File of course is fine, but for them it's a reject :)
This is why it's good to put through QC tools (best if you use same tool).
Always add small margin to your presets (I mean make them more strict). Adobe for example operates on higher precision. Vidchecker use to round (if I'm correct) loudness to 0.1 (I think they changed it now) so you quite often get +- 0.1 difference, which could mean reject :)
With loudness you just have to make sure you run test/normalisation on programme only. Silence won't affect end result but some audio tones etc. will.
I miss this as a feature in AME. I wish I could at least be able to exclude eg. first n seconds like QC tools allow you.
There is also another issue- some place will remember you as a delivery client and they keep track of your delivery results. If you keep sending bad files they may stop accepting them from you and if you send in name of your client then this can create "difficult situation" :)
Offline

Lucius Snow

  • Posts: 490
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Broadcast safe levels

PostSat Dec 03, 2022 5:49 pm

Andrew Kolakowski wrote:Vidchecker use to round (if I'm correct) loudness to 0.1 (I think they changed it now) so you quite often get +- 0.1 difference, which could mean reject :

That's why I ask the sound engineers I have to work with to reach -3,1 dBTP max. for broadcast files, not -3 dBTP. One shouted on me once because of my request.

- "ProTools says -3 dBTP"
- "I know, and it's probably right but some Q/C tools such as Vidchecker has a -0,1 margin"
- "I only trust ProTools!"
- "Fine but many televisions use Vidchecker"
- "Shut the fuc* up and send my mix like this!"
- "Are you sure?"
- "Yes!"
- "Okay okay".

Then, file rejected by the TV :roll:
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSat Dec 03, 2022 6:32 pm

Typical.
Depending on the place I don't let it go that easily, specially when most specs are -3dBTP +-0.1
In the same time to avoid problems I rather use more strict values, so I don't have to worry about tools precision.
As I said- it all fals into junior operated or auto operated systems which are based on black and white rules.
0.1 peak difference is totally meaningless in practice :)
Offline

Lucius Snow

  • Posts: 490
  • Joined: Sun Nov 24, 2013 1:19 pm

Re: Broadcast safe levels

PostSat Dec 03, 2022 6:58 pm

I used to warn the sound engineers before because they don't allow me any modification on their mix. But I've got bored of that meanless debate. So I just correct the signal by myself now...
Offline

Andrew Kolakowski

  • Posts: 8825
  • Joined: Tue Sep 11, 2012 10:20 am
  • Location: Poland

Re: Broadcast safe levels

PostSat Dec 03, 2022 8:54 pm

They're also "strange". Like this 0.1 dB would change the mix :)
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostFri Dec 09, 2022 10:13 am

I just tried Pulsar. Wow, so many false alarms. "Digital hits detected" where some ropes are seen hanging across the screen, "Camera Dead Pixels" when the camera doesnt move and films some lots of leaves in the background (so a lot of little shadows can be seen, maybe the size of a pixel), and for some strange reason a "field dominance issue" in the middle of three scenes, one is where the graphic shows up. But I cannot imagine a clean 1080i export from a 1080i timeline can create Field dominance issues. And then still "Video clipping Chroma (Cb) level exceeded 255 which shouldnt be possible mathematicalli, or is it?

And finally in the last shot of the whole movie a
"Color gamut violation detected from frame index 41452 to 41455. [Min,Max] value for Red(R) was found as [0(frame index 41452),235(frame index 41456)]. [Min,Max] value for Green(G) was found as [0(frame index 41452),231(frame index 41453)]. [Min,Max] value for Blue(B) was found as [0(frame index 41452),241(frame index 41453)]."

Strange, I added the FCPX Broadcast filter set to 1,5 exported as prores HQ and transcoded to XDCAM with Media Encoder and Broadcast Limiter with the strictest settings applied..
Offline

Petehikers

  • Posts: 60
  • Joined: Thu Jun 10, 2021 12:56 pm
  • Real Name: Pete hikers

Re: Broadcast safe levels

PostFri Dec 09, 2022 10:48 am

And those "Field Dominance issues" still happen in the MIDDLE of a graphic playing, not at the start. It has been exported with after effects as HD progressive and imported in a 1080i upper field first timeline, exported as 1080i, very strange..
PreviousNext

Return to Post Production

Who is online

Users browsing this forum: Marc Wielage, nnjrewzas112 and 7 guests