![(please configure the [header_logo] section in trac.ini)](/repos/chrome/site/pj.jpg)
Custom Query (2195 matches)
Results (109 - 111 of 2195)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2155 | fixed | Cleanup call setting flag before sending reinvite on IP change | bennylp | ming |
| Description |
Related to ticket #1793: Avoid unwanted call unhold when sending re-INVITE/UPDATE with call setting param set to NULL The same behavior is observed when sending re-INVITE upon IP change scenario. |
|||
| #2154 | worksforme | Test with Opus 1.3 | nanang | nanang |
| #2152 | fixed | Avoid premature video frame decoding due to RTP reordering | nanang | nanang |
| Description |
Currently video stream will assume a video frame is available and ready to decode when it sees RTP timestamp changing in the jitter buffer (note that RTP packets belong to same a video frame have same RTP timestamp). And when it sees a 'ready' frame, video stream will immediately pull those RTP packets from the JB and start decoding them. Unfortunately such frame availability check method may cause video quality degradation when the network suffers from consistent RTP reordering, e.g: an RTP packet of a newer frame received before the last RTP packets of an older frame, so the video frame will be decoded without one or more RTP packets. This ticket updates the behavior by introducing some delay in video frame decoding. The minimum delay is configurable via PJMEDIA_VID_STREAM_DECODE_MIN_DELAY_MSEC, which by default is 100ms. So video stream will make sure that there should be already few video frames in the JB before start decoding the oldest frame. Thanks Sai Krishna Reddy Kovvuri for the report. |
|||
