GoTeamScotch wrote: ↑
Wed Oct 10, 2018 7:38 am
Any input would be appreciated! Thanks
Not sure if you're still looking for input on this, but I'm happy to provide some cycles analyzing the problem space.
So you want a screen flash filter.
That actually consists of several sub-problems.
A) Flash detection
For the flash detection problem, you're going to have to identify the qualities of the stream that are most likely to be associated with the phenomena of a rapidly flashing screen. This will either have to happen on a frame by frame basis, which will require decoding the stream. I haven't looked at the frame averaging thing someone else posted, but that could be useful.
Now you still have some extra linguistic holes to jump through as well. What constitutes a "flash"? Are you just looking for alternating swaps of two colors? Are you trying to pick out sequences of rapid shift from color to color on a frame by frame basis? How long a pattern should be recognized/sampled for? Does it have to be realtime, or are you okay with watching everything on a delay?
What type of content are you trying to filter anyway? Streamed stuff from major content providers? That's going to be protected by DRM that you may not be able to decode enough to do the flash protection you decide on on, as those solutions are starting to converge on requiring the last step of the stream decryption process to happen on the display device itself in an effort to close the holes through which the end representation can be sampled as "Smart Displays" are more and more becoming the norm due to the extra compute in them enabling collection of post-purchase data to provide extra revenue streams to the manufacturers. Use cases like yours sadly fall victim to this way of doing things.
Now let's talk about what happens when you detect a flash. What do you want to do about it?
Not render the frame? Replace the flashing bits with a default preset color? Render a static box over most of the frame? Try to massage the flash frequency down to something that doesn't cause issues? These are all viable strategies, but require additional computational resources to dig into the set of frames to figure out which parts are part of the flashing content, and which aren't. Then you select your desired transform of the guilty frames, apply it, then reconstitute the stream and send it on it"s way. Though once again, as DRM ends up winding it's way to being enforced by Video display device manufacturers, you'll have more and more problems with content from studios.
It isn't necessarily an insurmountable set of problems, but it is non-trivial. That is for sure. Finally enough, a neural network driven detector might be easier to implement than a traditional program, but I shudder at the thought of the compute likely required for that, and I'd be leery of trusting it to generalize well.