[Videomgmt] Bob Ray's Simple MIB Proposal

["Larry R. Walsh" <[e-mail]>]

... sounds very good to me.

Others?

Larry Walsh


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, October 19, 2005 9:17 AM
> To: [e-mail]
> Subject: Videomgmt Digest, Vol 2, Issue 3
> 
> 
> Send Videomgmt mailing list submissions to
> 	[e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/videomgmt
> or, via email, send a message with subject or body 'help' to
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of Videomgmt digest..."
> 
> 
> Today's Topics:
> 
>    1. A simple proposal (Ray, Robert)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 19 Oct 2005 09:19:19 -0500
> From: "Ray, Robert" <[e-mail]>
> Subject: [Videomgmt] A simple proposal
> To: <[e-mail]>
> Message-ID:
> 	<[e-mail]>
> Content-Type: text/plain;	charset="us-ascii"
> 
> I thought I'd follow up on Larry's email about keeping things 
> simple. At the very heart of this industry seems to be two 
> elements: inputs and outputs.  The sole universal operation 
> is to connect an input to an output (a "take").
> 
> For some of the industry, the operation needs to be performed 
> in concert with a very specific event, the vertical interval, 
> specified via a timecode (hours, minutes, seconds, frame #).  
> For others, the operation needs to be performed based upon 
> some external, non-time-based, event. For many, the operation 
> simply needs to be performed as soon as possible. 
> 
> Additionally, for most of the industry, the operation needs 
> to be performed on several inputs and several outputs simultaneously.
> 
> Examples:
> 
> 1.  In a composite video router, an input can be connected to 
> zero or more outputs.
> 
> 2.  In an RGB video router, a collection of inputs needs to 
> be connected to a similar collection of outputs; red input to 
> red output, green input to green output, etc.
> 
> 3.  In a KVM switch, three inputs must be simultaneously 
> switched to three outputs.  A keyboard input must be 
> connected to a keyboard output, a video input must be 
> connected to a video output, a mouse input must be connected 
> to a mouse output.
> 
> 4.  An audio processor may include audio mixing capabilities, 
> where more than one input is connected to an one output (or 
> more than one output).
> 
> 
> 5.  A video processor may provide mixing of video inputs to 
> provide an output.  For example, keys, wipes, and fades.
> 
> 6.  All of the above might be controlled via automation 
> equipment, perhaps an audio router than switches to a 
> 
> Each of the elements (inputs, outputs) can have 
> characteristics which are highly dependent upon the nature of 
> the element.  An input may be an audio signal, it may be an 
> analog video signal, it may be a serial signal (i.e. mouse 
> movement or an RS-422 port), it may 5.1 digital audio signal, etc.  
> 
> Abstract groupings of these elements may have characteristics 
> which are distinct from the individual elements.  For 
> example, combining several audio inputs and video inputs to 
> produce an output signal (say, down-conversion of HD video + 
> 6 channel digital audio signal for output on an analog 
> monitor) would have characteristics that differ from a KVM 
> group (keyboard 1, video 1, mouse 1).
> 
> Attempting to provide a MIB which is all things to all of 
> these different would certainly consume a lot of time, 
> produce a very complex document, and would never be implemented.  
> 
> However, having a collection of MIBs which as a whole 
> accomplish the same thing would seem far easier (as long as 
> they are developed cohesively).  Viewed as objects (OO), a 
> base class would be inputs and outputs with a method to 
> associate the two.  A derived class would overide the method 
> to perform the method based upon some external event (i.e. a 
> timecode).  Other derived classes would augment the base 
> object with characterics specific to the signal (clock, 
> encoding, etc.). Another class would provide groupings (e.g., 
> inputGroups, outputGroups) and a method of associating the groups.
> 
> To summarize: at the most basic level, we need 
> 
> 1) inputs
> 2) outputs
> 3) a method to connect the two
> 
> The ability to retrieve the current connections would seem 
> appropriate for this class although this becomes murky when 
> one considers the difference between one-to-one (simple 
> switch), many-to-one (simple mixer), one-to-many 
> (distribution router), or many-to-many.  It may be best to 
> place this capability into a derived class.
> 
> The single characteristic that may be appropriate at this 
> level (considering the widely varying nature of the inputs 
> and outputs) is signal presence.  
> 
> The ability to generate notifications when an input is connected (or
> disconnected) from an output would seem appropriate for this 
> class.  If so, however, the ability to control, throttle, or 
> disable the generation of this notification would seem 
> necessary, especially if a user is more interested in the 
> occurrence of operations between complex groupings. 
> Similarly, a notification indicating change in signal 
> presence at an input or output would seem appropriate for this class.
> 
> Thoughts?
> 
> I will convert the above stream into a simple MIB for futher 
> discussion if anyone is interested.  Larry?  Others?
> 
> Regards,
> Bob Ray
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Videomgmt mailing list
> [e-mail] https://www1.ietf.org/mailman/listinfo/videomgmt
> 
> 
> End of Videomgmt Digest, Vol 2, Issue 3
> ***************************************
> 


_______________________________________________
Videomgmt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/videomgmt