Merge pull request #15 from video-audio/master

gofmt, golint, golangci-lint, panic prevent

Author: wernerd

README.md

@@ -1,92 +1,92 @@
-# RTP/RTCP stack for Go
-
-This Go package implements a RTP/RTCP stack for Go. The package is a
-sub-package of the standard Go _net_ package and uses standard _net_ package
-functions. 
-
-## How to build
-
-The _rtp_ sources use the GOPATH directory structure. To build, test, and run
-the software just add the main goRTP directory to GOPATH. For further
-information about this structure run `go help gopath` and follow the
-instructions. The _rtp_ package is below the package _net_ to make clear that
-_rtp_ is a network related package.
-
-To build the package just run `go build net/rtp` and then `go install
-net/rtp`. To excecute the tests just run `go test net/rtp`. The tests check if
-the code works with the current Go installation on your system. It should
-PASS.
-
-A demo program is available and is called _rtpmain_. Use `go build
-net/rtpmain` to build it. The command `go install net/rtpmain` installs it in
-the `bin` directory of the main directory.
-
-## How to use
-
-This is a pure RTP / RTCP stack and it does not contain any media processing,
-for example generating or packing the payload for audio or video codecs.
-
-The directory `src/net/rtpmain` contains an example Go program that performs a
-RTP some tests on _localhost_ that shows how to setup a RTP session, an
-output stream and how to send and receive RTP data and control events. Parts
-of this program are used in the package documentation.
-
-The software should be ready to use for many RTP applications. Standard
-point-to-point RTP applications should not pose any problems. RTP multi-cast
-using IP multi-cast addresses is not supported. If somebody really requires IP
-multi-cast it could be added at the transport level.
-
-RTCP reporting works without support from application. The stack reports RTCP
-packets and if the stack created new input streams and an application may
-connect to the control channel to receive the RTCP events. Just have a look
-into the example program. The RTCP fields in the stream structures are
-accessible - however, to use them you may need to have some know-how of the
-RTCP definitions and reporting.
-
-## The documentation
-
-After you downloaded the code you may use standard _godoc_ to get a nice
-formatted documentation. Just change into the `src` directory, run `godoc
--http=:6060 -path="."`, point your browser at _localhost:6060_, and select
-`src` at the top of the page.
-
-I've added some package global documentation and tried to document the
-globally visible methods and functions.
-
-Before you start hacking please have a look into the documentation first, in
-particular the package documentation (doc.go).
-
-## Some noteable features
-
-* The current release V1.0.0 computes the RTCP intervals based on the length of
-  RTCP compound packets and the bandwidth allocated to RTCP. The application may
-  set the bandwidth, if no set GoRTP makes somes educated guesses.
-  
-* The application may set the maximum number of output and input streams even
-  while the RTP session is active. If the application des not set GoRTP sets
-  the values to 5 and 30 respectively.
-  
-* GoRTP produces SR and RR reports and the associated SDES for active streams
-  only, thus it implements the activity check as defined in chapter 6.4
-
-* An appplication may use GoRTP in _simple RTP_ mode. In this mode only RTP
-  data packets are exchanged between the peers. No RTCP service is active, no
-  statistic counters, and GoRTP discards RTCP packets it receives.
-
-* GoRTP limits the number of RR to 31 per RTCP report interval. GoRTP does not
-  add an additional RR packet in case it detects more than 31 active input
-  streams. This restriction is mainly due to MTU contraints of modern Ethernet
-  or DSL based networks. The MTU is usually about 1500 bytes, GoRTP limits
-  the RTP/RTCP packet size to 1200 bytes. The length of an RR is 24 bytes,
-  thus 31 RR already require 774 bytes. Adding some data for SR and SDES fills
-  the rest. 
-
-* An application may register to a control event channel and GoRTP delivers a
-  nice set of control and error events. The events cover:
-  - Creation of a new input stream when receiving an RTP or RTCP packet and
-    the SSRC was not known
-  - RTCP events to inform about RTCP packets and received reports
-  - Error events
-
-* Currently GoRTP supports only SR, RR, SDES, and BYE RTCP packets. Inside 
-SDES GoRTP does not support SDES Private and SDES H.323 items.
+# RTP/RTCP stack for Go
+
+This Go package implements a RTP/RTCP stack for Go. The package is a
+sub-package of the standard Go _net_ package and uses standard _net_ package
+functions.
+
+## How to build
+
+The _rtp_ sources use the GOPATH directory structure. To build, test, and run
+the software just add the main goRTP directory to GOPATH. For further
+information about this structure run `go help gopath` and follow the
+instructions. The _rtp_ package is below the package _net_ to make clear that
+_rtp_ is a network related package.
+
+To build the package just run `go build net/rtp` and then `go install
+net/rtp`. To excecute the tests just run `go test net/rtp`. The tests check if
+the code works with the current Go installation on your system. It should
+PASS.
+
+A demo program is available and is called _rtpmain_. Use `go build
+net/rtpmain` to build it. The command `go install net/rtpmain` installs it in
+the `bin` directory of the main directory.
+
+## How to use
+
+This is a pure RTP / RTCP stack and it does not contain any media processing,
+for example generating or packing the payload for audio or video codecs.
+
+The directory `src/net/rtpmain` contains an example Go program that performs a
+RTP some tests on _localhost_ that shows how to setup a RTP session, an
+output stream and how to send and receive RTP data and control events. Parts
+of this program are used in the package documentation.
+
+The software should be ready to use for many RTP applications. Standard
+point-to-point RTP applications should not pose any problems. RTP multi-cast
+using IP multi-cast addresses is not supported. If somebody really requires IP
+multi-cast it could be added at the transport level.
+
+RTCP reporting works without support from application. The stack reports RTCP
+packets and if the stack created new input streams and an application may
+connect to the control channel to receive the RTCP events. Just have a look
+into the example program. The RTCP fields in the stream structures are
+accessible - however, to use them you may need to have some know-how of the
+RTCP definitions and reporting.
+
+## The documentation
+
+After you downloaded the code you may use standard _godoc_ to get a nice
+formatted documentation. Just change into the `src` directory, run `godoc
+-http=:6060 -path="."`, point your browser at _localhost:6060_, and select
+`src` at the top of the page.
+
+I've added some package global documentation and tried to document the
+globally visible methods and functions.
+
+Before you start hacking please have a look into the documentation first, in
+particular the package documentation (doc.go).
+
+## Some noteable features
+
+* The current release V1.0.0 computes the RTCP intervals based on the length of
+  RTCP compound packets and the bandwidth allocated to RTCP. The application may
+  set the bandwidth, if no set GoRTP makes somes educated guesses.
+
+* The application may set the maximum number of output and input streams even
+  while the RTP session is active. If the application des not set GoRTP sets
+  the values to 5 and 30 respectively.
+
+* GoRTP produces SR and RR reports and the associated SDES for active streams
+  only, thus it implements the activity check as defined in chapter 6.4
+
+* An appplication may use GoRTP in _simple RTP_ mode. In this mode only RTP
+  data packets are exchanged between the peers. No RTCP service is active, no
+  statistic counters, and GoRTP discards RTCP packets it receives.
+
+* GoRTP limits the number of RR to 31 per RTCP report interval. GoRTP does not
+  add an additional RR packet in case it detects more than 31 active input
+  streams. This restriction is mainly due to MTU contraints of modern Ethernet
+  or DSL based networks. The MTU is usually about 1500 bytes, GoRTP limits
+  the RTP/RTCP packet size to 1200 bytes. The length of an RR is 24 bytes,
+  thus 31 RR already require 774 bytes. Adding some data for SR and SDES fills
+  the rest.
+
+* An application may register to a control event channel and GoRTP delivers a
+  nice set of control and error events. The events cover:
+  - Creation of a new input stream when receiving an RTP or RTCP packet and
+    the SSRC was not known
+  - RTCP events to inform about RTCP packets and received reports
+  - Error events
+
+* Currently GoRTP supports only SR, RR, SDES, and BYE RTCP packets. Inside
+SDES GoRTP does not support SDES Private and SDES H.323 items.

