rohc team mailing list archive

[Didier Barvaux <question269935@xxxxxxxxxxxxxxxxxxxxx>]

Question #269935 on rohc changed:
https://answers.launchpad.net/rohc/+question/269935

    Status: Open => Answered

Didier Barvaux proposed the following answer:
Hello,

OK, I now understand your objective and the problem that you are facing.

The "bad" compression efficiency is due to your RTP stream. The RTP
profile of the ROHC protocol is optimized for RTP streams with SN and TS
fields increasing at a regular pace. If those fields behaves in a non-
deterministic way, the compression works but results in a smaller
compression ratio.

A RTP stream that is "easy" to compress efficiently is as follow:
  packet #1: SN=1  / TS=M+1*N
  packet #1: SN=2  / TS=M+2*N
  packet #3: SN=3  / TS=M+3*N
  ...
If SN increases by one and TS is a function of SN, then the ROHC library can only transmit some bits of SN and can deduce the full SN value and the TS value from those bits.

When you generate your RTP stream, the SN value seems to be incremented by 256 and the TS value only seldom changes (1 per second):
   [scaled_rtp_ts.c:175 c_add_ts()] SN delta = 256
   [scaled_rtp_ts.c:187 c_add_ts()] TS delta = 0

Change your program to increment the SN by 1 for every new packet
(probably an endianness problem, use htons() to convert your value
before putting it in the RTP header). Also change your program to
increment the TS value by a constant value for every new packet.

Regards,
Didier

-- 
You received this question notification because you are a member of ROHC
Team, which is an answer contact for rohc.