The Reconnect feature of helix has been rewritten. The new 'version' uses a single buffer to store data across connections (STREAM_INFO.m_pPosReconnectEventList), and two variables to keep track of where to seek to in a new stream (STREAM_INFO.m_ulHighestTS, STREAM_INFO.m_ulLargestGap). A method updates the highest timestamp and largest gap before inserting a packet into the pos reconnect event list. (Possibly need to reset these values after a seek by the player, or they will get unwanted results in a migration!) Synchronisation between two streams is performed as follows: In the request for the media from the new source, seek to (highest TS - largest gap) to ensure we have two overlapping packets. Once these have been seen (and thrown away), all data coming on the stream is a continuation of the media at the point left off from the old stream.
[10579] : updated ts : [10605] : updated ts : [10631] : updated ts : [10657] : updated ts : [10684] : updated ts : Attempting reconnection Lets seek for [10657] based on a lowest ts[10684] and larg gap [27] Finished handleReconnect() hxr_no_data hxr_no_data hxr_no_data hxr_no_data hxr_no_data hxr_no_data hxr_no_data hxr_no_data hxr_no_data Received play repsonse! hxr_no_data Ignoring an evil packet (10657) Ignoring an evil packet (10683) hxr_no_data Reconnection finished. [10710] : updated ts : [10736] : updated ts : [10762] : updated ts : [10788] : updated ts :
This is a BAD solution to the problem we're addressing. The underlying transport buffer is what needs to be made available across connections. This solution, as implemented by the helix client buffers 0 data packets for the switch, while my modifications can get at most ~4packets saved. The underlying network-jitter-fixer-buffer is more or less thrown away. To a large extent i believe this should all be shoved up if the connection is lost, synchronising at the same point as before, but using a set for the packets.