This changes the design of the jitter buffer to keeping track of decodable frames from the point when packets are inserted in the buffer, instead of searching for decodable frames when they are needed.
To accomplish this the frame_list_, which previously contained all frames (incomplete or complete, continuous or not), is split into a list of decodable_frames_ (complete, continuous) and a list of incomplete_frames_ (either incomplete or non-continuous). These frame lists are updated every time a packet is inserted.
This is another step in the direction of doing most of the work in the jitter buffer only once, when packets are inserted, instead of doing it every time we look for a frame or try to get a nack list.
BUG=1798
TEST=vie_auto_test, trybots
R=mikhal@webrtc.org
Review URL: https://webrtc-codereview.appspot.com/1522005
git-svn-id: http://webrtc.googlecode.com/svn/trunk@4104 4adac7df-926f-26a2-2b94-8c16560cd09d
Also fixes a timer bug related to NACKing in the RTP module which could cause packets to only be NACKed twice if there's frequent packet losses.
Note that I decided to remove any selective NACKing for now as I don't think the gain of doing it is big enough compared to the added complexity. The same reasoning for empty packets. None of them will be retransmitted by a smart sender since the sender would know that they aren't needed.
BUG=1420
TEST=video_coding_unittests, vie_auto_test, video_coding_integrationtests, trybots
Review URL: https://webrtc-codereview.appspot.com/1115006
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3599 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
This is a recommit of r3183. Extensive testing suggest that this may have been caused by virtual machine flakiness.
TBR=mflodman@webrtc.org
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/971011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3200 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/929031
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3183 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/966026
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3181 4adac7df-926f-26a2-2b94-8c16560cd09d
