Skip to content

Commit 81a11d8

Browse files
j0r1j0r1
committed
Added some files from internal repository
1 parent 05abf50 commit 81a11d8

File tree

3 files changed

+287
-0
lines changed

3 files changed

+287
-0
lines changed

‎aboutrfc3550.txt

Lines changed: 177 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,177 @@
1+
* p 9 (bottom):
2+
In the unicast case, a participant may
3+
receive from all other participants in the session using the same
4+
pair of ports, or may use a distinct pair of ports for each.
5+
6+
COMMENT:
7+
By default, a RTPSession instance will use only one pair
8+
of ports.
9+
10+
* p 14 (top):
11+
A profile MAY define additional
12+
marker bits or specify that there is no marker bit by changing the
13+
number of bits in the payload type field (see Section 5.3).
14+
15+
COMMENT:
16+
At the moment, no support for additional marker bits is present
17+
18+
* About payload data and payload types:
19+
The library doesn't inspect payload data or payload types. It is
20+
left to the application using the library to decide if a packet should
21+
be ignored or accepted
22+
23+
* p 18 (middle):
24+
o If a particular class of applications needs additional
25+
functionality independent of payload format, the profile under
26+
which those applications operate SHOULD define additional fixed
27+
fields to follow immediately after the SSRC field of the existing
28+
fixed header. Those applications will be able to quickly and
29+
directly access the additional fields while profile-independent
30+
monitors or recorders can still process the RTP packets by
31+
interpreting only the first twelve octets.
32+
33+
COMMENT:
34+
No direct support for such extensions are provided
35+
36+
* p 20 (bottom):
37+
4. A fourth, OPTIONAL function is to convey minimal session control
38+
information, for example participant identification to be
39+
displayed in the user interface.
40+
41+
COMMENT: SDES info is supported by the library
42+
43+
* p 21 (top):
44+
The
45+
recommendations here accommodate SSM only through Section 6.2's
46+
option of turning off receivers' RTCP entirely.
47+
48+
COMMENT:
49+
For now, the RTCP (sending) will only be disabled entirely
50+
if no destinations are present.
51+
52+
* p 25 (middle):
53+
The profile MAY further specify that the control traffic bandwidth
54+
may be divided into two separate session parameters for those
55+
participants which are active data senders and those which are not;
56+
57+
COMMENT: this will not be implemented
58+
59+
* p 26 (top):
60+
This delay MAY be set to half the
61+
minimum interval to allow quicker notification that the new
62+
participant is present.
63+
64+
COMMENT: is supplied as an option which is enabled by default
65+
66+
* p 26 (middle):
67+
An implementation MAY scale the minimum RTCP interval to a smaller
68+
value inversely proportional to the session bandwidth parameter with
69+
the following limitations:
70+
71+
COMMENT: not supported
72+
73+
* p 28 (middle):
74+
SSRC sampling -> not supported
75+
76+
* p 28 (bottom):
77+
An implementation which is constrained to two-party
78+
unicast operation SHOULD still use randomization of the RTCP
79+
transmission interval to avoid unintended synchronization of multiple
80+
instances operating in the same environment, but MAY omit the "timer
81+
reconsideration" and "reverse reconsideration" algorithms in Sections
82+
6.3.3, 6.3.6 and 6.3.7.
83+
84+
COMMENT: randomization and reconsideration will always be used. omitting
85+
them is not implemented.
86+
87+
* p 28 (top):
88+
New entries MAY be considered
89+
not valid until multiple packets carrying the new SSRC have been
90+
received (see Appendix A.1), or until an SDES RTCP packet containing
91+
a CNAME for that SSRC has been received.
92+
93+
COMMENT: Currently, probation is optional. A source is considered
94+
valid when either a number (depending on probation) of RTP
95+
packets are received or when a CNAME has been received
96+
97+
* p 42 (bottom):
98+
6.4.3 Extending the Sender and Receiver Reports
99+
100+
COMMENT: Extensions of SR and RR are not supported
101+
102+
* p 68 (middle):
103+
RTP relies on the underlying protocol(s) to provide demultiplexing of
104+
RTP data and RTCP control streams. For UDP and similar protocols,
105+
RTP SHOULD use an even destination port number and the corresponding
106+
RTCP stream SHOULD use the next higher (odd) destination port number.
107+
For applications that take a single port number as a parameter and
108+
derive the RTP and RTCP port pair from that number, if an odd number
109+
is supplied then the application SHOULD replace that number with the
110+
next lower (even) number to use as the base of the port pair. For
111+
applications in which the RTP and RTCP destination port numbers are
112+
specified via explicit, separate parameters (using a signaling
113+
protocol or other means), the application MAY disregard the
114+
restrictions that the port numbers be even/odd and consecutive
115+
although the use of an even/odd port pair is still encouraged. The
116+
RTP and RTCP port numbers MUST NOT be the same since RTP relies on
117+
the port numbers to demultiplex the RTP data and RTCP control
118+
streams.
119+
120+
COMMENT: Currently, the transporter only accepts an even portbase.
121+
122+
* p 68-69:
123+
It is RECOMMENDED that layered encoding applications (see Section
124+
2.4) use a set of contiguous port numbers.
125+
126+
COMMENT: No direct support for this using RTPSession, but it can be
127+
constructed in principle using several RTPTransmitter
128+
instances.
129+
130+
* p 69:
131+
A profile MAY specify a framing method to be used even when RTP is
132+
carried in protocols that do provide framing in order to allow
133+
carrying several RTP packets in one lower-layer protocol data unit,
134+
such as a UDP packet.
135+
136+
COMMENT: For UDP, such a framing mechanism will not be implemented
137+
138+
139+
140+
141+
QUESTIONS:
142+
* p 28: after BYE packet, ssrc should be removed after an appropriate delay.
143+
what delay is considered appropriate?
144+
* p 57: why do CNAMEs have to be forwarded to allow SSRC identifier collisions
145+
to work?
146+
-> If the CSRC sources are not senders, their identifiers wont be
147+
seen in the CSRC list of an RTP packet. By forwarding SDES CNAMEs,
148+
their identifiers will be present in the SDES chunk and collisions
149+
can be detected.
150+
* p 64: Section 8.3
151+
* What MTU should be used? Should it be the same for all session members?
152+
Is it the MTU of the protocol just below RTP or of the link layer?
153+
* p 33 (BYE scheduling): Should members be increased for each BYE packet or
154+
for each SSRC in a BYE packet?
155+
156+
* p 35:
157+
RTP receivers provide reception quality feedback using RTCP report
158+
packets which may take one of two forms depending upon whether or not
159+
the receiver is also a sender. The only difference between the
160+
sender report (SR) and receiver report (RR) forms, besides the packet
161+
type code, is that the sender report includes a 20-byte sender
162+
information section for use by active senders. The SR is issued if a
163+
site has sent any data packets during the interval since issuing the
164+
last report or the previous one, otherwise the RR is issued.
165+
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
166+
-> Is this also true when the sender timeout multiplier differs
167+
from 2 ??
168+
169+
* About report blocks: should an entry be made for each SSRC_n in the
170+
list of report blocks if the RR or SR originates from a valid SSRC?
171+
-> probably not, since then we don't have the right transport
172+
address of the SSRC_n
173+
-> Indeed: see p 61 at bottom
174+
175+
* Is it a valid tactic to use a timestamp unit estimation (from
176+
two SRs) for jitter calculation if no exact info is available?
177+

