Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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, #####