Opened 17 years ago
Closed 16 years ago
#439 closed defect (fixed)
Encoder is called for FRAME_TYPE_NONE
Reported by: | bennylp | Owned by: | bennylp |
---|---|---|---|
Priority: | normal | Milestone: | release-0.9.0 |
Component: | pjmedia | Version: | trunk |
Keywords: | Cc: | ||
Backport to 1.x milestone: | Backported: |
Description
Ticket #56 makes stream.c calls codec's encode() even when FRAME_TYPE_NONE is given. This is done by replacing FRAME_TYPE_NONE with a zero frame.
Unfortunately speex doesn't like zero frame to be fed if previously it has encoded non-zero frame. This will cause CPU utilization to get as high as 80% (in a 2.4GHz P4) and makes decoding sounds awful.
Change History (4)
comment:1 Changed 17 years ago by bennylp
- Resolution set to fixed
- Status changed from new to closed
comment:2 Changed 17 years ago by bennylp
- Summary changed from Speex encoder doesn't like zero frame to Encoder is called for FRAME_TYPE_NONE
comment:3 Changed 16 years ago by bennylp
- Resolution fixed deleted
- Status changed from closed to reopened
It seems that the CPU problem has been fixed in Speex, we can re-enable this feature again. And I've seen some server stops sending RTP if we are not sending RTP (!).
comment:4 Changed 16 years ago by bennylp
- Resolution set to fixed
- Status changed from reopened to closed
Done in r2020:
- Re-enable the feature in ticket #56 (disable VAD initially, and transmit RTP periodically on silence).
- implement RTCP SDES and CNAME transmission (explained in ticket #546)
- fixed bug in RTCP TX interval
- changed PJMEDIA_CODEC_MAX_SILENCE_PERIOD value from timestamp to msec so that the period is consistent among codecs. Default now is 500ms rather than 1s.
Note: See
TracTickets for help on using
tickets.
In r1667: