Audio Video Streams Avatar
  1. OMG Specification

Audio Video Streams — Open Issues

  • Acronym: AVSTR
  • Issues Count: 20
  • Description: Issues not resolved
Open Closed All
Issues not resolved

Issues Descriptions

Timestamp format used in SFP is not adequate (AV streams issue)

  • Key: AVSTR-21
  • Legacy Issue Number: 1114
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The timestamp format used in SFP is not adequate for many applications
    particularly non-linear editing and post-production systems. These systems
    require a more comprehensive timestamping format. Furthermore, the current
    timestamp, expressed in microseconds wraps around too quickly. This needs
    to be addressed without loss of precision.

  • Reported: AVSTR 1.0b1 — Fri, 27 Mar 1998 05:00 GMT
  • Updated: Wed, 11 Mar 2015 23:32 GMT

C&M ofAudio/Video Streams

  • Key: AVSTR-19
  • Legacy Issue Number: 2969
  • Status: open  
  • Source: Anonymous
  • Summary:

    I am going to implement OMG Control and Management of Audio/Video Streams
    specification. We used IONA's implementation: Orbix MediaStreams but we
    are not fully satisfied with it.
    I have some questions:
    1. StreamCtrl has a 'Status' property which is 'seqflowStatus' - probably
    sequence of flowStatus structures. But there is no such typedef in the IDL
    specification.
    2. StreamCtrl has alse A_parties and B_parties sequences. The same
    problem.

  • Reported: AVSTR 1.0 — Tue, 5 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

RTCP!

  • Key: AVSTR-18
  • Legacy Issue Number: 2833
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The AVStreams flow specification allows the flows to use RTP
    for their transport. The RTP spec requires that all RTP participants
    send RTCP information. For eg. without the RTCP CNAME packet other RTP
    receivers cannot do synchronization between 2 flows.

    RTP and RTCP need 2 different channels ie. 2 different endpoints. The
    flow specification provides a means of specifiying the RTP endpoint
    but no standard way of specifying the RTCP endpoint.

  • Reported: AVSTR 1.0 — Thu, 5 Aug 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Case-only difference in SFP IDL for enum MsgType {Credit} and struct credi

  • Key: AVSTR-17
  • Legacy Issue Number: 2556
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: n sfp.idl there"s a case-only difference for the Credit MsgType
    enumerator and the struct credit.

    Also it would be convenient to have an enumerator for the struct fragment
    message, so that its easier to switch code based on the MsgType set
    depending on the magic_number.

  • Reported: AVSTR 1.0 — Mon, 29 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

telecom/98-10-05, IDL spec of SFP v1.0

  • Key: AVSTR-16
  • Legacy Issue Number: 2117
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: the definition of struct fragment of module flowProtocol implies
    a waste of 4 bytes

  • Reported: AVSTR 1.0 — Wed, 21 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

stream controllers and endpoints in browser-type scenario needed

  • Key: AVSTR-13
  • Legacy Issue Number: 2062
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: This is related to the need to put stream controllers and
    endpoints in a browser-type sceanario. In this scenario the
    StreamEndPoint_A in the browser calls request_connection() on
    StreamEndPoint_B on the server. Because the StreamEndPoint_B
    is behind the firewall it must provide for all of the listen
    addresses of flows and must also provide the information about
    their direction and format. The StreamEndPoint_A in the browser
    can then decide which of the flows it can connect to based on name
    or directionality and format.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Wrong IDL for SFP

  • Key: AVSTR-14
  • Legacy Issue Number: 2115
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In document number telecom/98-10-05,
    IDL spec of SFP v1.0,
    in module flowProtocol is an enum-value Start and a struct Start
    defined. This is not allowed.
    Same for enum-value StartReply / struct StartReply.
    etc.

    Proposed Solution:

    Rename enum values of enum MsgType.

  • Reported: AVSTR 1.0 — Wed, 21 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

frameID of struct specialFrame in module flowProtocol not defined

  • Key: AVSTR-15
  • Legacy Issue Number: 2116
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In document number telecom/98-10-05,
    IDL spec of SFP v1.0, the type frameID in the definition of struct
    specialFrame
    is not defined.

    Proposed Solution:
    add
    typedef unsigned long frameID;
    to the module flowProtocol.

  • Reported: AVSTR 1.0 — Wed, 21 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

UDP Issue

  • Key: AVSTR-11
  • Legacy Issue Number: 2059
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In order to work reliably over UDP, SFP needs magic numbers to
    distinguish Credit and StartReply messages. Also, to work properly
    over UDP, the fragment header must have a sequence number field
    to associate it with its correct Frame. This is because transports
    like UDP could potentially interleave fragments from different frames.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

There is a bug in the state transition diagram for SFP

  • Key: AVSTR-9
  • Legacy Issue Number: 2057
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: There is a bug in the state transition diagram for SFP which could
    cause potential problems when it is used with UDP/IP.
    If we timeout (T1) on receiving a data frame, we should send a
    Credit message back to the producer. This prevents a situation where
    a whole Frame or Frames have been dropped but the sender times out on
    waiting for a credit message that will never arrive. The state transition
    diagram needs to be updated to take this into account.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

