[SCM] liblivemedia/master: Update upstream ChangeLog

Tue Nov 30 22:09:33 UTC 2010

The following commit has been merged in the master branch:
commit afc9fb081cb2f86e32adb119f001015af109a188
Author: Benjamin Drung <bdrung at ubuntu.com>
Date:   Tue Nov 30 22:58:36 2010 +0100

    Update upstream ChangeLog

diff --git a/debian/upstream.changelog b/debian/upstream.changelog
index 0e38ae6..37a007e 100644
--- a/debian/upstream.changelog
+++ b/debian/upstream.changelog
@@ -1,3 +1,61 @@
+2010.11.17:
+- Added new a member function "setAuthenticationDatabase()" to "RTSPServer".  This allows a server's manager to change
+  (or disable) authentication at runtime.  (Thanks to Jeremy Norling for suggesting this functionality.)
+
+2010.11.10:
+- Fixed "openRTSP" to eliminate a recursive call to "shutdown()" if we receive a RTCP "BYE" while in the middle of doing
+  a RTSP "TEARDOWN" command.  (Thanks to David Cailliere for noting this issue.)
+
+2010.11.09:
+- The previous release had accidentally included some experimental changes to "H264VideoStreamFramer" that were not (yet)
+  intended to see the light of day.
+
+2010.11.08:
+- Fixed a minor problem with RTSP-over-HTTP support in "RTSPClient" that was causing some servers to complain due to the
+  "CSeq:" header value not being incremented properly.  (Thanks to Kamil Dobkowski for the report.)
+
+2010.11.04:
+- Backed out and corrected the change to "RTSPClient" that we made in version 2010.10.22.  It turns out that existing RTSP-over-HTTP
+  servers that return "401 Unauthorized" in response to the HTTP "GET" *do*, in fact, want clients to resend the "GET" command
+  (with a filled-in "Authorization:" header).  However, at least one such server out there closes the TCP connection after
+  sending back the "401 Unauthorized" response, so we need to send the second "GET" command using a new TCP connection.
+  (Thanks to Kamil Dobkowski for providing access to a server that illustrated this problem.)
+
+2010.10.28:
+- Updated "JPEGVideoRTPSource" amd "JPEGVideoRTPSink" to support optional "Restart Marker Headers" in the outgoing RTP packet.
+  (We already supported such headers in *incoming* JPEG/RTP packets ("JPEGVideoRTPSource").)
+  If "type()" (defined by the "JPEGVideoSource" subclass) returns a value in [64,127], then the "JPEGVideoSource" subclass must
+  also redefine "restartInterval()" to return a non-zero value.
+  (Thanks to Cristiano Belloni for suggesting this addition.)
+
+2010.10.23a:
+- Fixed a bug in the way that "RTSPClient" generates ephemeral RTP/RTCP port number pairs for use when receiving unicast
+  RTSP/RTP streams.  The RTP (even) port was guaranteed not to be in use elsewhere on the same host, but that guarantee was not
+  necessarily true for the RTCP (next, i.e. odd) port.  This version fixes this.
+
+2010.10.23:
+- Our server implementation of "RTSP-over-HTTP tunneling" now allows for the possibility of receiving data from the 
+  (Base-64-encoded) initial RTSP command at the same time that we receive the HTTP "POST" command.  (This is a possibility because
+  the client does not wait for a response to the "POST" - because there isn't one.)
+
+2010.10.22:
+- Made a minor modification to the way that "RTSPClient" does "RTSP-over-HTTP tunneling".  If the initial "GET" request
+  returns "401 Unauthorized", then we don't resend it (with an "Authorization:" header).
+  Instead, we continue, as normal, sending the subsequent HTTP "POST" (with an "Authorization:" header).
+  It's not clear (from the limited documentation on "RTSP-over-HTTP tunneling") which behavior is 'correct', but at least some
+  servers seem to handle the new approach better.
+
+2010.10.20:
+- Made the implementation of 'RTSP-over-HTTP tunneling' in the RTSP server more tolerant of certain buggy clients.
+  (Thanks to Cristiano Belloni for this suggestion.)
+
+2010.10.15:
+- Added server support for RTSP/RTP-over-HTTP tunneling.  We added a new "RTSPServer" member function
+      Boolean setUpTunnelingOverHTTP(Port httpPort);
+  to (attempt to) set up tunneling on the specified HTTP port number.
+  We also updated the "testOnDemandRTSPServer" and "live555MediaServer" applications to try to set up HTTP tunneling
+  on port 80, then port 8000, and then finally port 8080.
+
 2010.10.06:
 - Made a small change to "RTSPClient" to make it better handle RTSP servers that
   erroneously do not include "CSeq:" lines in their responses.
@@ -263,7 +321,7 @@
 
 2009.09.04:
 - Fixed "BasicTaskScheduler"s workaround to a Windows bug (thanks to Vityusha Vinokurov).
-- Fixed "DelayQueue::synchronize()" to allow for the possibility of the system clock beinf reset back in time.
+- Fixed "DelayQueue::synchronize()" to allow for the possibility of the system clock being reset back in time.
   (Thanks to Sebastien Escudier for pointing out this issue.)
 - Made "H264VideoRTPSink::auxSDPLine()" "protected:" rather than "private:" (following a request from Stuart Rawling)
 

-- 
liblivemedia packaging

