VideoObjects

VideoObjects is a class library in the field of digital video compression. Its parent codec was developed by Eidos plc, established in 1990 and publicly listed on The London Stock Exchange. VideoObjects is the object oriented implementation of this world-class codec which will be deployed in smalltalk, C++, VisualBasic and Delphi environments.

In 1990, Eidos' founding engineers developed a unique, proprietary software video codec which could perform on a computer processor significantly less powerful than today's mass market processors. This core technology was developed for initial product, Optima, a professional nonlinear video editing system implemented in software.

Subsequent to Optima, the product line was broadened into core technologies and application software. The core technology addresses a range of bandwidth sensitive applications: from video telephony to cable TV and from LANs to CD ROM.

In 1993, VideoObjects's source company, Eidos tm plc, won the prestigious Coopers & Lybrand Award for Best Performing Share on The London Stock Exchange.

Partnering for the Future

In cooperation with Eidos' development team, VideoObjects works closely with clients to develop variations of the class library conforming to particular needs. VideoObjects believes strongly in the co-operative team development; only through well-planned, focused, and timely development programs can one achieve realistic product goals for specific market needs.

Such relationships range from co-operation with telco product development teams, to electronic games developers and independent software vendors integrating VideoObject technology, to consumer electronics companies seeding proprietary variations of the codec's capabilities.

Teamwork by Design

VideoObjects is a dedicated and talented team focused on providing superior customer service and support. This commitment to quality is also reflected in the enthusiasm for creating innovative, market-leading video technology products.

Every member of the marketing/ sales and R&D teams have a vested interest in the Company's success...their rewards are tied to company performance. This simple formula enables VideoObjects, as well as its parent Eidos, to achieve consistently world class results.

Video Compression

Why is video compression important?

Interactive multimedia is a multi-billion dollar marketplace encompassing all forms of electronic entertainment, telecommunication, TV, games, military, security, government, health, and publishing markets. This new market "medium" demands ever faster processing and transmission of the variety of digital media, from text and data to video in particular.

Digital video is a vital element of multimedia with near infinite capacity for data storage or transmission bandwidth. This tremendous river of moving picture images must also be manipulated in real time at data rates up to 45 megabits per second. To put this Amazonian flow of data into perspective, an uncompressed video movie would take one year to send down a normal telephone line. This amount of digital information, uncompressed, is equivalent to 5,000 pages of text for every second of video. Consequently, processing and storing information in these quantities is beyond the capabilities of today's personal computers without special help.

Clearly, the development of radical technology is necessary to cope with this digital tidal wave, video compression is the only solution. And, radical new approaches to digital video compression technology are key components to the future success of the multimedia revolution.

VideoObjects Specializes in this technology.

Innovators in Software compression

When the information technology industry first addressed the problem of video compression in the early 1980's the installed base of PC's was running on Intel 8088 processors, approximately 300 times slower than today's hone-based multimedia PC's.

Not surprisingly, "standards" committees which tackled the video compression issue at the time had no choice but to specify dedicated hardware as the solution. Consequently, video compression standards and designs in use today, such as M-JPEG, MPEG, and H.320 were set in the relative silicon stone age of the early 1980's,

But times have changed. It is no longer necessary to use dedicated hardware when comparable performance can be attained in software. The innovative VideoObjects codec has proven it.

The Software advantage

Software only codecs

VideoObjects playback code can be written to a CD ROM. This is significant because it enables standard PC's to play back VHS quality video at 30 frames per second from a CD without the requirement of dedicated hardware. In essence, CD's can "auto-play" today off an installed base of 60 million+ 486 PC's without paying a cent for additional hardware. Approximately one and one-half hours of full motion video can be "squeezed" onto a CD.

The codec is also designed for real-time applications like video conferencing, video mail, electronic publishing---near video on demand or real-time news feeds--and other applications where the software advantage is equally compelling.

Rapid development

VideoObjects applications can be developed and adapted rapidly for widely varying uses, a tremendous advantage over any hardware based approach. Lead times are counted in man months to market, not man years, permitting quick prototyping and custom applications to be brought to market in near "real time".

The codec design is doubling the compression rate nearly every quarter, resulting in both improved picture quality and reduced data rates; and this rate of advancement will continue in the foreseeable future. Customers benefit because software is less expensive, easier to upgrade than hardware is scaleable on CPU power, and is platform independent.

The Multiplier effect

The software approach to video compression enables VideoObjects technology to compound its power at the same, or greater rate, than the renowned Moore's Law. This "law" states that microprocessor power doubles every 18 months, as is evident in the latest RISC processors.

Access to greater CPU horsepower translates into extraordinary advancements in ESCaPE power. Access to larger data paths (32 to 64 bit and beyond) and more "pipelined" instructions per cycle translates into a multiplication of the video processing power.

This multiplier effect gives the codec an extraordinary advantage over dedicated hardware solutions which, once cast in silicon, are set in stone. And, it leaves competitive software solutions in the dust.

TECHNOLOGY BACKGROUND

Frequently Asked Questions on VideoObjectsware video compression

"The New Standard for Visual Communications"

1. As VideoObject compression and decompression algorithms are initially developed on the ARM CPU architecture, what are the data bus bandwidth (MB per second transfer rate); instruction cache size; and other properties of the Advanced RISC Machines CPU family known as ARM 3, ARM 610 and ARM 710? See table below:

CPU Ext.clock Ext.bus Int.clock Read Write Cache

ARM 610 16 mhz 42.7 MB/s 30 mhz 120 MB/s 120 MB/s 4 KB

ARM 710 16 mhz 51.2 MB/s 40 mhz 160 MB/s 160 MB/s 8 KB

2. What is video/bus bandwidth (MB per second transfer rate) of the current demonstration machines, i.e. how fast can you write to the screen? Note, the codec will only use a portion of the entire video bus on most machines, therefore allowing multiple video streams to be "painted" to screen.

a. ACORN RISC PC- 51.2 MB/sec