SFP frameHeader should always be treated implicitly as fragment 0

  • Key: AVSTR-10
  • Legacy Issue Number: 2058
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: It is not mentioned anywhere in the specification that the
    SFP frameHeader should always be treated implicitly as fragment 0.
    Subsequent values of the frag_number field will be 1, 2, 3, etc.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Description of connect() and request_connection(), stop(), start(), and de

  • Key: AVSTR-8
  • Legacy Issue Number: 2056
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In the description of the connect() and request_connection(), stop(),
    start() and destroy(), for point-to-point streams there is a bias
    towards always viewing the StreamEndPoint_A as the ‘initiator’ and
    StreamEndPoint_B as the ‘responder’. In fact the B party can equally
    be used as an initiator and an A party as the responder. This point
    needs to be emphasised by the text.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Description of Behaviour of the modify_QoS() operation

  • Key: AVSTR-12
  • Legacy Issue Number: 2061
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Section 2.2.11 describes the behaviour of the modify_QoS() operation.
    This behavioural description is flawed and should be replaced with
    more sensible semantics. When modify_QoS() is called on the
    StreamCtrl for a point-to-point stream it ahould call modify_QoS() on
    both A and B stream endpoints and both sides should adjust QoS only for
    flows which originate on their own side.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Flow naming issue

  • Key: AVSTR-7
  • Legacy Issue Number: 2055
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The A/V Streams light profile uses strings to name flow endpoints
    with respect to their corresponding StreamEndPoint/VDev. In some
    systems a flow endpoint in one stream endpoint corresponds to a
    differently named flow endpoint in another stream endpoint. When a
    stream is set up between these stream endpoints, the request_connection()
    and set_format() operations carry enough information
    (in terms of directionality and format) to allow the implementation to
    map the flow endpoint in the requesting StreamEndPoint/VDev to its
    corresponding flow endpoint in the local StreamEndPoint/VDev. This point
    and others related to flow naming issues need to be made more explicit in
    the text of the specification.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

The "the_QoS" parameter parameter is not properly explained

  • Key: AVSTR-6
  • Legacy Issue Number: 2054
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: he ‘the_QoS’ parameter plays a very important role the bind() and
    bind_devs() calls however its function is not properly explained by
    the text which describes bind() and bind_devs(). In particular, thee
    nature of the values following a call which managed to connect some
    but not all of the flows with the desired QoS.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Full profile issue

  • Key: AVSTR-5
  • Legacy Issue Number: 2053
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Probably the most serious problem for the specification is in the
    ‘full profile’. The model erroneously constrains the FlowProducer
    to always perform the transport connect() call while the FlowConsumer
    is the party which always calls transport listen(). Tying the
    connect()/listen() roles to the producer/consumer roles creates a
    problem with firewalls. With a firewall, the connection must always
    be accepted on the firewall machine. This is impossible, however
    if the FlowProducer is behind the firewall since there is no listen()
    operation in the FlowProducer IDL. There is a possible resolution to
    this problem which would be backward compatible for implementations
    which use the old IDL.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

StreamCtrl

  • Key: AVSTR-2
  • Legacy Issue Number: 2048
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The StreamCtrl can be used to create a stream between two or more
    endpoints by calling the bind_devs() operation with the
    MMDevices to be bound as parameters. During the course of the
    binding process, each MMDevice acts as a factory creating a VDev and
    a StreamEndPoint. The application programmer who called bind_devs()
    may want to query the resulting StreamEndPoints or VDevs, however
    there is no easy way to obtain a reference to these objects since
    they are not returned by the bind_devs() call.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

connect_leaf() operation

  • Key: AVSTR-4
  • Legacy Issue Number: 2052
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The connect_leaf() operation throws an exception if it is unable to use
    ATM-style multipoint transport connections. Using the current scheme,
    this happens, in principle, only when the first B party is bound into
    the multiparty stream. It would be very useful if the StreamCtrl could first
    test for the use of ATM-style multipoint by passing a nil object
    reference for the ‘the_ep’ parameter in the call to connect_leaf().
    It also leads to better semantics for binding the A party into the
    multiparty stream.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

Change term Multicast to Multipoint

  • Key: AVSTR-3
  • Legacy Issue Number: 2049
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In various parts of the spec, the term Multicast is used
    where Mulitpoint is more correct.

  • Reported: AVSTR 1.0 — Wed, 7 Oct 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT

set_dev_params() method in AVStreams IDL Interface

  • Key: AVSTR-1
  • Legacy Issue Number: 1845
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The set_dev_params() method in the AVStreams IDL interface raises a PropertyService::PropertyException. However, PropertyException which used to be an exception, was recently revised to be a struct in the Property Service. This broke the AVStreams interface since a struct cannot be raised. Can you please fix this.

  • Reported: AVSTR 1.0b1 — Thu, 20 Aug 1998 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT