RTP MIDIPayload格式：互联网工程任务组标准

Midi

需积分: 2 144 浏览量更新于2024-06-16 收藏 858KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

The comex interpretation of timestamps is usually not the best

timestamp interpretation for transcoding a MIDI source that uses

implicit command timing (such as MIDI 1.0 DIN cables) into an RTP

MIDI stream. Appendix C.3 defines alternatives to comex semantics

and describes session configuration tools for selecting the timestamp

interpretation semantics for a stream.

One-Octet Delta Time:

Encoded form: 0ddddddd

Decoded form: 00000000 00000000 00000000 0ddddddd

Two-Octet Delta Time:

Encoded form: 1ccccccc 0ddddddd

Decoded form: 00000000 00000000 00cccccc cddddddd

Three-Octet Delta Time:

Encoded form: 1bbbbbbb 1ccccccc 0ddddddd

Decoded form: 00000000 000bbbbb bbcccccc cddddddd

Four-Octet Delta Time:

Encoded form: 1aaaaaaa 1bbbbbbb 1ccccccc 0ddddddd

Decoded form: 0000aaaa aaabbbbb bbcccccc cddddddd

Figure 4 -- Decoding Delta Time Formats

3.2. Command Coding

Each non-empty MIDI Command field in the MIDI list codes one of the

MIDI command types that may legally appear on a MIDI 1.0 DIN cable.

Standard MIDI File meta-events do not fit this definition and MUST

NOT appear in the MIDI list. As a rule, each MIDI Command field

Lazzaro & Wawrzynek Standards Track [Page 16]

RFC 6295 RTP Payload Format for MIDI June 2011

codes a complete command, in the binary command format defined in

[MIDI]. In the remainder of this section, we describe exceptions to

this rule.

The first MIDI channel command in the MIDI list MUST include a status

octet. Running status coding, as defined in [MIDI], MAY be used for

all subsequent MIDI channel commands in the list. As in [MIDI],

System Common and System Exclusive messages (0xF0 ... 0xF7) cancel

the running status state, but System Real-Time messages (0xF8 ...

0xFF) do not affect the running status state. All system commands in

the MIDI list MUST include a status octet.

As we note above, the first channel command in the MIDI list MUST

include a status octet. However, the corresponding command in the

original MIDI source data stream might not have a status octet (in

this case, the source would be coding the command using running

status). If the status octet of the first channel command in the

MIDI list does not appear in the source data stream, the P (phantom)

header bit MUST be set to 1. In all other cases, the P bit MUST be

set to 0.

Note that the P bit describes the MIDI source data stream, not the

MIDI list encoding; regardless of the state of the P bit, the MIDI

list MUST include the status octet.

As receivers MUST be able to decode running status, sender

implementors should feel free to use running status to improve

bandwidth efficiency. However, senders SHOULD NOT introduce timing

jitter into an existing MIDI command stream through an inappropriate

use or removal of running status coding. This warning primarily

applies to senders whose RTP MIDI streams may be transcoded onto a

MIDI 1.0 DIN cable [MIDI] by the receiver: both the timestamps and

the command coding (running status or not) must comply with the

physical restrictions of implicit time coding over a slow serial

line.

On a MIDI 1.0 DIN cable [MIDI], a System Real-Time command may be

embedded inside of another "host" MIDI command. This syntactic

construction is not supported in the payload format: a MIDI Command

field in the MIDI list codes exactly one MIDI command (partially or

completely).

To encode an embedded System Real-Time command, senders MUST extract

the command from its host and code it in the MIDI list as a separate

command. The host command and System Real-Time command SHOULD appear

in the same MIDI list. The delta time of the System Real-Time

command SHOULD result in a command timestamp that encodes the System

Real-Time command placement in its original embedded position.

Lazzaro & Wawrzynek Standards Track [Page 17]

RFC 6295 RTP Payload Format for MIDI June 2011

Two methods are provided for encoding MIDI System Exclusive (SysEx)

commands in the MIDI list. A SysEx command may be encoded in a MIDI

Command field verbatim: a 0xF0 octet, followed by an arbitrary number

of data octets, followed by a 0xF7 octet.

Alternatively, a SysEx command may be encoded as multiple segments.

The command is divided into two or more SysEx command segments; each

segment is encoded in its own MIDI Command field in the MIDI list.

The payload format supports segmentation in order to encode SysEx

commands that encode information in the temporal pattern of data

octets. By encoding these commands as a series of segments, each

data octet may be associated with a distinct delta time.

Segmentation also supports the coding of large SysEx commands across

several packets.

To segment a SysEx command, first partition its data octet list into

two or more sublists. The last sublist MAY be empty (i.e., contain

no octets); all other sublists MUST contain at least one data octet.

To complete the segmentation, add the status octets defined in Figure

