Conclusion

Having proved the basic functionality of the system, all that remained was to tidy up the design and improve the user interface. At a minimum, a method of cycling through a number of stored reference logos would be needed. This should be controlled via the pushbutton switches on the board, in order to remove the requirement for a debug terminal connection. One of the buttons would also be used to initiate a frame capture.

However, it was obvious that the resources of the current hardware platform were stretched to their limits, and that it would be difficult to implement all of the features necessary for a fully practical design. The logic resources of the FPGA are fully consumed, and it had already been necessary to abandon some of the planned feature in order to fit the design in. Therefore, I decided not to continue working on the current hardware platform. Despite this, I believe this project has been quite successful overall.

The basic concept of recreating the original television picture from information transmitted with semitransparent logos has been shown to be feasible, providing a high quality image without the use of any further processing techniques. It would be possible to further improve the system using additional methods, such as interpolation of video content outside the logo region, fading the logo in and out, etc.

A practical logo cancellation would rely on automatic recognition of logos for optimal performance. Although I did not get this part of the system working to my satisfaction, and the current circuit design does not allow for it at all, I believe that further study of established pattern recognition algorithms and techniques would yield a useable system. (A member of the EEVBlog forum pointed out that perfecting the recognition of station logos would also permit a simple 'ad-zapping' device to be implemented, by switching out the sound and picture in the commercial break when the station logo is not recognised.)

Another important component of a practical system would be some sort of 'auto-learn' system, for setting up the logo masks, as, even when using captured frames from the transmitted video stream, it is inconvenient to have to process the masks manually.

The software-based testing of the algorithms proved to be a wise choice, as I could then debug the hardware without worrying about the logic being incorrect. The technique of debugging application-level embedded code by compiling and executing it with a wrapper on a desktop PC is also a useful one to know, as it quite feasible when the firmware is written in standard C.

Although analogue RGB video is a relatively simple format to work with, implementing the interface to it did present some problems, even when using ASICs designed for the task. In retrospect, implementing a digital video interface may not have been that much more work. I believe that some FPGA development boards actually have inbuilt capabilities for this class of work.

The iCE40HX1K FPGA chip that I used turned out to be a fair choice for this application, despite the fact that I had essentially chosen it at random, and that its limitations did prevent some features of the design from being fully implemented. The basic logo cancellation logic did fit inside the device, although I underestimated the quantity of resources that the control logic would require. The low pin count also proved to be a bit of an issue, particularly as it forced the need to multiplex the connections to the configuration EEPROM, and the external address counter necessitated by the shortage of pins was also an inconvenience.

For a second-generation hardware platform, I would probably choose an FPGA with at least 4x the logic cell capacity, and enough pins for dedicated connections to the programming EEPROM, RAM address bus, and micro SD card. Although high pin count devices tend to use BGA packages, some are available pre-fitted to a development board, with all the pins broken out to a connector. Use of such a board would significantly reduce the amount of hardware design work required, as they typically have most of the support systems required for the FPGA already fitted. Some also have inbuilt DRAM, which might be an option for the frame store.

However, despite the flexibility of an FPGA-based approach, it did eventually prove to be the limitation in this design. Although this was partly attributable to the particular part chosen, it does further highlight the advantages of the initial software-based implementation. In the past, using this approach in an embedded situation had many disadvantages. Generally, using an x86 processor and full operating system resulted in a system that was expensive, bulky, high in power consumption and heat generation, and of limited reliability. (I once built a standalone MP3 player along these lines.) However, the multitude of cheap, small, low power single board computers on the market now has changed all of this. One of these would probably be the best choice for further development of this video processing system. Although the FPGA solution would still probably have cost advantages in high volume production, using an SBC would provide a considerable reduction in development time.

Back to Part 3 - Construction and Testing.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

loopgain.net