b. INTEL 486 PCs: depends on video card, PCI or VESA local bus--all are known to be well within speed requirements of VideoObjects.

c. POWER PC- depends on model- all are know to be within speed requirements of the codec.

3. Where can the compression algorithms be "pushed" regarding their adaptability and strengths?

a. can it go wider bandwidth and bet better quality?: Yes.

b. can it use the same bandwidth and get higher quality?: Yes.

c. does it need both wider bandwidth and faster CPU to get better quality?: No, but it would benefit from both if required.

d. do the algorithms scale with both bandwidth and CPU power? In other words is scale a parameter of the algorithms or is it directly proportional (4x bandwidth= 4x CPU power)?

I) to double the resolution, you need 2x CPU power and 2x bandwidth for the current algorithms.

Future algorithm design will easily change this parameter as the "power" increased for newer CPU chips are tending to outrun capabilities of the supporting bus architectures and hardware.

ii) to double the compression with the same output quality does not require either more CUP power or bandwidth, ESCaPE design simply uses more "intelligent" algorithms.

4. For current VideoObjects algorithms can one slow down the frame rate to 12.5 to 15 fps, maximize color and resolution (display size) on the current ARM or Intel or PowerPC CPUs? If so, to what size?

i. Yes this can be done.

ii. For the ARM 610, the current compression and playback algorithms operate at CIF resolution of 384 x 288 x 16 bits color at 15 fps.

iii. For the Intel 486dx2-66, the current algorithms operate at 384 x 288 x 16 bit on playback only and at 320 x 240 x 8 bit color at 8 to 15 fps through a 128 kbps "pipe" for videophone application for compression and playback.

5. What is basis for compression design within the algorithms? Or, what is NOT being used?:

VQ- vector Quantization?: None

RLE- run-length-encoding?: None

Block truncation (color cell compression)?: Some

DCT- discrete cosine transform?: None

Motion compensation?: Some

Adaptive frequency (hi vs. Low) compensation?: None

Fractals?: Some

Wavelets?: None

Huffman series encoding?: Some

Other or combination?: YES

a. is VideoObjects a form or "region grow/block truncation encoding with vector quantization at high and low frequencies"?: Not whatsoever.

6. Is the color palette "color quantisized" to 8-bits (or 16 bit) using maximum 256 color palette? If not either of these, what is maximum color palette?

it is 16 bpp at 65,536 colors. Note: to display the 16 bpp color requires a 24 bpp display card because although colors are stored at 16 bit, the 16 bit cards are using the wrong 64,000 colors.

7. Can the VideoObjects stream play multiple windows from many sources? If not, what is limitation?

Yes, VideoObjects can play from multiple sources in multiple windows. It all depends on the parameters of the CPU & video bandwidth (therefore picture quality)...the more CPU power with smaller video streams means more pictures. Currently, the codec is capable of displaying 3 ISDN BRI video streams in one window operation under Windows 3.1 on a 486dx2-66 platform with PCI local bus.

Any one of the following items can be a limitation on number of windows and number of sources: a. CPU Bus; b. video bus; c. disk speed; system RAM; e. video RAM.

8. In video demo's of the "beach scene" utilized a 15 bpp color display card operation on a Acorn 5000 ARM 3- 33mhz CPU. Is the video stored at 15 bit with the video card changing resolution to 8-bit display "on the fly"?

No. The video card is too slow for the algorithms and therefore does not gain the full benefit of the codec. It is the codec which adjusts the color space and picture on the fly to accommodate the slower 8 bit display.

9. Is encoding done in TV standard YUV (5:5:5) or (4:1:1) component color space or in computer RGB (5:5:5)? If neither, what is it?

VideoObjects color encoding was YUV 5:5:5 component for the 1993 demonstrations, but it has been upgraded again for 1994 for greater color definition.

9. What difference does YUV make on the algorithms versus RGB color space? How does either one affect performance?

YUV component color space is better at handling color "noise" than RGB. YUV is also a more efficient definition of color as it uses a "vector 3rd dimension" versus a "block 3rd dimension". As a result, YUV provides better performance and color definition than RGB color space.

10. If YUV encoding is the color space the codec works with, how does it handle conversion from YUV to RGB to show it on a VGA multiscan screen?

By approximating color on 15 bpp screens, ESCaPE can display exact color on 24 bpp screens.

11. What is the error correction scheme for 28.8 kbps for analog video phone application?

a. Is it error "concealment" or error "correction"?: It is error correction.

b. Whichever answer above, how much of the bandwidth in bits does it occupy?: It depends on how bad ("dirty") the line is at the given time...noisier lines equals fewer frames sent.

12. What is the error correction scheme for the 128 kbps ISDN2 BRI digital video phone application?

a. Is it error "concealment" or error "correction"?: ONLY error "detection". It presumes there are no errors on ISDN digital lines as there are supposedly "noise free".

b. Whichever answer above, how much of the bandwidth in bits does it occupy?: It depends on how bad ("dirty") the line is at the given time...noisier lines equals fewer frames sent. Generally, 96 kbps for video.

13. In any of the video demo's, what is maximum and minimum bandwidth which VideoObjects

VideoObjects is a class library in the field of digital video compression. Its parent codec was developed by Eidos plc, established in 1990 and publicly listed on The London Stock Exchange. VideoObjects is the object oriented implementation of this world-class codec which will be deployed in smalltalk, C++, VisualBasic and Delphi environments.

In 1990, Eidos' founding engineers developed a unique, proprietary software video codec which could perform on a computer processor significantly less powerful than today's mass market processors. This core technology was developed for initial product, Optima, a professional nonlinear video editing system implemented in software.

Subsequent to Optima, the product line was broadened into core technologies and application software. The core technology addresses a range of bandwidth sensitive applications: from video telephony to cable TV and from LANs to CD ROM.

In 1993, VideoObjects's source company, Eidos tm plc, won the prestigious Coopers & Lybrand Award for Best Performing Share on The London Stock Exchange.

Partnering for the Future

