From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2190.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc2190.txt (limited to 'doc/rfc/rfc2190.txt') diff --git a/doc/rfc/rfc2190.txt b/doc/rfc/rfc2190.txt new file mode 100644 index 0000000..41eb909 --- /dev/null +++ b/doc/rfc/rfc2190.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group C. Zhu +Request for Comments: 2190 Intel Corp. +Category: Standards Track September 1997 + + + RTP Payload Format for H.263 Video Streams + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies the payload format for encapsulating an H.263 + bitstream in the Real-Time Transport Protocol (RTP). Three modes are + defined for the H.263 payload header. An RTP packet can use one of + the three modes for H.263 video streams depending on the desired + network packet size and H.263 encoding options employed. The shortest + H.263 payload header (mode A) supports fragmentation at Group of + Block (GOB) boundaries. The long H.263 payload headers (mode B and C) + support fragmentation at Macroblock (MB) boundaries. + +1. Introduction + + This document describes a scheme to packetize an H.263 video stream + for transport using RTP [1]. H.263 video stream is defined by ITU-T + Recommendation H.263 (referred to as H.263 in this document) [4] for + video coding at very low data rates. RTP is defined by the Internet + Engineering Task Force (IETF) to provide end-to-end network transport + functions suitable for applications transmitting real-time data over + multicast or unicast network services. + +2. Definitions + + The following definitions apply in this document: + + CIF: Common Intermediate Format. For H.263, a CIF picture has 352 x + 288 pixels for luminance, and 176 x 144 pixels for chrominance. + + QCIF: Quarter CIF source format with 176 x 144 pixels for luminance + and 88 x 72 pixels for chrominance. + + Sub-QCIF: picture source format with 128 x 96 pixels for luminance + and 64 x 48 pixels for chrominance. + + + +Zhu Standards Track [Page 1] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + 4CIF: Picture source format with 704 x 576 pixels for luminance and + 352 x 288 pixels for chrominance. + + 16CIF: Picture source format with 1408 x 1152 pixels for luminance + and 704 x 576 pixels for chrominance. + + GOB: For H.263, a Group of Blocks (GOB) consists of k*16 lines, + where k depends on the picture format (k=1 for QCIF, CIF and sub- + QCIF; k=2 for 4CIF and k=4 for 16CIF). + + MB: A macroblock (MB) contains four blocks of luminance and the + spatially corresponding two blocks of chrominance. Each block + consists of 8x8 pixels. For example, there are eleven MBs in a GOB in + QCIF format and twenty two MBs in a GOB in CIF format. + +3. Design Issues for Packetizing H.263 Bitstreams + + H.263 is based on the ITU-T Recommendation H.261 [2] (referred to as + H.261 in this document). Compared to H.261, H.263 employs similar + techniques to reduce both temporal and spatial redundancy, but there + are several major differences between the two algorithms that affect + the design of packetization schemes significantly. This section + summarizes those differences. + +3.1 Optional Features of H.263 + + In addition to the basic source coding algorithms, H.263 supports + four negotiable coding options to improve performance: Advanced + Prediction, PB-frames, Syntax-based Arithmetic Coding, and + Unrestricted Motion Vectors. They can be used in any combination. + + Advanced Prediction(AP): One or four motion vectors can be used for + some macroblocks in a frame. This feature makes recovery from packet + loss difficult, because more redundant information has to be + preserved at the beginning of a packet when fragmenting at a + macroblock boundary. + + PB-frames: Two frames (a P frame and a B frame) are coded into one + bitstream with macroblocks from the two frames interleaved. From a + packetization point of view, a MB from the P frame and a MB from the + B frame must be treated together because each MB for the B frame is + coded based on the corresponding MB for the P frame. A means must be + provided to ensure proper rendering of two frames in the right order. + Also, if part of this combined bitstream is lost, it will affect both + frames, and possibly more. + + + + + + +Zhu Standards Track [Page 2] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + Syntax-based Arithmetic Coding (SAC): When the SAC option is used, + the resultant run-value pair after quantization of Discrete Cosine + Transform (DCT) coefficients will be coded differently from Huffman + codes, but the macroblock hierarchy will be preserved. Since context + variables are only synchronized after fixed length codes in the + bitstream, any fragmentation starting at variable length codes will + result in difficulty in decoding in the presence of packet loss + without carrying the values of all the context variables in each + H.263 payload header. + + The Unrestricted motion vectors feature allows large range of motion + vectors to improve performance of motion compensation for inter-coded + pictures. This option also affects packetization because it uses + larger range of motion vectors than normal. + + To enable proper decoding of packets received, without dependency on + previous packets, the use of these optional features is signaled in + the H.263 payload header, as described in Section 5. + +3.2 GOB Numbering + + In H.263, each picture is divided into groups of blocks (GOB). GOBs + are numbered according to a vertical scan of a picture, starting with + the top GOB and ending with the bottom GOB. In contrast, a GOB in + H.261 is composed of three rows of 16x16 MB for QCIF, and three + half-rows of MBs for CIF. A GOB is divided into macroblocks in H.263 + and the definition of the macroblocks are the same as in H.261. + + Each GOB in H.263 can have a fixed GOB header, but the use of the + header is optional. If the GOB header is present, it may or may not + start on a byte boundary. Byte alignment can be achieved by proper + bit stuffing by the encoder, but it is not required by the H.263 + bitstream specification [4]. + + In summary, a GOB in H.263 is defined and coded with finer + granularity but with the same source format, resulting in more + flexibility for packetization than with H.261. + +3.3 Motion Vector Encoding + + Differential coding is used to code motion vectors as variable length + codes. Unlike in H.261, where each motion vector is predicted from + the previous MB in the GOB, H.263 employs a more flexible prediction + scheme, where one or three candidate predictors could be used + depending on the presence of GOB headers. + + + + + + +Zhu Standards Track [Page 3] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + If the GOB header is present in a GOB, motion vectors are coded with + reference to MBs in the current GOB only. If a GOB header is not + present in the current GOB, three motion vectors must be available to + decode one macroblock, where two of them might come from the previous + GOB. To correctly decode a whole inter-coded GOB, all the motion + vectors for MBs in the previous GOB must be available to compute the + predictors or the predictors themselves must be present. The optional + use of three motion vector predictors can be a major problem for a + packetization scheme like the one defined for H.261 when packetizing + at MB boundaries [5]. + + Consider the case that a packet starts with a MB but the GOB header + is not present. If the previous packet is lost, then all the motion + vectors needed to predict the motion vectors for the MBs in the + current GOB are not available. In order to decode the received MBs + correctly, all the motion vectors for the previous GOB or the motion + vector predictors would have to be duplicated at the beginning of the + packet. This kind of duplication would be very expensive and + unacceptable in terms of bandwidth overhead. + + The encoding strategy of each H.263 CODEC (CODer and DECoder) + implementation is beyond the scope of this document, even though it + has significant effect on visual quality in the presence of packet + loss. However, we strongly recommend use of the GOB header for every + GOB at the beginning of a packet to address this problem. + + Similar problems exist because of cross-GOB data dependency related + to motion vectors, but they can not be addressed by using the GOB + header. For 16CIF and 4CIF pictures, a GOB contains more than one row + of MBs. If a GOB can not fit in one RTP packet, and the first packet + containing the GOB header is lost, then MBs in the second packet can + not compute motion vectors correctly, because they are coded relative + to data in the lost packet. Similarly, when OBMC (Overlapped Block + Motion Compensation) [4] in Advanced Prediction mode is used, motion + compensation for some MBs in one GOB could use motion vectors of MBs + in previous GOB regardless of the presence of GOB header. When MBs + that are used to decode received MBs are lost, those received MBs can + not be decoded correctly. Each implementation of the method described + in this document should take these limitations into account. + + + + + + + + + + + + +Zhu Standards Track [Page 4] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + +3.4 Macroblock Address + + As specified by H.261, a macroblock address (MBA) is encoded with a + variable length code to indicate the position of a macroblock within + a group of MBs in H.261 bitstreams. H.263 does not code the MBA + explicitly, but the macroblock address within a GOB is necessary to + recover from packet loss when fragmenting at MB boundaries. + Therefore, this information must be included in the H.263 payload + header for modes (mode B and mode C as described in Section 5) that + allow packetization at MB boundaries. + +4. Usage of RTP + + When transmitting H.263 video streams over the Internet, the output + of the encoder can be packetized directly. For every video frame, the + H.263 bitstream itself is carried in the RTP payload without + alteration, including the picture start code, the entire picture + header, in addition to any fixed length codes and variable length + codes. In addition, the output of the encoder is packetized without + adding the framing information specified by H.223 [6]. Therefore + multiplexing audio and video signals in the same packet is not + accommodated, as UDP and RTP provide a much more efficient way to + achieve multiplexing. + + RTP does not guarantee a reliable and orderly data delivery service, + so a packet might get lost in the network. To achieve a best-effort + recovery from packet loss, the decoder needs assistance to proceed + with decoding of other packets that are received. Thus it is + desirable to be able to process each packet independent of other + packets. Some frame level information is included in each packet, + such as source format and flags for optional features to assist the + decoder in operating correctly and efficiently in presence of packet + loss. The flags for H.263 optional features also provide information + about coding options used in H.263 video bitstreams that can be used + by session management tools. + + H.263 video bitstreams will be carried as payload data within RTP + packets. A new H.263 payload header is defined in section 5 on the + H.263 payload header. This section defines the usage of RTP fixed + header and H.263 video packet structure. + +4.1 RTP Header Usage + + Each RTP packet starts with a fixed RTP header [1]. The following + fields of the RTP fixed header are used for H.263 video streams: + + + + + + +Zhu Standards Track [Page 5] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + Marker bit (M bit): The Marker bit of the RTP fixed header is set to + 1 when the current packet carries the end of current frame; set to 0 + otherwise. + + Payload Type (PT): The Payload Type shall specify H.263 video payload + format using the value specified by the RTP profile in use, for + example RFC 1890 [3]. + + Timestamp: The RTP timestamp encodes the sampling instant of the + video frame contained in the RTP data packet. The RTP timestamp may + be the same on successive packets if a video frame occupies more + than one packet. For H.263 video streams, the RTP timestamp is based + on a 90 kHz clock, the same as the RTP timestamp for H.261 video + streams [5]. + +4.2 Video Packet Structure + + For each RTP packet, the RTP fixed header is followed by the H.263 + payload header, which is followed by the standard H.263 compressed + bitstream [4]. + + The size of the H.263 payload header is variable depending on modes + used as detailed in the next section. The layout of an RTP H.263 + video packet is shown as: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RTP header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H.263 payload header | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H.263 bitstream | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +5. H.263 Payload Header + + For H.263 video streams, each RTP packet carries only one H.263 video + packet. The H.263 payload header is always present for each H.263 + video packet. + + Three formats (mode A, mode B and mode C) are defined for H.263 + payload header. In mode A, an H.263 payload header of four bytes is + present before actual compressed H.263 video bitstream in a packet. + It allows fragmentation at GOB boundaries. In mode B, an eight byte + H.263 payload header is used and each packet starts at MB boundaries + without the PB-frames option. Finally, a twelve byte H.263 payload + + + +Zhu Standards Track [Page 6] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + header is defined in mode C to support fragmentation at MB boundaries + for frames that are coded with the PB-frames option. + + The mode of each H.263 payload header is indicated by the F and P + fields in the header. Packets of different modes can be intermixed. + All client application are required to be able to receive packets in + any mode, but decoding of mode C packets is optional because the PB- + frames feature is optional. + + In this section, the H.263 payload format is shown as rows of 32-bit + words. Each word is transmitted in network byte order. Whenever a + field represents a numeric value, the most significant bit is at the + left of the field. + +5.1 Mode A + + In this mode, an H.263 bitstream will be packetized on a GOB boundary + or a picture boundary. Mode A packets always start with the H.263 + picture start code [4] or a GOB, but do not necessarily contain + complete GOBs. Four bytes are used for the mode A H.263 payload + header. The H.263 payload header definition for mode A is shown as + follows with F=0. Mode A packets are allowed to start at a GOB + boundary even if no GOB header is present in the bitstream for the + GOB. However, such use is discouraged due to the dependencies it + creates across GOB boundaries, as described in Section 3.3. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |F|P|SBIT |EBIT | SRC |I|U|S|A|R |DBQ| TRB | TR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + F: 1 bit + The flag bit indicates the mode of the payload header. F=0, mode A; + F=1, mode B or mode C depending on P bit defined below. + + P: 1 bit + Optional PB-frames mode as defined by the H.263 [4]. "0" implies + normal I or P frame, "1" PB-frames. When F=1, P also indicates modes: + mode B if P=0, mode C if P=1. + + SBIT: 3 bits + Start bit position specifies number of most significant bits that + shall be ignored in the first data byte. + + EBIT: 3 bits + End bit position specifies number of least significant bits that + shall be ignored in the last data byte. + + + +Zhu Standards Track [Page 7] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + SRC : 3 bits + Source format, bit 6,7 and 8 in PTYPE defined by H.263 [4], specifies + the resolution of the current picture. + + I: 1 bit. + Picture coding type, bit 9 in PTYPE defined by H.263[4], "0" is + intra-coded, "1" is inter-coded. + + U: 1 bit + Set to 1 if the Unrestricted Motion Vector option, bit 10 in PTYPE + defined by H.263 [4] was set to 1 in the current picture header, + otherwise 0. + + S: 1 bit + Set to 1 if the Syntax-based Arithmetic Coding option, bit 11 in + PTYPE defined by the H.263 [4] was set to 1 for current picture + header, otherwise 0. + + A: 1 bit + Set to 1 if the Advanced Prediction option, bit 12 in PTYPE defined + by H.263 [4] was set to 1 for current picutre header, otherwise 0. + + R: 4 bits + Reserved, must be set to zero. + + DBQ: 2 bits + Differential quantization parameter used to calculate quantizer for + the B frame based on quantizer for the P frame, when PB-frames option + is used. The value should be the same as DBQUANT defined by H.263 + [4]. Set to zero if PB-frames option is not used. + + TRB: 3 bits + Temporal Reference for the B frame as defined by H.263 [4]. Set to + zero if PB-frames option is not used. + + TR: 8 bits + Temporal Reference for the P frame as defined by H.263 [4]. Set to + zero if the PB-frames option is not used. + +5.2 Mode B + + In this mode, an H.263 bitstream can be fragmented at MB boundaries. + Whenever a packet starts at a MB boundary, this mode shall be used + without PB-frames option. Mode B packets are intended for a GOB whose + size is larger than the maximum packet size allowed in the underlying + protocol, thus making it impossible to fit one or more complete GOBs + in a packet. This mode can only be used without the PB-frames option. + Mode C as defined in the next section can be used to fragment H.263 + + + +Zhu Standards Track [Page 8] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + bitstreams at MB boundaries with the PB-frames option. The H.263 + payload header definition for mode B is shown as follows with F=1 and + P=0: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following fields are defined the same as in mode A: F, P, SBIT, + EBIT, SRC, I, U, S and A. Other fields are defined as follows: + + QUANT: 5 bits + Quantization value for the first MB coded at the starting of the + packet. Set to 0 if the packet begins with a GOB header. This is the + equivalent of GQUANT defined by the H.263 [4]. + + GOBN: 5 bits + GOB number in effect at the start of the packet. GOB number is + specified differently for different resolutions. See H.263 [4] for + details. + + MBA: 9 bits + The address within the GOB of the first MB in the packet, counting + from zero in scan order. For example, the third MB in any GOB is + given MBA = 2. + + HMV1, VMV1: 7 bits each. + Horizontal and vertical motion vector predictors for the first MB in + this packet [4]. When four motion vectors are used for current MB + with advanced prediction option, these would be the motion vector + predictors for block number 1 in the MB. Each 7 bits field encodes a + motion vector predictor in half pixel resolution as a 2's complement + number. + + HMV2, VMV2: 7 bits each. + Horizontal and vertical motion vector predictors for block number 3 + in the first MB in this packet when four motion vectors are used with + the advanced prediction option. This is needed because block number 3 + in the MB needs different motion vector predictors from other blocks + in the MB. These two fields are not used when the MB only has one + motion vector. See the H.263 [4] for block organization in a + macroblock. Each 7 bits field encodes a motion vector predictor in + half pixel resolution as a 2's complement number. + + + + +Zhu Standards Track [Page 9] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + R : 2 bits + Reserved, must be set to zero. + +5.3 Mode C + + In this mode, an H.263 bitstream is fragmented at MB boundaries of P + frames with the PB-frames option. It is intended for those GOBs whose + sizes are larger than the maximum packet size allowed in the + underlying protocol when PB-frames option is used. The H.263 payload + header definition for mode C is shown as follows with F=1 and P=1: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |F|P|SBIT |EBIT | SRC | QUANT | GOBN | MBA |R | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |I|U|S|A| HMV1 | VMV1 | HMV2 | VMV2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RR |DBQ| TRB | TR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The following fields are defined the same as in mode B: F, P, SBIT, + EBIT, SRC, QUANT, GOBN, MBA, R, I, U, S, A, HMV1, VMV1, HMV2, VMV2. + The rest of the fields (TR, DBQ, TRB) are defined the same as in mode + A, except field RR. The RR field takes 19 bits, and is currently + reserved. It must be set to zero. + +5.4 Selection of Modes for the H.263 Payload Header + + Packets carrying H.263 video streams with different modes can be + intermixed. The modes shall be selected carefully based on network + packet size, H.263 coding options and underlying network protocols. + More specifically, mode A shall be used for packets starting with a + GOB or the H.263 picture start code [4], and mode B or C shall be + used whenever a packet has to start at a MB boundary. Mode B or C are + necessary for those GOBs with sizes larger than network packet size. + + We strongly recommend use of mode A whenever possible. The major + advantage of mode A over mode B and C is its simplicity. The H.263 + payload header is smaller than mode B and C. Transmission overhead is + reduced and the savings may be very significant when working with + very low data rates or relatively small packet sizes. + + Another advantage of mode A is that it simplifies error recovery in + the presence of packet loss. The internal state of a decoder can be + recovered at GOB boundaries instead of having to synchronize with MBs + as in mode B and C. The GOB headers and the picture start code are + easy to identify, and their presence will normally cause a H.263 + + + +Zhu Standards Track [Page 10] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + + decoder to re-synchronize its internal states. + + Finally, we would like to stress that recovery from packet loss + depends on a decoder's ability to use the information provided in the + H.263 payload header within RTP packets. + +6. Limitations + + The packetization method described in this document applies to the + 1996 version of H.263. It may not be applicable to bitstreams with + features added after that. + +Security Considerations + + Security issues are addressed by RTP [1]. This memo does not bring + up any additional security issues. + +7. Acknowledgments + + The author would like to thank the following people for their + valuable comments: Linda S. Cline, Christian Maciocco, Mojy + Mirashrafi, Phillip Lantz, Steve Casner, Gary Sullivan, and Sassan + Pejhan. + +8. References + +[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, + "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, + January 1996. + +[2] International Telecommunication Union. + Video Codec for Audiovisual Services at p x 64 kbits/s, + ITU-T Recommendation H.261, 1993. + +[3] Schulzrinne, H., + "RTP Profile for Audio and Video Conference with Minimal + Control", RFC 1890, + January 1996. + +[4] International Telecommunication Union. + Video Coding for Low Bitrate Communication, ITU-T Recommendation + H.263, 1996 + +[5] Turletti, T., and C. Huitema, + "RTP Payload Format for H.261 Video Streams", RFC 2032, + October 1996. + + + + + +Zhu Standards Track [Page 11] + +RFC 2190 RTP Payload Format for H.263 Video Streams September 1997 + + +[6] International Telecommunication Union. + Multiplexing Protocol for Low Bitrate Multimedia Communication, + ITU-T Recommendation H.223, 1995. + +7. Author's Address + + C. "Chad" Zhu + Mail Stop: JF3-202 + Intel Corporation + 2111 N.E. 25th Avenue + Hillsboro, OR 97124 + USA + + EMail: czhu@ibeam.intel.com + Phone: (503) 264-6008 + Fax: (503) 264-1805 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu Standards Track [Page 12] + -- cgit v1.2.3