- update to 2022.07.14:
  * use SHA-1 rather than MD5 to hash the latest tarball of our code

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- Update to version 2022.06.16:
  + Both our RTSP client and RTSP server implementations now
    support (optional) RTSP-over-HTTPS streaming, when
    RTSP-over-TLS would otherwise be available.
- Changes from version 2022.06.14:
  + Added optional support (via #ifdefs) to the
    "testOnDemandRTSPServer" demo application for streaming via
    RTSPS (RTSP-over-TLS) and optionally SRTP (encrypted RTP/RTCP).
    To use this, you would need to define SERVER_USE_TLS, and
    PATHNAME_TO_CERTIFICATE_FILE and PATHNAME_TO_PRIVATE_KEY_FILE.

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

Update to 2022.04.26

• Files Changed
• Browse Source

- Update to version 2022.02.07:
  + Updated the SRTP packet sending code in "MultiFramedRTPSink.cp"
    to not allocate a variable-sized buffer on the stack, because
    some compilers can't handle this.
  + Ensure that RTSP servers that serve SRTP do not also support
    streaming over the TCP connection, because that would add extra
    overhead for no benefit.
- Changes from version 2022.01.21:
  + Fixed a bug in the "groupsock" library that could cause
    outgoing RTP packets to get duplicated when a RTSP "PLAY"
    command is sent after a "PAUSE".
- Changes from version 2022.01.20:
  + More updates to the code for optional server SRTP streaming.
- Changes from version 2022.01.17:
  + More updates to the code in preparation for optional server
    SRTP streaming.
- Changes from version 2022.01.11:
  + Fixed a minor memory leak in "RTSPClient" when receiving a SRTP
    stream.
  + Updates to "RTPSink" in preparation for optional server SRTP
    streaming.
- Changes from version 2022.01.06:
  + Made "GenericMediaServer::addServerMediaSubsession()" a virtual
    function, and redefine it in the subclass "RTSPServer" to call
    the base function, then set the "ServerMediaSubsession"s
    "streamingIsEncrypted" flag (if the RTSP server is streaming
    SRTP).

• Files Changed
• Browse Source

Udpate to 2021.12.18

• Files Changed
• Browse Source

- update to 2021.12.07:
  - Added #ifndef NO_OPENSSL/#endif around "#include <openssl/err.h>" in
    "liveMedia/TLSState.cpp", so that the code will compile if you're compiling
    with no OpenSSL headers, and NO_OPENSSL
    defined.

• Files Changed
• Browse Source

- update to 2021.11.23:
  * Updated the "RTSPServer::setTLSState()" function to take an optional
    parameter "weServeSRTP".  For now, the default value of this parameter is
    False, but it will get changed to True later, when we implement server-side
    SRTP.
  * Updated the RTSP server implementation to (optionally) support connections via TLS.
  * Updated the "TLSState" interface and implementation to (1) reduce the
    amount of stuff that the compiler gets to see if you're compiling with
    NO_OPENSSL defined, and (2) add a new subclass "ServerTLSState" that
    will eventually be used to implement optional TLS connections to our RTSP server. 
  * Split the "TLSState" class into two classes: "TLSState" (an abstract base
    class), and "ClientTLSState" (a subclass).  This is in preparation for later defining
    second subclass "ServerTLSState" that will eventually be used to implement TLS connections
    in our RTSP server.
  * Updated the implementation of AES encryption/decryption (used by our client SRTP
    implementation) to use the new OpenSSL EVP interface.  This makes it possible to
    use hardware acceleration (e.g., AES-NI), when it is available.
  * Updated the "RTSPClient"s implementation of receiving RTP/RTCP-over-TCP so
    that it will also work over a RTSP-over-TLS (including RTSPS) connection.
  * Fixed a bug in "MatroskaFileParser" that could cause delivery of data to a downstream object
    that wasn't expecting it (potentially causing an invalid memory access).
  * The final (I hope!) update to eliminate a "depends on uninitialised value"
    report from 'valgrind'.

• Files Changed
• Browse Source

- Update to 2021.08.23:
  * Updated the "readSocket()" code in "GroupsockHelper.cpp" yet
    again to try to eliminate another (alleged) "depends on
    uninitialised value" report from 'valgrind'.
    (If, after this, you still see this, then your implementation
    of "recvfrom()" is broken.)
- Changes in 2021.08.19:
  * Updated the "readSocket()" code in "GroupsockHelper.cpp" to
    eliminate another possible "depends on uninitialised value"
    report from 'valgrind'.
- Changes in 2021.08.18:
  * Updated the "readSocket()" code in "GroupsockHelper.cpp" to
    eliminate a "depends on uninitialised value" report from
    'valgrind'.
- Changes in 2021.08.17:
  * Updated the 'groupsock' "setPortNum()" function to not rely
    upon the "ss_family" family field, in case it's uninitialized.
- Changes in 2021.08.14:
  * Fixed a minor bug in the previous release ("delete" should have
    been "delete[]")
- Changes in 2021.08.13:
  * Fixed a bug in "MPEG1or2Demux" that could cause a 'reading
    twice at the same time" abort when streaming from a MPEG
    Program Stream file. (boo#1189726, CVE-2021-39283)
  * Fixed a potential memory leak in "AC3AudioStreamFramer".
    (boo#1189725, CVE-2021-39282)

• Files Changed
• Browse Source

- Update to 2021.08.09:
  - Fixed a bug in the MPEG-1 or 2 file server demultiplexors that 
    could cause a RTSP server to crash if it received successive 
    RTSP "SETUP" commands for the same track. (Thanks to Ba 
    Jinsheng for reporting this.)(boo#1189352, CVE-2021-38381)
- Update to 2021.08.06:
  - Fixed a bug in the Matroska and Ogg file server demultiplexors 
    that could cause a RTSP server to crash if it received 
    successive RTSP "SETUP" commands for the same track.  (Thanks 
    to Ba Jinsheng for reporting this.)(boo#1189353, CVE-2021-38382)
- Update to 2021.08.04:
  - In the "MP3FileSource" implementation, we no longer do a 
    recursive call to "doEventLoop()" when attempting to 
    synchronously read from a MP3 file.  This avoids a possible 
    stack overflow in the RTSP server if multiple concurrent 
    requests are made. (Thanks to Ba Jinsheng for reporting this.)  
    The server still does some synchronous reads, when 
    initializing, and when parsing MP3 frame headers. This should 
    be fixed sometime in the future. (boo#1189351, CVE-2021-38380)
- Update to 2021.07.20:
  - If a "RTSPClient" receives a response to a RTSP "PLAY" that 
    changes the 'scale()' or 'speed()' of the whole session, then 
    those parameters also need to be changed in each subsession (as 
    that inheritance doesn't happen automatically). (Thanks to a 
    developer in China for reporting this.)
- Update to 2021.07.10:
  - Updated "H264or5VideoStreamFramer.cpp" once again to set the 
    default value of "DeltaTfiDivisor" to 2.0 for H.265, and 1.0 
    for everything else.  (This fixes the frame rate for another 
    stream supplied by Paul Westlund.)
- Update to 2021.06.29:
  - In the proxy server implementation, if a client closes one 
    substream, but there are still other clients receiving other 
    substream(s), then we no send a single-track RTSP "PAUSE" 
    command downstream, because some back-end servers might handle 
    that by pausing all tracks of the stream.  So now, in this 
    case, we don't send a RTSP "PAUSE" command at all. (Thanks to 
    Jose Maria Infanzon for noting this issue.)
- Update to 2021.06.25:
  - Updated "H264or5VideoStreamFramer.cpp" to set the default value 
    of "DeltaTfiDivisor" to 1.0 (rather than 2.0), and to assume a 
    frame rate of 30 fps (rather than 25 fps) if there is no VPS or 
    SPS NAL unit that specifies a different frame rate.  This seems 
    to work the best for most raw H.264 and H.265 video streams.  
    (Thanks to Paul Westlund for supplying an example file to 
    motivate this.)
- Change the so version of libliveMedia to 97

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- Update to 2021.05.22:
  lots of fixes and updates, including the security fix for
  CVE-2021-28899 boo#1185874
  See the list in http://live555.com/liveMedia/public/changelog.txt
- Change the so version of libliveMedia to 94, libgroupsock to 30

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- update to 2020.10.16:
  - Changed "TLSState::read()" to treat any "SSL_read()" result of <=0 as if the
    TLS connection has closed (unless the error was SSL_ERROR_WANT_READ).
    This fixes a problem that could cause 100% CPU usage in RTSP client applications.
    (Thanks to Larry Wu for reporting this.)
  - Updated "TLSState::setup()" to use "TLS_client_method()" instead of the (deprecated)
    "SSLv23_client_method()".

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

- update to 2020.08.19:
  - Fixed a bug in "QuickTimeFileSink" that could cause malformed "esds" atoms to be
    generated.  (Thanks to Chris Paucar for reporting this issue.)
  - In "MPEG2TransportStreamFromESSource.cpp", changed the name of the constant LOW_WATER_MARK
    to TS_FROM_ES_LOW_WATER_MARK, and "#ifndef"d it, so that, if you wish, you can redefine it
    at compile time.
  - Fixed a bug in the handling of pausing, when streaming from (multi-track) Matroska files.
  - Fixed another bug in the handling of seeking within Matroska files.
  - Fixed a bug in the handling of seeking within Matroska files.
    (Thanks to Jim Ham for reporting this problem.)
  - Changed the parameter signature of the "RawVideoRTPSink" constructor and "createNew()"
    functions so that the "width" parameter comes before the "height" parameter.  This order
    - "width", "height" - is more common, and is the order used when these parameters are
    defined in RFC 4175.
    IMPORTANT NOTE: Because the types of these two parameters are the same, existing application
    code that uses "RawVideoRTPSink" will compile without error; however, it will not work
    properly unless the order of the parameters in the call to "RawVideoRTPSink::createNew()"
    is changed.
  - More cleanup of the implementation of "RawVideoRTPSink".
  - Cleaned up the implementation of "RawVideoRTPSink".
  - Updated the "RawVideoRTPSource" implementation to not set "fCurrentPacketCompletesFrame"
    until we are processing the last line in the packet.
    (Thanks to Andrey Lisovoy for reporting this issue.)
  - Fixed a potential buffer overflow bug in the server handling of a RTSP "PLAY" command,
    when the command specifies seeking by absolute time.
    (Thank to Xiaobo Xiang for reporting this.)
  - Fixed a memory leak in the "sha1()" function (a "EVP_MD_CTX" object was not being deleted).
    (Thanks to Amir Perlman for reporting this.)
  - Moved all definitions of PREFIX from "Makefile.tail" files to "Makefile.head" (so that
    it can be redefined by a "config.*" file, if desired.

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source

Update to 2020.05.15

• Files Changed
• Browse Source

baserev update by copy to link target

• Files Changed
• Browse Source