src/net/rtp/ctrlpacket_test.go

@@ -25,15 +25,15 @@ import (
 )
 
 // V=2, P=0, chunks=2;   PT=SDES; length=5 32bit words (24 bytes)
-var sdes_1 = []byte{0x81, 202, 0x00, 0x05,
+var sdes1 = []byte{0x81, 202, 0x00, 0x05,
 	0x01, 0x02, 0x03, 0x04, // SSRC 0x01020304
 	0x01, 0x01, 0x02, // CNAME, len=1, content=2
 	0x00,                   // END (chunk length: 8)
 	0x05, 0x06, 0x07, 0x08, // SSRC 0x05060707
 	0x01, 0x03, 0x05, 0x06, 0x07, // CNAME, len=3, content=5,6,7
 	0x00, 0x00, 0x00} // END plus 2 padding (chunk length: 12)
 // V=2, P=0, chunks=2;   PT=SDES; length=8 32bit words (36 bytes)
-var sdes_2 = []byte{0x81, 202, 0x00, 0x08,
+var sdes2 = []byte{0x81, 202, 0x00, 0x08,
 	// first chunk, two items: CNAME, NAME, END)
 	0x01, 0x02, 0x03, 0x04, // SSRC 0x01020304
 	0x01, 0x01, 0x02, // CNAME, len=1, content=2 (item length: 3)
@@ -46,7 +46,7 @@ var sdes_2 = []byte{0x81, 202, 0x00, 0x08,
 	0x00, 0x00, 0x00} // END plus 2 padding (chunk length: 12)
 
 // V=2, P=0, chunks=2;   PT=SDES; length=5 32bit words (24 bytes)
-var sdes_1_wrong = []byte{0x81, 202, 0x00, 0x05,
+var sdes1wrong = []byte{0x81, 202, 0x00, 0x05,
 	0x01, 0x02, 0x03, 0x04, // SSRC 0x01020304
 	0x01, 0x03, 0x02, // CNAME, len=3 (wrong, should be 1), content=2
 	0x00,                   // END (chunk length: 8)
@@ -58,7 +58,7 @@ func sdesCheck(t *testing.T) (result bool) {
 	result = false
 
 	rp := new(CtrlPacket) // allocate a new CTRL packet.
-	rp.buffer = sdes_1
+	rp.buffer = sdes1
 
 	cnt := int((rp.Length(0) + 1) * 4) // SDES Length incl. header word
 	if cnt != 24 {
@@ -87,7 +87,7 @@ func sdesCheck(t *testing.T) (result bool) {
 		return
 	}
 
-	rp.buffer = sdes_2
+	rp.buffer = sdes2
 	cnt = int((rp.Length(0) + 1) * 4) // SDES Length incl. header word
 	if cnt != 36 {
 		t.Error(fmt.Sprintf("Basic second SDES length check failed. Expected: 36, got: %d\n", cnt))
@@ -115,7 +115,7 @@ func sdesCheck(t *testing.T) (result bool) {
 		return
 	}
 
-	rp.buffer = sdes_1_wrong
+	rp.buffer = sdes1wrong
 	offset = 4
 	// SDES chunk starts ofter first header word
 	sdesChunk = rp.toSdesChunk(offset, cnt-4)

src/net/rtp/datapacket_test.go

@@ -36,15 +36,15 @@ var payloadNull = []byte{}
 var initialPacket = []byte{0x80, 0x03, 0x47, 0x11, 0xf0, 0xe0, 0xd0, 0xc0, 0x01, 0x02, 0x03, 0x04,
 	0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x20}
 
-var csrc_1 = []uint32{0x21435465, 0x65544322}
-var csrc_2 = []uint32{0x23445566, 0x66554423, 0x87766554}
-var csrc_3 = []uint32{}
+var csrc1 = []uint32{0x21435465, 0x65544322}
+var csrc2 = []uint32{0x23445566, 0x66554423, 0x87766554}
+var csrc3 = []uint32{}
 
 //                 profile ID     length
-var ext_1 = []byte{0x77, 0x88, 0x00, 0x02, 0x01, 0x02, 0x03, 0x04, 0x04, 0x03, 0x02, 0x01}                         // len: 12
-var ext_2 = []byte{0x77, 0x89, 0x00, 0x03, 0x01, 0x02, 0x03, 0x04, 0x04, 0x03, 0x02, 0x01, 0x11, 0x22, 0x33, 0x44} // len: 16
-var ext_3 = []byte{0x77, 0x8a, 0x00, 0x00}                                                                         // len: 4
-var ext_4 = []byte{}
+var ext1 = []byte{0x77, 0x88, 0x00, 0x02, 0x01, 0x02, 0x03, 0x04, 0x04, 0x03, 0x02, 0x01}                         // len: 12
+var ext2 = []byte{0x77, 0x89, 0x00, 0x03, 0x01, 0x02, 0x03, 0x04, 0x04, 0x03, 0x02, 0x01, 0x11, 0x22, 0x33, 0x44} // len: 16
+var ext3 = []byte{0x77, 0x8a, 0x00, 0x00}                                                                         // len: 4
+var ext4 = []byte{}
 
 func headerCheck(rp *DataPacket, t *testing.T) (result bool) {
 	result = false
@@ -275,7 +275,7 @@ func rtpPacket(t *testing.T) {
 	rp.SetPayload(payload)
 
 	// Now check CSRC list handling. These modify InUse and shift the payload inside the packet buffer.
-	if !csrcTest(rp, t, csrc_1, 1) || !csrcTest(rp, t, csrc_2, 2) || !csrcTest(rp, t, csrc_3, 3) {
+	if !csrcTest(rp, t, csrc1, 1) || !csrcTest(rp, t, csrc2, 2) || !csrcTest(rp, t, csrc3, 3) {
 		return
 	}
 	// After last CSCR test the packet shall be in initial state, check it.
@@ -291,7 +291,7 @@ func rtpPacket(t *testing.T) {
 			return
 		}
 	}
-	if !extTest(rp, t, ext_1, 1) || !extTest(rp, t, ext_2, 2) || !extTest(rp, t, ext_3, 3) || !extTest(rp, t, ext_4, 4) {
+	if !extTest(rp, t, ext1, 1) || !extTest(rp, t, ext2, 2) || !extTest(rp, t, ext3, 3) || !extTest(rp, t, ext4, 4) {
 		return
 	}
 	// After last EXT test the packet shall be in initial state, check it.
@@ -307,14 +307,14 @@ func rtpPacket(t *testing.T) {
 			return
 		}
 	}
-	if !csrcTest(rp, t, csrc_1, 1) || !extTest(rp, t, ext_1, 1) {
+	if !csrcTest(rp, t, csrc1, 1) || !extTest(rp, t, ext1, 1) {
 		return
 	}
 	if *verbose {
 		rp.Print("CSCR/EXT combined")
 	}
 	use = rp.InUse()
-	expected := rtpHeaderLength + len(payload) + len(csrc_1)*4 + len(ext_1)
+	expected := rtpHeaderLength + len(payload) + len(csrc1)*4 + len(ext1)
 	if use != expected {
 		t.Error(fmt.Sprintf("Packet length check afer CSRC/EXT failed. Expected: %d, got: %d\n", expected, use))
 		return

src/net/rtp/doc.go

@@ -17,7 +17,7 @@
 //
 
 /*
-The GoRTP package rtp implements the RTP/RTCP protocol.
+Package GoRTP implements the RTP/RTCP protocol.
 
 This Go implementation of the RTP/RTCP protocol uses a set of structures to
 provide a high degree of flexibility and to adhere to the RFC 3550 notation of