In cooperation with Eidos' development team, VideoObjects works closely with clients to develop variations of the class library conforming to particular needs. VideoObjects believes strongly in the co-operative team development; only through well-planned, focused, and timely development programs can one achieve realistic product goals for specific market needs.

Such relationships range from co-operation with telco product development teams, to electronic games developers and independent software vendors integrating VideoObject technology, to consumer electronics companies seeding proprietary variations of the codec's capabilities.

Teamwork by Design

VideoObjects is a dedicated and talented team focused on providing superior customer service and support. This commitment to quality is also reflected in the enthusiasm for creating innovative, market-leading video technology products.

Every member of the marketing/ sales and R&D teams have a vested interest in the Company's success...their rewards are tied to company performance. This simple formula enables VideoObjects, as well as its parent Eidos, to achieve consistently world class results.

Video Compression

Why is video compression important?

Interactive multimedia is a multi-billion dollar marketplace encompassing all forms of electronic entertainment, telecommunication, TV, games, military, security, government, health, and publishing markets. This new market "medium" demands ever faster processing and transmission of the variety of digital media, from text and data to video in particular.

Digital video is a vital element of multimedia with near infinite capacity for data storage or transmission bandwidth. This tremendous river of moving picture images must also be manipulated in real time at data rates up to 45 megabits per second. To put this Amazonian flow of data into perspective, an uncompressed video movie would take one year to send down a normal telephone line. This amount of digital information, uncompressed, is equivalent to 5,000 pages of text for every second of video. Consequently, processing and storing information in these quantities is beyond the capabilities of today's personal computers without special help.

Clearly, the development of radical technology is necessary to cope with this digital tidal wave, video compression is the only solution. And, radical new approaches to digital video compression technology are key components to the future success of the multimedia revolution.

VideoObjects Specializes in this technology.

Innovators in Software compression

When the information technology industry first addressed the problem of video compression in the early 1980's the installed base of PC's was running on Intel 8088 processors, approximately 300 times slower than today's hone-based multimedia PC's.

Not surprisingly, "standards" committees which tackled the video compression issue at the time had no choice but to specify dedicated hardware as the solution. Consequently, video compression standards and designs in use today, such as M-JPEG, MPEG, and H.320 were set in the relative silicon stone age of the early 1980's,

But times have changed. It is no longer necessary to use dedicated hardware when comparable performance can be attained in software. The innovative VideoObjects codec has proven it.

The Software advantage

Software only codecs

VideoObjects playback code can be written to a CD ROM. This is significant because it enables standard PC's to play back VHS quality video at 30 frames per second from a CD without the requirement of dedicated hardware. In essence, CD's can "auto-play" today off an installed base of 60 million+ 486 PC's without paying a cent for additional hardware. Approximately one and one-half hours of full motion video can be "squeezed" onto a CD.

The codec is also designed for real-time applications like video conferencing, video mail, electronic publishing---near video on demand or real-time news feeds--and other applications where the software advantage is equally compelling.

Rapid development

VideoObjects applications can be developed and adapted rapidly for widely varying uses, a tremendous advantage over any hardware based approach. Lead times are counted in man months to market, not man years, permitting quick prototyping and custom applications to be brought to market in near "real time".

The codec design is doubling the compression rate nearly every quarter, resulting in both improved picture quality and reduced data rates; and this rate of advancement will continue in the foreseeable future. Customers benefit because software is less expensive, easier to upgrade than hardware is scaleable on CPU power, and is platform independent.

The Multiplier effect

The software approach to video compression enables VideoObjects technology to compound its power at the same, or greater rate, than the renowned Moore's Law. This "law" states that microprocessor power doubles every 18 months, as is evident in the latest RISC processors.

Access to greater CPU horsepower translates into extraordinary advancements in ESCaPE power. Access to larger data paths (32 to 64 bit and beyond) and more "pipelined" instructions per cycle translates into a multiplication of the video processing power.

This multiplier effect gives the codec an extraordinary advantage over dedicated hardware solutions which, once cast in silicon, are set in stone. And, it leaves competitive software solutions in the dust.

TECHNOLOGY BACKGROUND

Frequently Asked Questions on VideoObjectsware video compression

"The New Standard for Visual Communications"

1. As VideoObject compression and decompression algorithms are initially developed on the ARM CPU architecture, what are the data bus bandwidth (MB per second transfer rate); instruction cache size; and other properties of the Advanced RISC Machines CPU family known as ARM 3, ARM 610 and ARM 710? See table below:

CPU Ext.clock Ext.bus Int.clock Read Write Cache

ARM 610 16 mhz 42.7 MB/s 30 mhz 120 MB/s 120 MB/s 4 KB

ARM 710 16 mhz 51.2 MB/s 40 mhz 160 MB/s 160 MB/s 8 KB

2. What is video/bus bandwidth (MB per second transfer rate) of the current demonstration machines, i.e. how fast can you write to the screen? Note, the codec will only use a portion of the entire video bus on most machines, therefore allowing multiple video streams to be "painted" to screen.

a. ACORN RISC PC- 51.2 MB/sec

b. INTEL 486 PCs: depends on video card, PCI or VESA local bus--all are known to be well within speed requirements of VideoObjects.

c. POWER PC- depends on model- all are know to be within speed requirements of the codec.

3. Where can the compression algorithms be "pushed" regarding their adaptability and strengths?

a. can it go wider bandwidth and bet better quality?: Yes.

b. can it use the same bandwidth and get higher quality?: Yes.

c. does it need both wider bandwidth and faster CPU to get better quality?: No, but it would benefit from both if required.

d. do the algorithms scale with both bandwidth and CPU power? In other words is scale a parameter of the algorithms or is it directly proportional (4x bandwidth= 4x CPU power)?

I) to double the resolution, you need 2x CPU power and 2x bandwidth for the current algorithms. Future algorithm design will easily change this parameter as the "power" increased for newer CPU chips are tending to outrun capabilities of the supporting bus architectures and hardware.