5 to the head and tail of the first, last, and any "middle" sublists.

Figure 6 shows example segmentations of a SysEx command.

A sender MAY cancel a segmented SysEx command transmission that is in

progress by sending the "cancel" sublist shown in Figure 5. A

"cancel" sublist MAY follow a "first" or "middle" sublist in the

transmission but MUST NOT follow a "last" sublist. The cancel MUST

be empty (thus, 0xF7 0xF4 is the only legal cancel sublist).

The cancellation feature is needed because Appendix C.1 defines

configuration tools that let session parties exclude certain SysEx

commands in the stream. Senders that transcode a MIDI source onto an

RTP MIDI stream under these constraints have the responsibility of

excluding undesired commands from the RTP MIDI stream.

The cancellation feature lets a sender start the transmission of a

command before the MIDI source has sent the entire command. If a

sender determines that the command whose transmission is in progress

should not appear on the RTP stream, it cancels the command. Without

a method for cancelling a SysEx command transmission, senders would

be forced to use a high-latency store-and-forward approach to

transcoding SysEx commands onto RTP MIDI packets, in order to

validate each SysEx command before transmission.

The recommended receiver reaction to a cancellation depends on the

capabilities of the receiver. For example, a sound synthesizer that

is directly parsing RTP MIDI packets and rendering them to audio will

Lazzaro & Wawrzynek Standards Track [Page 18]

RFC 6295 RTP Payload Format for MIDI June 2011

be aware of the fact that SysEx commands may be cancelled in RTP

MIDI. These receivers SHOULD detect a SysEx cancellation in the MIDI

list and act as if they had never received the SysEx command.

As a second example, a synthesizer may be receiving MIDI data from an

RTP MIDI stream via a MIDI DIN cable (or a software API emulation of

a MIDI DIN cable). In this case, an RTP-MIDI-aware system receives

the RTP MIDI stream and transcodes it onto the MIDI DIN cable (or its

emulation). Upon the receipt of the cancel sublist, the RTP-MIDI-

aware transcoder might have already sent the first part of the SysEx

command on the MIDI DIN cable to the receiver.

Unfortunately, the MIDI DIN cable protocol cannot directly code

"cancel SysEx in progress" semantics. However, MIDI DIN cable

receivers begin SysEx processing after the complete command arrives.

The receiver checks to see if it recognizes the command (coded in the

first few octets) and then checks to see if the command is the

correct length. Thus, in practice, a transcoder can cancel a SysEx

command by sending an 0xF7 to (prematurely) end the SysEx command --

the receiver will detect the incorrect command length and discard the

command.

Appendix C.1 defines configuration tools that may be used to prohibit

SysEx command cancellation.

The relative ordering of SysEx command segments in a MIDI list must

match the relative ordering of the sublists in the original SysEx

command. By default, commands other than System Real-Time MIDI

commands MUST NOT appear between SysEx command segments (Appendix C.1

defines configuration tools to change this default to let other

commands types appear between segments). If the command segments of

a SysEx command are placed in the MIDI lists of two or more RTP

packets, the segment ordering rules apply to the concatenation of all

affected MIDI lists.

-----------------------------------------------------------

| Sublist Position | Head Status Octet | Tail Status Octet |

|-----------------------------------------------------------|

| first | 0xF0 | 0xF0 |

|-----------------------------------------------------------|

| middle | 0xF7 | 0xF0 |

|-----------------------------------------------------------|

| last | 0xF7 | 0xF7 |

|-----------------------------------------------------------|

| cancel | 0xF7 | 0xF4 |

-----------------------------------------------------------

Figure 5 -- Command Segmentation Status Octets

Lazzaro & Wawrzynek Standards Track [Page 19]

RFC 6295 RTP Payload Format for MIDI June 2011

[MIDI] permits 0xF7 octets that are not part of a (0xF0, 0xF7) pair

to appear on a MIDI 1.0 DIN cable. Unpaired 0xF7 octets have no

semantic meaning in MIDI apart from cancelling running status.

Unpaired 0xF7 octets MUST NOT appear in the MIDI list of the MIDI

Command section. We impose this restriction to avoid interference

with the command segmentation coding defined in Figure 5.

SysEx commands carried on a MIDI 1.0 DIN cable may use the "dropped

0xF7" construction [MIDI]. In this coding method, the 0xF7 octet is

dropped from the end of the SysEx command, and the status octet of

the next MIDI command acts both to terminate the SysEx command and

start the next command. To encode this construction in the payload

format, follow these steps:

o Determine the appropriate delta times for the SysEx command and

the command that follows the SysEx command.

o Insert the "dropped" 0xF7 octet at the end of the SysEx command to

form the standard SysEx syntax.

o Code both commands into the MIDI list using the rules above.

o Replace the 0xF7 octet that terminates the verbatim SysEx encoding

