|
Linden examines the strengths and weaknesses of the OpenCable Application Platform's Java interfaces.
July 01, 2004
URL:http://www.drdobbs.com/jvm/java-the-opencable-application-platform/184405724
<
Linden is Consultant Engineer at Pace Micro Technology Americas and the author of Core Java Media Framework (Prentice-Hall, 1999). He can be contacted at lindendmindspring.com.
The U.S. cable industry is making a massive investment in Java technology to escape the quagmire of proprietary network software and APIs. As I pointed out in "The OpenCable Application Platform" (DDJ, June 2004), Java is at the core of the standards-based, OpenCable Application Platform (OCAP). In fact, due to its heavy reliance on these Java APIs, OCAP's advocates claim that properly written OCAP applications can run on any OpenCable-compliant North American cable network. In this article, I examine the strengths and weaknesses of OCAP's Java interfaces to determine if they can fulfill OCAP's ambitious goals.
CableLabs, the research organization of U.S. cable companies, has taken the European Multimedia Home Platform (MHP) specification, added core features needed for the U.S. digital cable market, and labeled it OCAP (at the time of writing, the OCAP specification is at Version 10; see http://www.opencable.com/specifications/). Both MHP and OCAP expose traditional Java interfaces such as Java Multimedia Framework (JMF) for multimedia, Advanced Windowing Toolkit (AWT) for graphics, and JavaTV for digital video. Although these interfaces are familiar to most Java programmers, they are not the identical version you'll find on a PC or Mac. Rather, they have been tweaked for optimal performance for embedded environments (that is, the OCAP architects jettisoned portions of the API that are impractical for machines with limited memory and processing resources).
MHP and OCAP also provide unique enhancements for their particular digital television environments. For instance, MHP offers a Java input/output subsystem to retrieve files from a broadcast carousel. Carousels are popular in Digital Television (DTV) environments since they let service providers cram a filesystem into an existing MPEG-2 digital video stream. This technique is referred to as "in-band" since data is transmitted within existing multimedia streams. By contrast, "out-of-band" filesystems don't reuse the broadcast video stream and are meant exclusively for data. Carousels are popular in cable environments because in-band transfers offer the widest and fastest communication pipe to your cable set-top box (Figure 1).
Unfortunately, there are side effects to reusing a portion of the content stream for file I/O. As the name implies, a filesystem carousel is constantly looping (the duration of the loop is controlled by the server). These loops are required because the file server doesn't communicate directly with the client application. Rather, the data is repeatedly broadcast to all clients since the server never knows when a client has completed the read request. Consequently, carousels are useful for broadcasting information to many clients, but if you need a bidirectional communication path to a server (say, TCP/IP), an out-of-band technique must be used.
Like a TCP/IP stack, a carousel is composed of layers (Figure 3). The lowest layer consists of an MPEG-2 stream. Above the MPEG-2 stream are Digital Storage Media for Command and Control (DSM-CC) sections (DSM-CC defines a standardized mechanism to transport data in MPEG-2 content). A higher layer DSMCC protocol organizes these sections into a data carousel. Finally, the highest item in the stack groups the data into objects (or an object carousel).
Unlike a conventional reliable filesystem, it often takes multiple read attempts to obtain the requested data when using a carousel. To explain, parts of the file are typically sprinkled throughout the carousel and you may need to wait for the carousel to loop around to obtain the missing portion (see Figures 1 and 2). Furthermore, even when you reach the appropriate carousel location, the read may fail due to Cyclic Redundancy Check (CRC) issues and the data must be reread until the correct information is obtained (MPEG-2 data streams aren't guaranteed and may arrive out of order or contain errors).
Fortunately, the DSMCCObject class shields you from the tedious work necessary to assemble a file from the object carousel by extending the java.io.File interface. For example, Listing One shows how you can open a bitmap and read a carousel file as if it were a traditional file. However, for optimal multithreaded performance, you will want to exploit the asynchronous carousel extensions found in DSMCCObject (Listing Two).
Listing Two shows you how to exploit the asynchronous capabilities of the DSMCCObject to notify your application when the carousel I/O is complete, rather than the blocking approach used in Listing One.
OCAP retains core MHP Java classes such as DSMCCObject and enhances them with interfaces that are specific to the North American Cable environment. Three of the most important of these new functional areas are: Monitor, Hardware, and CableCARD.
The Monitor is a special application that controls access to machine and network resources and also resolves resource conflicts between applications (see "The OpenCable Application Platform," DDJ, June 2004, for more on the Monitor application). To fulfill its responsibilities, the monitor should implement the ResourceContentionHandler interface (Listing Three).
ResourceContentionHandler has one method (resolveResourceContention) and this method is called by the OCAP middleware when a resource fight erupts between applications. Since every monitor application is MSO-specific, resolveResourceContention() uniquely decides how conflicts will be resolved on that particular network.
The monitor application alerts the OCAP middleware that is interested in arbitrating resource conflicts by invoking the setResourceContentionHandler(ResourceContentionHandler) method of org.ocap.resource.ResourceContentionManager class. Be aware that the ResourceContentionManager is picky if you don't have the appropriate permission; it will throw a java.lang.SecurityException exception.
If the monitor app is hacked, it could cripple the entire network infrastructure since it has roughly the authority of a UNIX root account. Consequently, the OCAP middleware provides a multilayered security approach to reduce risk. To explain, OCAP divides monitor functionality into several different categories and enforces different permission attributes for each category (Table 1). This has two benefits:
The cable provider alerts the OCAP middleware that it should load an OCAP-J application either by the in-band Application Information Table (AIT) or the out-of-band Extended Application Information Table (XAIT); again, see "The OpenCable Application Platform" for details on AIT and XAIT. These tables contain the permissions that the cable provider has explicitly defined for each application. Typically, only the monitor application (which is loaded at boot time) is granted any of these permissions. However, Multiple Service Operators (or MSOs—another name for a cable company) do have the option of installing applications with some or all of the monitor permissions.
The monitor is responsible for enforcing MSO-specific behavior. For instance, since most digital copy control standards are immature (see my article "HDTV & Broadcast Flags," DDJ, November 2003), each cable company often formulates its own copy protection strategy. In an OCAP environment, monitor applications can manipulate Copy Control settings with the org.ocap.hardware.CopyControl class.
By default, OCAP devices don't enforce copy protection unless the Copy Control Information (CCI) embedded in the MPEG-2 data stream requests that the content be protected. For example, the CCI setting may prevent content from being copied on a digital interface or require that the video output of component video outputs be constrained (constraining decreases the resolution of the picture from an HDTV resolution to a standard definition-type resolution).
Because the monitor application is all-powerful, it can overrule the current CCI setting and implement the MSO-specific policy (clearly another reason why monitor permissions must be so closely guarded by the OCAP middleware). For instance, the setDownRes() method of org.ocap.hardware.CopyControl can be used to force component outputs to be constrained (Listing Four), even if the CCI setting doesn't mandate it.
In addition, monitor class applications can obtain the current CCI settings for the content via the org.ocap.hardware.CopyControl.getCCIBits() method and alter (or override) the current settings via the org.ocap.hardware.CopyControl.setCCIBits() method (Listing Five). The first parameter of setCCIBits() is a Boolean. If it is True, then the CCI bits parameter will be used to override the CCI bits in the stream. If False, then the OCAP middleware should dump the CCI bits and rely on the CCI settings embedded in the content stream.
OCAP-specific hardware extensions are located in the org.ocap.hardware package and enable features that are unique to the OpenCable environment. For instance, the org.ocap.hardware.VideoOutputPort class is the logical representation of either a digital or analog video output interface (DVI, HDMI, component video, or the like).
Since an OCAP device typically has multiple video output ports, you must use the org.ocap.hardware.host.getVideoOutputPorts() method to retrieve a list of valid video output devices (Listing Six). Once this list is obtained, you can determine the type of each output by calling the VideoOutputPort's getType() method (Table 2).
The most interesting ports are the digital VideoOutputPorts (for instance, DVI and 1394) because they are programmable. If the port type is AV_OUTPUT_PORT_TYPE_DVI, then you can query if the port supports HDCP via VideoOutputPort.queryCapability(CAPABILITY_TYPE_HDCP). If the port isn't HDCP enabled, the monitor app has the option of disabling it with VideoOutputPort.disable() to minimize the risk of piracy (see my article "Digital, Analog, and High-Definition TV," DDJ, November 2002 for more information on HDCP). Similarly, if it is HDCP enabled, the video output can be activated via VideoOutputPort.enable() (the display will be dark until you make this call).
A DVI bus is strictly limited to a single transmitter (for instance, cable set-top) and a single receiver (or display device). Therefore, as soon as the DVI display is connected to the set-top, the OCAP middleware configures the DVI connection to communicate with that specific monitor. By contrast, the 1394 bus can contain a plethora of recording and display devices (again, see "Digital, Analog, and High-Definition TV" for information on 1394) and there is no default display. Therefore, if the VideoOutputPort is AV_OUTPUT_PORT_TYPE_1394, then you need to find and manually select the 1394 device where the set-top box should stream its video output.
The first step in this process is to discover the available devices on the 1394 bus via VideoOutputPort.getIEEE1394Node() (Listing Seven). Then you must walk through the list until you find a valid output device such as a DVHS or a 1394 display (the OCAP 1.0 specification only supports streaming content to output devices and doesn't address incoming streams from cameras and so on).
Once you've selected the target device, you use the VideoOutputPort.selectIEEE1394Sink() method to make a logical connection to the destination device. To transform this logical connection into a physical stream between the set-top box and sink device, you must enable the VideoOutputPort with VideoOutputPort.enable() (the same method that is used to enable the DVI output port). If you forget this step, you could spend many frustrating hours trying to debug why nothing appears on your 1394 display.
OpenCable devices are required to process unencrypted content without the aid of additional hardware devices (typically, analog channels broadcasting local content aren't encrypted). By contrast, virtually all cable providers encrypt digital channels and premium content with conditional access technology such as PowerKEY or DigiCipher (see "The OpenCable Application Platform," DDJ, June 2004, for information on Conditional Access).
Monitor-class OCAP-J applications manipulate conditional access and other network-specific features via the org.ocap.hardware.pod package found in CableCARD devices. Newcomers to OCAP usually wonder why CableLabs sometimes refers to the device as a Point of Deployment (POD) and other times as a CableCARD. Yet, a careful examination of the problem reveals that older documents refer to CableCARDs as POD devices, whereas all new publications exclusively use the CableCARD nomenclature to describe these devices (a CableCARD is an implementation of a POD). Unfortunately, the one exception to this rule is the actual OCAP API. CableLabs continues to use the POD terminology in its APIs.
To access the POD API, you first obtain an instance of the POD via OcapSystem.getHost().getPOD(). Given this instance, you can query the POD about its capabilities. For instance, you can use getHostParam() to retrieve the current setting of an attribute and update the value with updateHostParam() (Listing Eight).
However, the most intriguing features of a POD revolve around conditional access. Each POD may contain applications to enable decryption of encrypted content, manipulate pay-per-view (PPV) attributes, and provide infrastructure for video-on-demand sessions. You can get a list of PODApplication objects by calling the POD.getApplications() method (Listing Nine). PODApplications are divided into the functional types: conditional access, out-of-band communication, diagnostic, Internet protocol related, and uncategorized (that is, anything that falls outside the previous four categories). POD.getType() determines the type of the current PODApplication and I'll use it to search for conditional access applications.
Unfortunately, OCAP doesn't provide a network-independent means of communicating with conditional access-related CableCARD applications. As a result, you must create a specific application session (SAS) tunnel between your OCAP-J application and the application running on the CableCARD (this tunnel represents a secure communication path between your OCAP-J app and the app running on the CableCARD).
To establish this tunnel, your application must be authorized with monitor "podApplication" permission. If you're authorized, you call the SystemModuleRegistrar.openSpecificApplicationSession() method. Otherwise, the OCAP stack will throw a java.lang.SecurityException exception at you. Once the SAS tunnel has been created, you can use SystemModuleHandler.send() to transmit messages to the POD and SystemModuleHandler.receive() to obtain responses from the POD.
Because the interface between the two applications is proprietary, there is no standardized API per se. Rather, you communicate with the POD via binary data structures (for details on the format of typical POD data structures, see the Society of Cable and Telecommunication Engineers 28, http://www.scte.org/documents/pdf/ ANSISCTE282003DVS295.pdf). Besides being more susceptible to errors (for instance, you lose type-safety checking by using binary data structures instead of Java APIs), this technique tightly couples your OCAP-J app with the CA technology on specific networks and, as a result, will only work on a subset of potential OCAP boxes. Given the proprietary nature of CA technologies, software vendors will have to create different flavors of their OCAP-J applications if they require low-level access to CA functionality (the typical OCAP-J applications won't need to do this). Consequently, one of the critical design goals of cable application portability remains only partially fulfilled.
While OCAP offers unique Java classes and interfaces to control CableCARD, DVI, and 1394 other hardware devices, it also adapts traditional Java interfaces to the cable environment. For instance, the org.ocap.media.ClosedCaptioningControl interface has been added to JMF players so that you can control captions in digital content streams.
Most people assume that captions are only useful for the hearing impaired. While this is an important use of captions, there are many other uses of this technology. For instance, they can be used as subtitles in foreign films or add to the mood of a presentation.
To enable captions, you call setClosedCaptioning(true); to disable captions, you invoke setClosedCaptioning(false). Because captions may change dynamically, it is a good idea to register a listener with the addClosedCaptioningListener() method and monitor events that could affect your presentation. For instance, if captions are no longer in the stream, then you receive the EVENTID_CLOSED_CAPTIONING_UNAVAILABLE event. This can happen on live content when equipment malfunctions or the provider fails to provide caption service. Fortunately, due to FCC requirements, captions must be reactivated and, when this occurs, your listener receives an EVENTID_CLOSED_CAPTIONING_AVAILABLE event.
OCAP builds on Java interfaces such as JMF and JavaTV and enhances them with classes and interfaces unique to the North American cable market. If your application has the appropriate permission, you can use the monitor APIs to manipulate resources and control how copy protection is performed. Additionally, you can manipulate digital video output devices on DVI and 1394 buses and control conditional access features of a CableCARD. Although the CableCARD application APIs aren't open, OCAP is clearly a quantum leap forward for Java developers that are interested in writing portable applications for the cable market.
DDJ
import org.ocap.net.*;
import java.io.*;
import org.dvb.dsmcc.*;
import org.davic.net.*;
public class Listing1
{
public static void main (String [] args )
{
// create the carousel object
ServiceDomain carousel = new ServiceDomain();
// next, create a Locator that refers to the service
// that contains our carousel
// NOTE: you need to use an OCAP locator and not the dvb locator.
// ********************************
org.ocap.net.OcapLocator ocapLocator;
// attach the locator to the carousel so it knows where to pull data
try
{
ocapLocator = new org.ocap.net.OcapLocator("ocap://10.0.0.1");
carousel.attach(ocapLocator, 1);
// create the DSMCC object.
// we're using the theoretical drdobbs directory
DSMCCObject dsmccObj;
dsmccObj = new DSMCCObject(carousel.getMountPoint(),
"drdobbs/blocking.txt");
// next step, create a FileInputStream object from the carousel
try
{
FileInputStream inputStream;
// and read the file into our buffer. note: this will block
// the read thread until the read completes.
byte [] dataFile = new byte[2048];
inputStream = new FileInputStream(dsmccObj);
// read the first 2k of the file.
inputStream.read( dataFile );
}
catch (IOException ioProblem )
{
// error handling goes here....carousel reads can and
// do fail occasionally so don't forget to
System.out.println("Carousel read error occurred " );
}
}
catch (IOException ioProblem )
{
System.out.println("IO issues" );
}
catch (InvalidLocatorException badLocator)
{
System.out.println("locator isn't valid " );
}
}
}
Back to articleimport org.ocap.net.*;
import java.io.*;
import org.dvb.dsmcc.*;
import org.davic.net.*;
import java.util.*;
public class Listing2
{
public class TestHandler implements AsynchronousLoadingEventListener
{
public void receiveEvent(AsynchronousLoadingEvent e)
{
}
}
public static TestHandler asyncHandler;
public static void main (String [] args )
{
// create the carousel object
ServiceDomain carousel = new ServiceDomain();
// now create a Locator that refers to the service
// that contains our carousel
// ********************************
try
{
org.ocap.net.OcapLocator ocapLocator;
ocapLocator = new org.ocap.net.OcapLocator("ocap://10.0.0.1");
// attach the locator to the carousel so it knows where to pull data
carousel.attach(ocapLocator, 1);
// create the DSMCC object.
// we're using the theoretical drdobbs directory
DSMCCObject dsmccObj;
dsmccObj=new DSMCCObject(carousel.getMountPoint(),"drdobbs/async.txt");
// unlike the previous sample, we have have the carousel load
// the object asynchronously and notify our carouselListener
// implementation when it is ready.
// key part is this...the thread isn't blocked at this point.
dsmccObj.asynchronousLoad(asyncHandler);
}
catch (IOException ioProblem )
{
System.out.println("IO issues" );
}
catch (InvalidLocatorException badLocator)
System.out.println("locator isn't valid " );
}
}
}
Back to articleimport org.dvb.application.*;
import org.ocap.application.*;
import org.ocap.resource.*;
public class Listing3
extends AppsDatabaseFilter
implements ResourceContentionHandler
{
private static final int KNOWN_HACKER = 0xBADD;
private static final int VOD_APP = 0xFACE;
// bare bones class that installs a resource conflict handler.
public Listing3()
{
super();
ResourceContentionManager rcManager =
ResourceContentionManager.getInstance();
// tells OCAP that we want to be approve application launching.
rcManager.setResourceFilter(this,
"org.davic.mpeg.sections.SectionFilterGroup");
// and this tells OCAP stack where to call if/when a conflict occurs.
rcManager.setResourceContentionHandler(this);
}
// here's where we do the dirty work of resolving resource contentions....
// this is a VERY primitive handler simply for illustration purposes.
public AppID[] resolveResourceContention( AppID requester, AppID owners[],
java.lang.String resourceProxy)
{
AppID result[] = new AppID[owners.length + 1];
if(resourceProxy.equals("org.davic.mpeg.sections.SectionFilterGroup"))
{
// VOD apps have the highest priority
if(requester.getOID() == VOD_APP)
{
result[0] = requester;
for(int loop=0; loop < owners.length; loop++)
{
result[loop+1] = owners[loop];
}
}
else
{
// every other request is simply a FIFO
for(int loop=0; loop<owners.length; loop++)
{
result[loop] = owners[loop];
}
result[owners.length] = requester;
}
}
return(result);
}
// very primitive check to prevent hacker app from being launched.
public boolean accept(AppID appid)
{
boolean bAnswer = true;
if(appid.getOID() == KNOWN_HACKER)
{
bAnswer = false;
}
return(bAnswer);
}
}
Back to articleimport org.ocap.hardware.*;
public class Listing4
{
public static void main (String [] args )
{
boolean bConstrainVideo = true;
try
{
// this call will constrain ALL outputs, not just the
// component video output use with caution!!!
org.ocap.hardware.CopyControl.setDownRes(bConstrainVideo);
}
catch (java.lang.SecurityException securityExcept)
{
// you will get this exception if you don't have the monitor
//app permission "setDownRes"
System.out.println("you don't have monitor
app permission: setDownRes " );
}
}
}
Back to articleimport org.ocap.hardware.pod.*;
public class Listing5
{
public static void main (String [] args )
{
int cciBits = 0;
// figure out what the current CCI settings is for the stream......
cciBits = org.ocap.hardware.CopyControl.getCCIBits();
System.out.println("CCI bits are: " + cciBits );
}
}
Back to articleimport org.ocap.hardware.*;
import java.lang.*;
import java.util.*;
public class Listing6
{
public static void main (String [] args )
{
Host settopBox;
VideoOutputPort videoOutput;
settopBox = org.ocap.hardware.Host.getInstance();
Enumeration videooutputPorts = settopBox.getVideoOutputPorts();
// this is a very simple list walker
while ( videooutputPorts.hasMoreElements() )
{
videoOutput = (VideoOutputPort)videooutputPorts.nextElement();
if (videoOutput.getType() == VideoOutputPort.AV_OUTPUT_PORT_TYPE_DVI)
{
System.out.println("This is a DVI port!");
if ( videoOutput.queryCapability
(VideoOutputPort.CAPABILITY_TYPE_HDCP) == Boolean.TRUE )
{
System.out.println("This video port offers HDCP security!");
}
}
else if ( videoOutput.getType() ==
VideoOutputPort.AV_OUTPUT_PORT_TYPE_COMPONENT_VIDEO )
{
System.out.println("This is an analog copmonent video port!");
}
}
}
}
Back to articleimport org.ocap.hardware.*;
import java.lang.*;
import java.util.*;
public class
{
public static void main (String [] args )
Host settopBox;
org.ocap.hardware.VideoOutputPort videoOutput;
settopBox = org.ocap.hardware.Host.getInstance();
Enumeration videooutputPorts = settopBox.getVideoOutputPorts();
// this is a very simple list walker
while ( videooutputPorts.hasMoreElements() )
{
videoOutput = (VideoOutputPort)videooutputPorts.nextElement();
if ( videoOutput.getType() ==
VideoOutputPort.AV_OUTPUT_PORT_TYPE_1394 )
{
System.out.println("This is a 1394 port!");
org.ocap.hardware.IEEE1394Node[] firewireNodes =
videoOutput.getIEEE1394Node();
for (int loop = 0; loop < firewireNodes.length; loop++ )
{
// first node is the OCAP stack in the set-top box ignore it.
if ( loop == 0 )
{
}
else
{
// for this sample, grab and use the first valid port
try
{
short[] subunits = firewireNodes[ loop].getSubunitType();
// tell OCAP stack to use this device for video output
videoOutput.selectIEEE1394Sink(firewireNodes
[ loop].getEUI64(), subunits[0] );
// if everything ok, break out of the loop, given that
// we successfully set up the video output.
break;
}
catch(SecurityException SecurityException )
{
System.out.println("You don't have the
right permission (setVideoPort)");
}
}
}
}
}
}
}
Back to articleimport org.ocap.hardware.pod.*;
public class Listing8
{
public static void main (String [] args )
{
// this information can be found in the HOST-POD interface
// specification (SCTE 28)
int parentPIN = 2;
// it gets hairy talking with a CableCARD given that all the parameters
// are datastructures, but in this case, the first field is the length
// and the second field is the value.
byte[] parentalPin = {0X1, 0X7F};
byte[] value = pod.getHostParam(parentPIN);
}
}
Back to articleimport org.ocap.hardware.pod.*;
public class Listing9
{
public static void main (String [] args )
{
POD cableCARD = POD.getInstance();
PODApplication[] apps = cableCARD.getApplications();
for ( int i = 0; i < apps.length; i++ )
{
System.out.println("Application name is: " + apps[i].getName());
// is this a conditional access application????
if (apps[i].getType() == PODApplication.TYPE_CA )
{
// yep! We found our target app, so break out of the loop
System.out.println("Found a conditional access application"
+ apps[i].getName() );
break;
}
}
}
}
Back to article
| Monitor Permission | Explanation |
| registrar | Application permitted to add/remove other applications from the OCAP database. |
| service | Application permitted to modify its service contexts. |
| servicemanager | Application permitted to create its own service context. |
| security | Application can determine the permissions of other applications. |
| reboot | Application can reboot the box. |
| systemevent | Causes monitor application to be affected by actions such as a reboot. |
| handler.appFilter | Application can control if the OCAP middleware will load broadcast applications. |
| handler.resource | Permits an application to resolve resource conflicts. |
| handler.closedCaptioning | Application can display closed captions. |
| filterUserEvents | Application can filter incoming user events. |
| handler.podResource | Application can access the CableCARD. |
| handler.eas | Application can process Emergency Alert Messages. |
| setCCIBits | Application can change the copy control processing of the CableCARD. |
| setDownRes | Application can constrain video output on the VideoOutputPort. |
| setVideoPort | Application can manipulate digital video output ports such as DVI and HDMI and analog interfaces such as component video output. |
| podApplication | Application can create SAS tunnels and communicate with applications running on the CableCARD. |
| signal.configured | Application can call monitorConfiguredSignal(). |
| properties | Application permitted to read OCAP system properties. |
| Port Type | Description |
| AV_OUTPUT_PORT_TYPE_1394 | Video output port is a 1394 (Firewire) connector. |
| AV_OUTPUT_PORT_TYPE_BB | Video output port is an analog Baseband (or RCA jack) connector. |
| AV_OUTPUT_PORT_TYPE_COMPONENT_VIDEO | Video output port is an analog component video (YpbPr) connector. |
| AV_OUTPUT_PORT_TYPE_DVI | Video output port is a DVI (or HDMI) connector. |
| AV_OUTPUT_PORT_TYPE_RF | Video output port is an analog RF connector. |
| AV_OUTPUT_PORT_TYPE_SVIDEO | Video output port is an analog S-Video connector. |
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.