Showing posts with label PSE. Show all posts
Showing posts with label PSE. Show all posts

Sunday, December 28, 2014

PSE and the DPP - a whole lotta flashing going on

 One things that seems to have to come to light since the introduction of the DPP delivery spec at the start of October is just how badly folks understand the requirement for PSE (Photo Sensitive Epilepsy) with respect to TV deliverables. A lot of this is down to the fact that since the late '90s the industry has essentially had two standards - OFCOM and Harding
I did a talk to NBC-Universal's TV dept in July and you can snag the notes here - pay attention to p.12 to see why the important thing now is that the metadata of your AS-11 file needs to specify what algorithm was used and pass/fail.

For a (slightly noisy!) audio recording - download here.
For all the notes and test clips - Google Drive folder

Thursday, August 1, 2013

PSE detection, interlaced video and VidChecker

I've been preparing some training notes on PSE (hence last week's podcast) but noticed that VidChecker's analysis of a recent BBC recording suggested there were more flash events than were apparent to the eye. Have a look at this Off air MPEG2 from BBC News, 22nd July and pay attention to the timecodes as shown in the analysis in the second screen-grab. 

It looks like I've discovered a bug in VidChecker! The mixes to and from white that seem to provoke the PSE violation are at field rate (as you'd expect from any studio vision mixer) but VidChecker, by necessity, does a frame analysis and so the magic "...no more than 20 Cd/m2" prohibition on frame-frame luminance changes (as measured on a displayed calibrated at 200 Cd/m2 for peak white) are twice as likely to be triggered.

I mentioned this to the guys at VidCheck and this was the response;

Phil

You are right that the first 3 below are fades to white and back again and should not really be picked up as flashing.  

Scott has taken a look at the file, and it appears that the problem is in the interlacing artefacts during the fades where alternate lines are lighter and darker.  He has put in a fix for the next release.

Thanks again for the file and for finding this!  Attached some docs. You may already have them

Regards

Simon

The helpful document they sent was ITU rec 1702 which has a few more pointers than the OFCOM spec I used in the podcast.

Tuesday, July 30, 2013