Download Document

Cross Layer RTP packets reordering for Single
NAL unit and Non Interleaved modes (not
using CL-DON)
[email protected]
Objectives
First part of this document tries to explain and to trace issues concerning the
method “De-Packetization Process for Session Multiplexing using noninterleaved mode or Single NAL unit mode following classical RTP
mechanisms” explained in section 8.1.1 of document
http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-06#page-27
Second part of this document proposes a different method to address these
issues
All Rights Reserved © Alcatel-Lucent 2006, #####
Current method
Rely on the knowledge of the one-dimensional RTP sessions dependency path
defined in Session Description Protocol (SDP) (doc
http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-00)
How it works ?
 Consider 3 RTP sessions A (S0),B (S1),C (S2)
 C depends on B that depends on A
TS_S0 synchronisation point
TS_S1 synchronisation point
All Rights Reserved © Alcatel-Lucent 2006, #####
Current method
A TS_Sx synchronisation point corresponds to a sampling instant TS (Access
Unit) with at least one RTP packet of timestamp TS in all RTP sessions Sy with
Sy >= Sx.
 i.e. Before proceeding to a TS_S0 synchronisation point, we should test the
presence of a TS_S1 synchronisation point, and before a TS_S1, testing a
TS_S2 and so on…
To order packets of a specific synchronisation point across sessions, packets
are outputed in the order of session dependency, so starting from S0 to S2. If
many RTP packets have same TS inside a RTP sessions, packets are outputed
according to increasing sequence numbers.
All Rights Reserved © Alcatel-Lucent 2006, #####
Current method
Hence the application to the previous example
4
2,3
1
8
6,7
10,11
9
13
12
5
All Rights Reserved © Alcatel-Lucent 2006, #####
Current method
Limitation 1
Hence such scheme is not decodable (because red pkts do not exist)
S2
1
2
S1
1
2
S0
1
2
x
3
4
3
4
5
6
3
4
5
6
5
6
RTP packet of sequence number x
All Rights Reserved © Alcatel-Lucent 2006, #####
Current method
Limitation 2
Network Pkt lost Pkts not outputed/ordered due to current limitation despite well received
 limit capability of H.264 SVC decoder doing error concealment
S2
1
2
3
4
5
6
7
8
9
10
S1
1
2
3
4
5
6
7
8
9
10
S0
1
2
3
4
5
6
Red curve shows the order of packets at output of the SVC RTP receiver
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method
Instead of using the concept of TS_Sx synchronisation points, we rely on the
knowledge of frame rates contained inside each session (using a=framerate
lines in the SDP)
The proposed method is then split in two parts:
1. Search TS of next AU (in decoding order) by reading the TS of next packet
of RTP session containing the highest frame rate
2. Output packets in decoding order across sessions using the order of session
dependency defined in SDP  same process as current method
To handle packet losses, we can refine the first part by not considering RTP
sessions where a packet loss is detected when searching for the session with
highest frame rate  this can be done in a simple iterative process detailed
in next figure
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method (part 1)
TS of current AU in decoding order is found, and will be used as input for second part
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method (part 2)
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method (global view)
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method (application to previous limitations)
Limitation 1:
S2
1
2
S1
1
2
S0
1
2
3
4
3
4
5
6
3
4
7
8
5
6
9
10
5
6
S1 is defined
as Ssync
 All packets are correctly ordered and outputted
Limitation 2:
S2
1
2
3
4
5
6
7
8
9
10
S1
1
2
3
4
5
6
7
8
9
10
S0
1
2
3
4
5
6
Ssync
All packets are correctly ordered and outputted, except network lost packet (of course)
All Rights Reserved © Alcatel-Lucent 2006, #####
Proposed method
How to get the additional knowledge of frame rate per session
 Read it in SDP, thus “a=framerate” lines MUST be present in SDP for each
media/session
 Simplest method
 Knowledge of frame rates per session is immediate, cross layer ordering can be
performed directly after zapping
 Compute frame rate in each session by adding a module analysing the
content of each buffer, and retrieving the frame rate as the inverse of the
minimum TS difference between two packets contained in the buffer
 More complex
 Requiring additional module to compute frame rate
 Knowledge of frame rate is not instantaneous, a buffering period (dependent on
the highest temporal level) should be waited  delay before cross layer ordering
after zapping
 “a=framerate” lines are not required
All Rights Reserved © Alcatel-Lucent 2006, #####