or the last segment of the segmented SysEx encoding with a 0xF5

octet. This substitution informs the receiver of the original

"dropped 0xF7" coding.

[MIDI] reserves the undefined System Common commands 0xF4 and 0xF5

and the undefined System Real-Time commands 0xF9 and 0xFD for future

use. By default, undefined commands MUST NOT appear in a MIDI

Command field in the MIDI list, with the exception of the 0xF5 octets

used to code the "dropped 0xF7" construction and the 0xF4 octets used

by SysEx "cancel" sublists.

During session configuration, a stream may be customized to transport

undefined commands (Appendix C.1). For this case, we now define how

senders encode undefined commands in the MIDI list.

An undefined System Real-Time command MUST be coded using the System

Real-Time rules.

If the undefined System Common commands are put to use in a future

version of [MIDI], the command will begin with an 0xF4 or 0xF5 status

octet, followed by an arbitrary number of data octets (i.e., zero or

more data bytes). To encode these commands, senders MUST terminate

the command with an 0xF7 octet and place the modified command into

the MIDI Command field.

Lazzaro & Wawrzynek Standards Track [Page 20]

RFC 6295 RTP Payload Format for MIDI June 2011

Unfortunately, non-compliant uses of the undefined System Common

commands may appear in MIDI implementations. To model these

commands, we assume that the command begins with an 0xF4 or 0xF5

status octet, followed by zero or more data octets, followed by zero

or more trailing 0xF7 status octets. To encode the command, senders

MUST first remove all trailing 0xF7 status octets from the command.

Then, senders MUST terminate the command with an 0xF7 octet and place

the modified command into the MIDI Command field.

Note that we include the trailing octets in our model as a cautionary

measure: if such commands appeared in a non-compliant use of an

undefined System Common command, an RTP MIDI encoding of the command

that did not remove trailing octets could be mistaken for an encoding

of the "middle" or "last" sublist of a segmented SysEx command

(Figure 5) under certain packet loss conditions.

Original SysEx command:

剩余167页未读，继续阅读

weixin_36989426

粉丝: 0
资源: 20

RTP MIDIPayload格式：互联网工程任务组标准

RTP Payload Format for H.264&H.265 Video

error: unknown type name 'RTP_PAYLOAD_TYPE' RTP_PAYLOAD_TYPE RTP_PAYLOAD_TYPE_VIDEO_0;//first streamer video type

frame += rtp_payload_size; frameSize -= rtp_payload_size; 分析这段代码

RTP_PAYLOAD_TYPE_H264和RTP_PAYLOAD_TYPE_H265

将.cpp文件改为.c文件后编译报错 error: unknown type name 'RTP_PAYLOAD_TYPE' RTP_PAYLOAD_TYPE RTP_PAYLOAD_TYPE_VIDEO_0;//first streamer video type

error: unknown type name 'RTP_PAYLOAD_ RTP_PAYLOAD_TYPE RTP_PAYLOAD_TYPE_VIDEO_0;//first streamer video type

frame += rtp_payload_size; frameSize -= rtp_payload_size;这段代码是在计算H264的负载数据么

int rtp_payload_size = RTP_MAX_PKT_SIZE - RTP_HEADER_SIZE;

golang中写入pcma的rtp包pkt := &rtp.Packet{ Header: rtp.Header{ Version: 2, PayloadType: 8, }, Payload: dat.pcma, } dat.rtpPackets = []*rtp.Packet{pkt}是否正确

h265的rtp_payload_size 怎么设置 给整个例程看一下 兄弟

rtppayloadformat

while (frameSize > rtp_payload_size)

memcpy(&rtpPacket->rtppayload[RTP_HEADER_SIZE], frame, rtp_payload_size); ret = RtpSendPacket(socket, ip, port, rtpPacket, RTP_MAX_PKT_SIZE); if(ret < 0) return -1; rtpPacket->rtpHeader.seq++; sendBytes += ret;

h265的rtp_payload_size是怎么设置的 也是RTP_MAX_PKT_SIZE - RTP_HEADER_SIZE么

rfc4588 RTP重传有效载荷格式

h265的rtp_payload_size是怎么设置的

python 解析rtp包

[rtp @ 00000160512f0300] Unable to receive RTP payload type 96 without an SDP file describing it rtp://127.0.0.1:1234: Invalid data found when processing input

golang中pcmu如何打包为rtp？

subprocess 创建一个rtsp 流推送服务器, 循环推送rtp数据包 代码示例

最新资源

h265的rtp_payload_size 怎么设置给整个例程看一下兄弟

h265的rtp_payload_size是怎么设置的也是RTP_MAX_PKT_SIZE - RTP_HEADER_SIZE么

subprocess 创建一个rtsp 流推送服务器, 循环推送rtp数据包代码示例