Displaying 4 results from an estimated 4 matches for "lost_count".
Did you mean:
list_count
2008 Apr 09
3
Jitter Buffer fix for frozen sender
...following condition:
- The sender and receiver are in sync.
- The sender machine freezes for a few seconds while the receiver does not.
- This causes all the packets sent by the sender to have a timestamp
that is too low to be considered, meaning jitter_buffer_put ditches it
before it checks if lost_count > 20 to reset.
- The jitter buffer will never reset on its own and will discard all
incoming packets.
The patch moves the check for lost_count > 20 before the check if the
packet is "hopelessly late". If lost_count > 20, something is very wrong
and we want this packet to be t...
2008 Apr 11
0
Jitter Buffer fix for frozen sender
...> - The sender and receiver are in sync.
> - The sender machine freezes for a few seconds while the receiver does not.
> - This causes all the packets sent by the sender to have a timestamp
> that is too low to be considered, meaning jitter_buffer_put ditches it
> before it checks if lost_count > 20 to reset.
> - The jitter buffer will never reset on its own and will discard all
> incoming packets.
>
> The patch moves the check for lost_count > 20 before the check if the
> packet is "hopelessly late". If lost_count > 20, something is very wrong
> and...
2009 Apr 22
0
Error in manual and a suggestion
...t to 2048. So actually there should just
be inserted the statement: packet.len = 2048;
?
This has been done in the code, but is not reflected in the manual.
?
?
Another thing is if I may and that is to suggest a functionallity to the
speex specific jitter buffer which would be a
int?get_consequtive_lost_count() or bool is_reset() which would simple
deal with with the lost_count variable in the jitter_buffer (not speex
specific) and either return the lost_count value or return a value
indicating wether it is higher than the value used to reset the
jitter_buffer (think its 20 atm).
?
The reason Im suggest...
2005 Sep 04
1
DTX mode using preprocessor?
> Hi,
>
> It could (and should) definitely be done, but it's somewhere
> (unfortunately not on top) on my TODO list. I think the simplest way
> (until I really integrate the preprocessor with the codec, which will
> take a while) to do it is to add a speex_encoder_ctl() call as you
> proposed. I'd call it SPEEX_SET_EXT_VAD_STATUS and I'm willing to merge
> a