ii) to double the compression with the same output quality does not require either more CUP power or bandwidth, ESCaPE design simply uses more "intelligent" algorithms.

4. For current VideoObjects algorithms can one slow down the frame rate to 12.5 to 15 fps, maximize color and resolution (display size) on the current ARM or Intel or PowerPC CPUs? If so, to what size?

i. Yes this can be done.

ii. For the ARM 610, the current compression and playback algorithms operate at CIF resolution of 384 x 288 x 16 bits color at 15 fps.

iii. For the Intel 486dx2-66, the current algorithms operate at 384 x 288 x 16 bit on playback only and at 320 x 240 x 8 bit color at 8 to 15 fps through a 128 kbps "pipe" for videophone application for compression and playback.

5. What is basis for compression design within the algorithms? Or, what is NOT being used?:

VQ- vector Quantization?: None

RLE- run-length-encoding?: None

Block truncation (color cell compression)?: Some

DCT- discrete cosine transform?: None

Motion compensation?: Some

Adaptive frequency (hi vs. Low) compensation?: None

Fractals?: Some

Wavelets?: None

Huffman series encoding?: Some

Other or combination?: YES

a. is VideoObjects a form or "region grow/block truncation encoding with vector quantization at high and low frequencies"?: Not whatsoever.

6. Is the color palette "color quantisized" to 8-bits (or 16 bit) using maximum 256 color palette? If not either of these, what is maximum color palette?

it is 16 bpp at 65,536 colors. Note: to display the 16 bpp color requires a 24 bpp display card because although colors are stored at 16 bit, the 16 bit cards are using the wrong 64,000 colors.

7. Can the VideoObjects stream play multiple windows from many sources? If not, what is limitation?

Yes, VideoObjects can play from multiple sources in multiple windows. It all depends on the parameters of the CPU & video bandwidth (therefore picture quality)...the more CPU power with smaller video streams means more pictures. Currently, the codec is capable of displaying 3 ISDN BRI video streams in one window operation under Windows 3.1 on a 486dx2-66 platform with PCI local bus.

Any one of the following items can be a limitation on number of windows and number of sources: a. CPU Bus; b. video bus; c. disk speed; system RAM; e. video RAM.

8. In video demo's of the "beach scene" utilized a 15 bpp color display card operation on a Acorn 5000 ARM 3- 33mhz CPU. Is the video stored at 15 bit with the video card changing resolution to 8-bit display "on the fly"?

No. The video card is too slow for the algorithms and therefore does not gain the full benefit of the codec. It is the codec which adjusts the color space and picture on the fly to accommodate the slower 8 bit display.

9. Is encoding done in TV standard YUV (5:5:5) or (4:1:1) component color space or in computer RGB (5:5:5)? If neither, what is it?

VideoObjects color encoding was YUV 5:5:5 component for the 1993 demonstrations, but it has been upgraded again for 1994 for greater color definition.

9. What difference does YUV make on the algorithms versus RGB color space? How does either one affect performance?

YUV component color space is better at handling color "noise" than RGB. YUV is also a more efficient definition of color as it uses a "vector 3rd dimension" versus a "block 3rd dimension". As a result, YUV provides better performance and color definition than RGB color space.

10. If YUV encoding is the color space the codec works with, how does it handle conversion from YUV to RGB to show it on a VGA multiscan screen?

By approximating color on 15 bpp screens, ESCaPE can display exact color on 24 bpp screens.

11. What is the error correction scheme for 28.8 kbps for analog video phone application?

a. Is it error "concealment" or error "correction"?: It is error correction.

b. Whichever answer above, how much of the bandwidth in bits does it occupy?: It depends on how bad ("dirty") the line is at the given time...noisier lines equals fewer frames sent.

12. What is the error correction scheme for the 128 kbps ISDN2 BRI digital video phone application?

a. Is it error "concealment" or error "correction"?: ONLY error "detection". It presumes there are no errors on ISDN digital lines as there are supposedly "noise free".

b. Whichever answer above, how much of the bandwidth in bits does it occupy?: It depends on how bad ("dirty") the line is at the given time...noisier lines equals fewer frames sent. Generally, 96 kbps for video.

13. In any of the video demo's, what is maximum and minimum bandwidth which sound occupies in the bit stream?

For ISDN2 BRI demo, about 32 kbps for sound and for CD-ROM use max. of 22 KB/s uncompressed sampled at 44 khz from a standard sound board.

14. What is the replay power figure in terms of MIPS for the 486 replay under Windows for the ESCaPE algorithm?

VideoObjects is efficient and can play back at 320 x 240 x 16 bits at 15 fps on an Intel 386dx-33mhz machine off a 150 KB CD-ROM.

a. is the mode running DOS under Windows, or within Windows itself?

It runs under Video for Windows within the Windows 3.1 and Windows95 system. It also runs under DOS itself and DOS within Windows. Therefore, it is utilizing its own drivers within VfW and using the .AVI format for its replay files.

15. What is the main bottleneck for algorithms in any PC based system?

The principal bottleneck on any PC system is first, Video for Windows for Quicktime, and second, their respective subsystems. Either VfW or Quicktime are extraordinarily slow at handling the demands of video as they are not fully integrated into the operating system.

a. what and where is it in any PC playback system which constrains quality?

The answer is the same as above.

b. are primary bottlenecks CPU restrictions, access to frame buffers for display, or bus data rates?

In addition to the software "overhead" or "baggage" the CPU must endure, the display card can often be a bottleneck as well. Frame buffers are often large enough in most cards/ boards/ or subsystems for VideoObjects to operate very efficiently.

16. Can the algorithms be written in standard ANSI C code and be recompiled for various operation systems or CPUs?

Yes, they can be and were completed in summer 1994. In fact, they can even operate under any Unix "X" Windows compliant operating system on any known platform which has the power to run X-Windows.

17. Are VideoObjects algorithms based on integer performance, or is it integer performance sensitive? If NOT, what (floating point?)?

The algorithms use integer only calculations. Therefore, any CPU which has a strong integer performance will simply run ESCaPE faster.

18. Within the algorithms, is sub-sampling of video color in chroma or luminance?

VideoObjects sub-samples principally in chroma with some luminance. Luminance sampling is far more rigorous than chrominance unless the sub-sampling is being done on spatial intervals.

19. What is the effect of video RAM, if any, on any version of the codec for video display resolution?

In the 1993 Acorn 5000 (ARM 3- 33mhz CPU) demo's, the machine had no video RAM whatsoever.

The resolution of the codec pictures increases with the addition of video RAM as more information can be sent more quickly to screen.

a. what is absolute min. RAM to run 1/2 CIF (160 x 120)?

The codec requires at least 180 KB of system RAM to run the decompression algorithms, excluding display RAM.

b. what is absolute min. RAM to run full CIF (320 x 240)?

VideoObjects requires at least 450 KB of system RAM to run decompression algorithms, excluding display RAM.

c. will it work in 512 KB RAM and what's theoretical resolution?

Yes, at full CIF resolution.

d. which RAM is most important to video display resolution- video RAM or System RAM?

VideoObjects uses system RAM. Video RAM acts as the frame buffer waiting to paint pictures to the screen and, thus, only affects to some degree resolution. More critical is system RAM as here is where the "work" is done to create and display pictures off files.

e. does hardware CPU cache (instruction or other) affect the parameters for video display resolution and speed?

As in answer above, CPU RAM cache size can positively affect display resolution and speed, the more the better.

20. Can VideoObjects algorithms work on the Motorola 68000 12.5 mhz chip replaying only?

Yes, at a lower resolution, possibly 160 x 120 x 8 bits at 15 fps. The Motorola 68000 chip is about 15% slower than the ARM 3 chip.

21. Regarding the PC videophone codec version Q3-1993, if displaying 320 x 240 x 8 bits at 2-bits per pixel block, is algorithm reprocessing for replay only 160 x 120 x 8 bits, or only 20.7 KB per frame.

No. In the compression mode the codec processes the entire bit stream any digitizer is capable of processing, most are capable of at least 320 x 240 x 15 bits (as is the one used in the videophone demo in Q3- 1993). After processing the bit stream, VideoObjects is storing approximately 3 to 5k per compressed frame, depending on complexity (movement) of content. When the stored file or transmission stream is un-compressed and redisplayed to screen it is reconfiguring and dithering the bit stream to display at 320 x 240 x 8 bits at 10 to 18 fps in color in real-time.

22. With the VideoObjects codec running at analog video phone rates of 28.8 kbps, what is projected or anticipated color space?

VideoObjects uses YUV component color space and this will be updated continuously as greater power and hardware capabilities enable it to process greater amounts of data.

23. What is projected video resolution in color at ISDN2 BRI 128 kbps and at what frame rate?

VideoObjects videophone at IDSN2 BRI will achieve from 10 to 18 frames per second at 320 x 240 x 8 bits color.

24. What is color component space at VideoObjects videophone ISDN2 BRI rate of 128 kbps?

VideoObjects videophone algorithms work with YUV component capture and RGB composite playback. The "picture" and resolution is an abstract representation of compressed video.

25. What is the difference between VideoObjects at 128 kbps versus Px64 or H.261 hardware techniques (note- Px64 already achieves 1/4 CIF resolution at 180x144 display storing 90x72 compressed data)? Is VideoObjects better?

Yes, VideoObjects is significantly better in many respects. VideoObjects achieves 320 x 240 x 8 bit color resolution as opposed to 1/4 CIF of Px64 at 180 x 144 x 8 bit color.

a. what other elements besides the "software solution" is VideoObjects better than either ITU Video telephony standard?

VideoObjects is better than either H.261 or Px64 standard in numerous respects already; these are:

1. better resolution- therefore better granularity and detail in the picture, picture resolution provides greater color realism.

2. better frame rate- therefore better on-screen motion means more realistic facial and body expressions.

3. truer color tones- due to VideoObjects's processing the entire bit stream the digitizer that VideoObjects is processing in compression prior to transmission and redisplay.

4. higher latency- it is better than either ITU standard due to VideoObjects's ability to process more information, more accurately, and redisplay at better resolutions over a given pipeline. VideoObjects is fast enough that reduced latency is introduced by the hardware only, not the software.

5. easier manipulation and storage of video files- VideoObjects can be edited, cut, pasted, and stored on any standard PC storage medium, making it significantly more useful than either know standard. For instance, it can be used for Video Mail across LAN/ WAN enterprise networks (as in Microsoft Mail, Lotus cc:Mail or Notes).

26. At 28.8 kbps, if VideoObjects will displaying 1/4 CIF at 8-12 fps at 8-bit resolution and 8 bit color, does this mean the VideoObjects algorithms are processing a full 320x240 bit stream, or a digitizer hardware reduced 160x120 or 80x60?

VideoObjects algorithms process the full bit stream any known digitizer is capable of processing. VideoObjects algorithms analyze and compress the bit stream to fit the 28.8 kbps data pipeline. 27. If H.26P (for PSTN applications- a "family" of the H.261 std.) uses 11.2 bits for video and 3.2 kbits for sound, what is VideoObjects projected to use for the video/ sound mix at 28.8 kbps?? a. Video bits = 19.8 kbps (if lines are "dirty" will simply drop frames). b. Data/ Sound bits = 9.0 kbps.

28. How much of VideoObjects algorithm instruction mix is devoted to post and pre-processing of bit stream?

VideoObjects algorithms both pre- and post-process the video bit stream in a continuous manner which are not independent of one another, they are interdependent.

a. IF pre- & post-processing exists, does this vary on a scalable basis; meaning the larger bit stream gets better screen resolution? And, if it does exist, does an increase of CPU MIPS increase the resolution for a fixed bit stream?

Yes, the VideoObjects algorithms will vary resolution and frame rate on a scalable basis and more CPU MIPS increase the resolution for a given bit rate. See earlier discussion on this matter in Question #3. Furthermore, the algorithm designs for VideoObjects can be adapted for specific situations or requirements.

29. For current versions of VideoObjects algorithms, does the digitizer board pre-process the bit stream before VideoObjects algorithms begin processing the actual bit stream?

No. VideoObjects algorithms do all the processing of the bit steam. The Digitizer boards themselves are seen as the limitation on VideoObjects, not the other way around.

a. does the digitizer board automatically drop the bit stream from 764x576 to 325x256x16 bit before VideoObjects begins processing?

Yes, this can be done, but VideoObjects prefers to "see" the entire bit stream to get a more accurate color "read" and content "read" than what hardware reduced bit streams permit.

b. or, does VideoObjects process the initial 764x576 bit stream down to 163x128 (or whatever) for storage/ replay/ transmission?

Yes, VideoObjects processes the entire bit stream it "sees". The more it "sees" the better the resultant picture on replay.

c. does VideoObjects do all the compression from the full bit stream that ANY digitizer board can potentially process (like broadcast quality 30 fps with 2 field per frame at 764 x 576 x 24 bit color)?

Yes, see first answer.

d. what are the differences in digitizer board pre-processing, if any, between Acorn machine boards and PC/ Mac boards??

All boards vary tremendously in design and actual execution of the bit stream. VideoObjects only cares to "see" the bit stream as defined by the board and will act upon that element only. Only drivers need to be written for each digitizer board for VideoObjects to act upon a particular bit stream.

30. With the Motorola PowerPC or 100 mhz CPUs, or with the Intel 486dx2 or 486dx4 or Pentium 60 or 90 mhz CPUs presuming there's 20 MIPS available at all times in the clock/ instruction cycle, could VideoObjects utilized fully symmetric processing to show two-way video at 128 kbps on the same CPU?? This presumes some form of multi-point to multi-point video conferencing.

Yes, with relative ease. VideoObjects can already replay on the Acorn 5000 (ARM 3- 33 mhz) machine four sources at ISDN BRI 128 kbps rate. VideoObjects can also replay four or more source windows on the host CPU for the Intel 486 and Pentium as well as the Power PC.

Furthermore, the ability to display three incoming video streams as well as process (compress) one outgoing stream is entirely possible within the power of the 486dx2-66 or 100 mhz CPUs, any Pentium, or the Power PC 601 or 620 chips.

31. If VideoObjects uncompiled ANSI C code algorithms work under X-Windows compliant environments, does this imply that it can work under ANY Unix machine which can run an "X-Windows complaint" operating system?

Yes, VideoObjects has been written in standard ANSI C code and can effectively run on all of the following machines running under "X Windows" in Unix:

a. IBM RISC 6000 using PowerPCs with AUX.

b. HP Vectra 9000 or Apollo RISC machines with HP Unix.

c. Silicon Graphics MIPS workstations with X-Windows.

d. Sun SPARC with Solaris/ X-Windows.

e. Data General, Tandem Computer, Thinking Machines, that run any X-Window iteration.

f. any machine that runs "Linux", a version of Unix running "X" windows.

g. DEC Alpha AXP machines running any iteration of X-windows Unix.

h. Apple Power Pcs running Apple AUX (X-windows compliant).

i. NEC MIPS machines running Motif or X-Windows Unix.

32. What is HIGHEST quality playback resolution video (sound and video) which can be compressed onto a CD-ROM disk (i.e. understood it must be squeezed onto a 600 MB floptical and "pressed" at an outside publishing house) TODAY?

VideoObjects can be compressed to run better than MPEG1 at a resolution of 384 x 288 x 24 bpp at 30 fps. In other words, a very high quality video playback is achievable on the ARM 700 machine. By Q3 1995 this will be possible under the Windows VfW environment as well.

a. how many minutes of the highest quality video may be stored on a 600 MB CD-ROM?

Depends on the CD-ROM rate. As in the above, if a 600 MB capacity disk is running at its maximum display transfer rate of 150 KB per sec, this means you are limited to 72 minutes of video storage. If you run a 2x speed CD-ROM at 300 KB per sec, you are limited to half the above, or approximately 31 minutes of video storage. The alternative is to fine tune new VideoObjects algorithms to run around 85 KB per sec for an MPEG1 quality video of 384 x 288 x 16 bpp at 25 fps; meaning an entire movie can be stored on one side of a CD-ROM.

33. What is the anticipated size of a "multi-file format compatible playback engine" which can be stored on individual PCs so that any individual's PC can playback any file created by any version of VideoObjects at any resolution or data rate?

VideoObjects algorithm design is so efficient that a playback file size of approximately 100 K can be designed to incorporate playback routines for at least eight (8) playback files at the following "pipeline rates":

a. 28.8 analog video

b. 112 kbps IDSN2 video

c. 384 kbps (48 KB) ISDN6, ADSL video

d. 1.2 mbps (150 KB) CD-ROM video, T1 lines

e. 2.4 mbps (300 KB) ISDN30, 2x CD-ROM video

f. 10 Mbps (1,25 MB) Ethernet (Fast Ethernet = 100 Mbps)

g. 16 Mbps (2 MB) switched video on demand

For ISDN2 BRI demo, about 32 kbps for sound and for CD-ROM use max. of 22 KB/s uncompressed sampled at 44 khz from a standard sound board.

14. What is the replay power figure in terms of MIPS for the 486 replay under Windows for the ESCaPE algorithm?

VideoObjects is efficient and can play back at 320 x 240 x 16 bits at 15 fps on an Intel 386dx-33mhz machine off a 150 KB CD-ROM.

a. is the mode running DOS under Windows, or within Windows itself?

It runs under Video for Windows within the Windows 3.1 and Windows95 system. It also runs under DOS itself and DOS within Windows. Therefore, it is utilizing its own drivers within VfW and using the .AVI format for its replay files.

15. What is the main bottleneck for algorithms in any PC based system?

The principal bottleneck on any PC system is first, Video for Windows for Quicktime, and second, their respective subsystems. Either VfW or Quicktime are extraordinarily slow at handling the demands of video as they are not fully integrated into the operating system.

