Video Refresh Request Sample Clauses

Video Refresh Request. When using an MCU with a multipoint focus, which is switching video streams, there is a need to have a mechanism to request that video encoders generate a new I Frame (IDR Frame in H.264). The following RTCP APP packet is the mechanism for that request. This mechanism is not intended as the mechanism for repair of packet loss. The feedback mechanism detailed below should be used for that purpose. RTCP APP REFRESH packet format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|subtype=8| PT=APP=204 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | name=xcts | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit NTP timestamp, most significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transmit NTP timestamp, least significant word | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTCP APP Packet field definitions should follow [4] and: subtype: 5 bits MUST be set to ‘8’ to designate the REFRESH packet type. name: 4 bytes MUST be set to the value ‘xcts’. REFRESH Packet field definitions: transmit ntp timestamp: 64 bits The NTP time of the transmission of the REFRESH request. This can be used by the receiver to detect out of order or duplicate requests. target: 4 bytes The MUX-CSRC of the target encoder that is being requested to refresh. Typically this value would be provided from the RTP media packets being received from the transmitter.
AutoNDA by SimpleDocs

Related to Video Refresh Request

  • Service Request The Service Provider may:

  • Red Hat Directory Server Use Cases Subscription Services are provided for Red Hat Directory Server only when used for its supported Use Case in accordance with the terms of this Exhibit and Table 3.1 below.

  • Bona Fide Request/New Business Request Process for Further Unbundling 6.1 BellSouth shall, upon request of <<customer_name>>, provide to <<customer_name>> access to its network elements at any technically feasible point for the provision of <<customer_name>>'s telecommunications service where such access is necessary and failure to provide access would impair the ability of <<customer_name>> to provide services that it seeks to offer. Any request by <<customer_name>> for access to a network element, interconnection option, or for the provisioning of any service or product that is not already available shall be treated as a Bona Fide Request/New Business Request (BFR/NBR), and shall be submitted to BellSouth pursuant to the BFR/NBR process.

  • BONA FIDE REQUEST PROCESS 42.1. Embarq shall promptly consider and analyze CLEC requests for unbundled Network Elements that are not currently developed by Embarq, network information that is reasonably required to determine what unbundled Network Elements it needs to serve a particular customer or development of and changes to Embarq work processes related to ordering, provisioning or installation of unbundled Network Elements with the submission of a Bona Fide Request (“BFR”) hereunder.

  • Request A request to submit a grievance to arbitration must be in writing, signed by the aggrieved party, and such request must be filed in the office of the Superintendent within ten (10) days following the decision in Level III of the grievance procedure.

  • Software Use Case Red Hat Enterprise Linux Developer Suite Subscription Services for Red Hat Enterprise Linux Developer Suite are available for Development Purposes only.

  • DATA REQUESTS Upon the written request of the District, the State Auditor’s Office, the Appraisal District, or the Comptroller during the term of this Agreement, the Applicant, the District or any other entity on behalf of the District shall provide the requesting party with all information reasonably necessary for the requesting party to determine whether the Applicant is in compliance with its rights, obligations or responsibilities, including, but not limited to, any employment obligations which may arise under this Agreement.

  • Request for Proposal Once the project development stage and joint scope meeting have produced a County approved Detailed Scope of Work, the County will issue a Request for Proposal (RFP) to the Contractor. The RFP will include the Scope of Work approved by the County and other pertinent information with regards to scheduling, submittals, shop drawings and sketch requirements. The Contractor agrees to prepare and submit a JOC Task Order Proposal of Work.

  • Request for Proposals A State request inviting proposals for Goods or Services. This Contract shall be governed by the statutes, regulations and procedures of the State of Connecticut, Department of Administrative Services.

  • Loop Provisioning Involving Integrated Digital Loop Carriers 2.6.1 Where InterGlobe has requested an Unbundled Loop and BellSouth uses IDLC systems to provide the local service to the End User and BellSouth has a suitable alternate facility available, BellSouth will make such alternative facilities available to InterGlobe. If a suitable alternative facility is not available, then to the extent it is technically feasible, BellSouth will implement one of the following alternative arrangements for InterGlobe (e.g. hairpinning):

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!