‎builddist.sh

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
#!/bin/bash
2+
3+
VERSION_MAJOR=`cat CMakeLists.txt|grep VERSION_MAJOR | head -n 1 | grep set | head -n 1 |cut -f 2 -d " "|cut -f 1 -d ")"`
4+
VERSION_MINOR=`cat CMakeLists.txt|grep VERSION_MINOR | head -n 1 | grep set | head -n 1 |cut -f 2 -d " "|cut -f 1 -d ")"`
5+
VERSION_DEBUG=`cat CMakeLists.txt|grep VERSION_DEBUG | head -n 1 | grep set | head -n 1 |cut -f 2 -d " "|cut -f 1 -d ")"`
6+
VERSION=$VERSION_MAJOR.$VERSION_MINOR.$VERSION_DEBUG
7+
LIBNAME=jrtplib
8+
9+
TMPDIR=`tempfile`
10+
CURDIR=`pwd`
11+
rm -r $TMPDIR
12+
if ! mkdir $TMPDIR ; then
13+
echo "Couldn't create temporary directory"
14+
exit -1
15+
fi
16+
17+
cd $TMPDIR
18+
TMPDIR=`pwd` # Get the full path
19+
cd $CURDIR
20+
21+
if ! git archive --format tar --prefix=${LIBNAME}-${VERSION}/ HEAD | (cd $TMPDIR && tar xf -) ; then
22+
echo "Couldn't archive repository"
23+
exit -1
24+
fi
25+
26+
cd $TMPDIR/${LIBNAME}-${VERSION}
27+
28+
rm -f `find . -name ".git*"`
29+
rm -f builddist.sh
30+
rm -rf sphinxdoc
31+
rm -f TODO
32+
rm -rf nodist
33+
rm -f aboutrfc3550.txt
34+
35+
cd ..
36+
37+
if ! tar cfz ${LIBNAME}-${VERSION}.tar.gz ${LIBNAME}-${VERSION}/ ; then
38+
echo "Couldn't create archive"
39+
exit -1
40+
fi
41+
42+
if ! tar cfj ${LIBNAME}-${VERSION}.tar.bz2 ${LIBNAME}-${VERSION}/ ; then
43+
echo "Couldn't create archive"
44+
exit -1
45+
fi
46+
47+
if ! zip ${LIBNAME}-${VERSION}.zip `find ${LIBNAME}-${VERSION}/` ; then
48+
echo "Couldn't create archive"
49+
exit -1
50+
fi
51+
52+
mv $TMPDIR $CURDIR/
53+
54+

‎visual_studio_jthread_jrtplib_compilation.txt

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
To build JThread and JRTPLIB, you'll need to use 'cmake' to generate
2+
the project files. Below you can find the procedure you can follow.
3+
I've also created a screencast which illustrates the steps in making
4+
the library. You can try one of these files (it's the same file, in
5+
different video formats):
6+
7+
http://research.edm.uhasselt.be/jori/jthread_jrtplib_example_mpeg1.mpg
8+
http://research.edm.uhasselt.be/jori/jthread_jrtplib_example_mpeg2.mpg
9+
http://research.edm.uhasselt.be/jori/jthread_jrtplib_example.avi
10+
11+
In words you'll need to do the following. As an example, I'll assume
12+
that jrtplib is extracted into c:\projects\jrtplib-3.9.1 and jthread
13+
is in c:\projects\jthread-1.3.1
14+
15+
First we'll build jthread. Start the CMake gui and enter
16+
c:\projects\jthread-1.3.1 as the source directory and
17+
c:\projects\jthread-1.3.1\build as the build directory. Then,
18+
before doing anything else, you'll need to specify where the library
19+
should be installed. I always use c:\local as the prefix, which will
20+
install the headers in c:\local\include and the libraries in
21+
c:\local\lib. To do this, add the cmake variable
22+
CMAKE_INSTALL_PREFIX and set it to c:\local
23+
24+
Then, press 'configure'. When this first configure step is complete,
25+
press 'configure' again, and afterward press 'generate'. There you can
26+
specify to generate a visual studio project. When this is done, open
27+
the visual studio project (you can find it in
28+
c:\projects\jthread-1.3.1\build) and run the 'INSTALL' project.
29+
When this is done, select the 'release' build type, and run the
30+
'INSTALL' project again. If all went well, you should find the
31+
jthread headers in c:\local\include\jthread, and the jthread library
32+
in c:\local\lib.
33+
34+
Then, follow the exact same procedure for jrtplib. By using the same
35+
installation prefix (c:\local in my example), the cmake script will
36+
automatically detect jthread as well. After building and installing
37+
jrtplib, you should find that the examples are built as well, and
38+
that you can run them.
39+
40+
To use jrtplib and jthread in another project, you must then do the
41+
following:
42+
- in the project settings, add the include directory
43+
c:\local\include to the list of include directories (for debug and
44+
release builds)
45+
- in the project settings, add c:\local\lib to the list of library
46+
directories.
47+
- for the release version, add jrtplib.lib, jthread.lib and
48+
ws2_32.lib to the list of libraries
49+
- for the debug version, add jrtplib_d.lib, jthread_d.lib and
50+
ws2_32.lib to the list of libraries.
51+
52+
In your program files, include a jrtplib header like this:
53+
#include <jrtplib3/rtpsession.h>
54+
and a jthread header like this:
55+
#include <jthread/jthread.h>
56+

0 commit comments

Comments
 (0)