a. what and where is it in any PC playback system which constrains quality?

The answer is the same as above.

b. are primary bottlenecks CPU restrictions, access to frame buffers for display, or bus data rates?

In addition to the software "overhead" or "baggage" the CPU must endure, the display card can often be a bottleneck as well. Frame buffers are often large enough in most cards/ boards/ or subsystems for VideoObjects to operate very efficiently.

16. Can the algorithms be written in standard ANSI C code and be recompiled for various operation systems or CPUs?

Yes, they can be and were completed in summer 1994. In fact, they can even operate under any Unix "X" Windows compliant operating system on any known platform which has the power to run X-Windows.

17. Are VideoObjects algorithms based on integer performance, or is it integer performance sensitive? If NOT, what (floating point?)?

The algorithms use integer only calculations. Therefore, any CPU which has a strong integer performance will simply run ESCaPE faster.

18. Within the algorithms, is sub-sampling of video color in chroma or luminance?

VideoObjects sub-samples principally in chroma with some luminance. Luminance sampling is far more rigorous than chrominance unless the sub-sampling is being done on spatial intervals.

19. What is the effect of video RAM, if any, on any version of the codec for video display resolution?

In the 1993 Acorn 5000 (ARM 3- 33mhz CPU) demo's, the machine had no video RAM whatsoever.

The resolution of the codec pictures increases with the addition of video RAM as more information can be sent more quickly to screen.

a. what is absolute min. RAM to run 1/2 CIF (160 x 120)?

The codec requires at least 180 KB of system RAM to run the decompression algorithms, excluding display RAM.

. what is absolute min. RAM to run full CIF (320 x 240)?

VideoObjects requires at least 450 KB of system RAM to run decompression algorithms, excluding display RAM.

c. will it work in 512 KB RAM and what's theoretical resolution?

es, at full CIF resolution.

d. which RAM is most important to video display resolution- video RAM or System RAM?

VideoObjects uses system RAM. Video RAM acts as the frame buffer waiting to paint pictures to the screen and, thus, only affects to some degree resolution. More critical is system RAM as here is where the "work" is done to create and display pictures off files.

e. does hardware CPU cache (instruction or other) affect the parameters for video display resolution and speed?

As in answer above, CPU RAM cache size can positively affect display resolution and speed, the more the better.

20. Can VideoObjects algorithms work on the Motorola 68000 12.5 mhz chip replaying only?

Yes, at a lower resolution, possibly 160 x 120 x 8 bits at 15 fps. The Motorola 68000 chip is about 15% slower than the ARM 3 chip.

21. Regarding the PC videophone codec version Q3-1993, if displaying 320 x 240 x 8 bits at 2-bits per pixel block, is algorithm reprocessing for replay only 160 x 120 x 8 bits, or only 20.7 KB per frame.

No. In the compression mode the codec processes the entire bit stream any digitizer is capable of processing, most are capable of at least 320 x 240 x 15 bits (as is the one used in the videophone demo in Q3- 1993). After processing the bit stream, VideoObjects is storing approximately 3 to 5k per compressed frame, depending on complexity (movement) of content. When the stored file or transmission stream is un-compressed and redisplayed to screen it is reconfiguring and dithering the bit stream to display at 320 x 240 x 8 bits at 10 to 18 fps in color in real-time.

22. With the VideoObjects codec running at analog video phone rates of 28.8 kbps, what is projected or anticipated color space?

VideoObjects uses YUV component color space and this will be updated continuously as greater power and hardware capabilities enable it to process greater amounts of data.

23. What is projected video resolution in color at ISDN2 BRI 128 kbps and at what frame rate?

VideoObjects videophone at IDSN2 BRI will achieve from 10 to 18 frames per second at 320 x 240 x 8 bits color.

24. What is color component space at VideoObjects videophone ISDN2 BRI rate of 128 kbps?

VideoObjects videophone algorithms work with YUV component capture and RGB composite playback. The "picture" and resolution is an abstract representation of compressed video.

25. What is the difference between VideoObjects at 128 kbps versus Px64 or H.261 hardware techniques (note- Px64 already achieves 1/4 CIF resolution at 180x144 display storing 90x72 compressed data)? Is VideoObjects better?

Yes, VideoObjects is significantly better in many respects. VideoObjects achieves 320 x 240 x 8 bit color resolution as opposed to 1/4 CIF of Px64 at 180 x 144 x 8 bit color.

a. what other elements besides the "software solution" is VideoObjects better than either ITU Video telephony standard?

VideoObjects is better than either H.261 or Px64 standard in numerous respects already; these are:

1. better resolution- therefore better granularity and detail in the picture, picture resolution provides greater color realism.

2. better frame rate- therefore better on-screen motion means more realistic facial and body expressions.

3. truer color tones- due to VideoObjects's processing the entire bit stream the digitizer that VideoObjects is processing in compression prior to transmission and redisplay.

4. higher latency- it is better than either ITU standard due to VideoObjects's ability to process more information, more accurately, and redisplay at better resolutions over a given pipeline. VideoObjects is fast enough that reduced latency is introduced by the hardware only, not the software.

5. easier manipulation and storage of video files- VideoObjects can be edited, cut, pasted, and stored on any standard PC storage medium, making it significantly more useful than either know standard. For instance, it can be used for Video Mail across LAN/ WAN enterprise networks (as in Microsoft Mail, Lotus cc:Mail or Notes).

26. At 28.8 kbps, if VideoObjects will displaying 1/4 CIF at 8-12 fps at 8-bit resolution and 8 bit color, does this mean the VideoObjects algorithms are processing a full 320x240 bit stream, or a digitizer hardware reduced 160x120 or 80x60?

VideoObjects algorithms process the full bit stream any known digitizer is capable of processing. VideoObjects algorithms analyze and compress the bit stream to fit the 28.8 kbps data pipeline.

27. If H.26P (for PSTN applications- a "family" of the H.261 std.) uses 11.2 bits for video and 3.2 kbits for sound, what is VideoObjects projected to use for the video/ sound mix at 28.8 kbps??

a. Video bits = 19.8 kbps (if lines are "dirty" will simply drop frames).

b. Data/ Sound bits = 9.0 kbps.

28. How much of VideoObjects algorithm instruction mix is devoted to post and pre-processing of bit stream?

VideoObjects algorithms both pre- and post-process the video bit stream in a continuous manner which are not independent of one another, they are interdependent.

a. IF pre- & post-processing exists, does this vary on a scalable basis; meaning the larger bit stream gets better screen resolution? And, if it does exist, does an increase of CPU MIPS increase the resolution for a fixed bit stream?

Yes, the VideoObjects algorithms will vary resolution and frame rate on a scalable basis and more CPU MIPS increase the resolution for a given bit rate. See earlier discussion on this matter in Question #3. Furthermore, the algorithm designs for VideoObjects can be adapted for specific situations or requirements.

29. For current versions of VideoObjects algorithms, does the digitizer board pre-process the bit stream before VideoObjects algorithms begin processing the actual bit stream?

No. VideoObjects algorithms do all the processing of the bit steam. The Digitizer boards themselves are seen as the limitation on VideoObjects, not the other way around.

a. does the digitizer board automatically drop the bit stream from 764x576 to 325x256x16 bit before VideoObjects begins processing?

Yes, this can be done, but VideoObjects prefers to "see" the entire bit stream to get a more accurate color "read" and content "read" than what hardware reduced bit streams permit.

b. or, does VideoObjects process the initial 764x576 bit stream down to 163x128 (or whatever) for storage/ replay/ transmission?

Yes, VideoObjects processes the entire bit stream it "sees". The more it "sees" the better the resultant picture on replay.

c. does VideoObjects do all the compression from the full bit stream that ANY digitizer board can potentially process (like broadcast quality 30 fps with 2 field per frame at 764 x 576 x 24 bit color)?

Yes, see first answer.

d. what are the differences in digitizer board pre-processing, if any, between Acorn machine boards and PC/ Mac boards??

All boards vary tremendously in design and actual execution of the bit stream. VideoObjects only cares to "see" the bit stream as defined by the board and will act upon that element only. Only drivers need to be written for each digitizer board for VideoObjects to act upon a particular bit stream.

30. With the Motorola PowerPC or 100 mhz CPUs, or with the Intel 486dx2 or 486dx4 or Pentium 60 or 90 mhz CPUs presuming there's 20 MIPS available at all times in the clock/ instruction cycle, could VideoObjects utilized fully symmetric processing to show two-way video at 128 kbps on the same CPU?? This presumes some form of multi-point to multi-point video conferencing.

Yes, with relative ease. VideoObjects can already replay on the Acorn 5000 (ARM 3- 33 mhz) machine four sources at ISDN BRI 128 kbps rate. VideoObjects can also replay four or more source windows on the host CPU for the Intel 486 and Pentium as well as the Power PC.

Furthermore, the ability to display three incoming video streams as well as process (compress) one outgoing stream is entirely possible within the power of the 486dx2-66 or 100 mhz CPUs, any Pentium, or the Power PC 601 or 620 chips.

31. If VideoObjects uncompiled ANSI C code algorithms work under X-Windows compliant environments, does this imply that it can work under ANY Unix machine which can run an "X-Windows complaint" operating system?

Yes, VideoObjects has been written in standard ANSI C code and can effectively run on all of the following machines running under "X Windows" in Unix:

a. IBM RISC 6000 using PowerPCs with AUX.

b. HP Vectra 9000 or Apollo RISC machines with HP Unix.

c. Silicon Graphics MIPS workstations with X-Windows.

d. Sun SPARC with Solaris/ X-Windows.

e. Data General, Tandem Computer, Thinking Machines, that run any X-Window iteration.

f. any machine that runs "Linux", a version of Unix running "X" windows.

g. DEC Alpha AXP machines running any iteration of X-windows Unix.

h. Apple Power Pcs running Apple AUX (X-windows compliant).

i. NEC MIPS machines running Motif or X-Windows Unix.

32. What is HIGHEST quality playback resolution video (sound and video) which can be compressed onto a CD-ROM disk (i.e. understood it must be squeezed onto a 600 MB floptical and "pressed" at an outside publishing house) TODAY?

VideoObjects can be compressed to run better than MPEG1 at a resolution of 384 x 288 x 24 bpp at 30 fps. In other words, a very high quality video playback is achievable on the ARM 700 machine. By Q3 1995 this will be possible under the Windows VfW environment as well.

a. how many minutes of the highest quality video may be stored on a 600 MB CD-ROM?

Depends on the CD-ROM rate. As in the above, if a 600 MB capacity disk is running at its maximum display transfer rate of 150 KB per sec, this means you are limited to 72 minutes of video storage. If you run a 2x speed CD-ROM at 300 KB per sec, you are limited to half the above, or approximately 31 minutes of video storage. The alternative is to fine tune new VideoObjects algorithms to run around 85 KB per sec for an MPEG1 quality video of 384 x 288 x 16 bpp at 25 fps; meaning an entire movie can be stored on one side of a CD-ROM.

33. What is the anticipated size of a "multi-file format compatible playback engine" which can be stored on individual PCs so that any individual's PC can playback any file created by any version of VideoObjects at any resolution or data rate?

VideoObjects algorithm design is so efficient that a playback file size of approximately 100 K can be designed to incorporate playback routines for at least eight (8) playback files at the following "pipeline rates":

a. 28.8 analog video

b. 112 kbps IDSN2 video

c. 384 kbps (48 KB) ISDN6, ADSL video

d. 1.2 mbps (150 KB) CD-ROM video, T1 lines

e. 2.4 mbps (300 KB) ISDN30, 2x CD-ROM video

f. 10 Mbps (1,25 MB) Ethernet (Fast Ethernet = 100 Mbps)

g. 16 Mbps (2 MB) switched video on demand