Index index by Group index by Distribution index by Vendor index by creation date index by Name Mirrors Help Search

libliveMedia112-2023.11.30-2.1 RPM for riscv64

From OpenSuSE Ports Tumbleweed for riscv64

Name: libliveMedia112 Distribution: openSUSE Tumbleweed
Version: 2023.11.30 Vendor: openSUSE
Release: 2.1 Build date: Sun Mar 3 23:16:16 2024
Group: System/Libraries Build host: i01-ch1d
Size: 1190154 Source RPM: live555-2023.11.30-2.1.src.rpm
Packager: https://bugs.opensuse.org
Url: http://www.live555.com/liveMedia/
Summary: Basic Usage Environment library of live555 streaming media
This code forms a set of C++ libraries for multimedia streaming,
using open standard protocols (RTP/RTCP, RTSP, SIP). These libraries
can be used to build streaming applications

Provides

Requires

License

LGPL-2.1-only

Changelog

* Fri Mar 01 2024 pgajdos@suse.com
  - Use %autosetup macro. Allows to eliminate the usage of deprecated
    %patchN
* Sun Jan 14 2024 Takashi Iwai <tiwai@suse.com>
  - update up to 2023.11.30:
    * In the implementation of the "MPEGVideoStreamFramer" class, gave
      "TimeCode::operator==()" the "const" qualifier, to make some
      compilers happy.
    * Performed the annual update of the copyright years near the start
      of each file
  - update to 2023.11.08:
    * Changed the signature to the virtual function
      "getRTPSinkandRTCP()" (in "ServerMediaSubession", and its subclasses
      "OnDemandServerMediaSession" and "PassiveServerMediaSubsession")
      to make its 'result' arguments "rtpSink" and "rtcp" no longer "const *".
      There was no real reason to make those "const *".
  - update to 2023.11.07:
    * In the class "GenericMediaServer", made the variables
      "fServerMediaSessions",
      "fClientConnections", and "fClientSessions" 'protected' rather
      than 'private', to allow subclasses to access them if desired.
  - update to 2023.10.30:
    * Fixed a bug in "deleteEventTrigger()" that had accidentally been
      introduced during the change to 'event trigger' implementation
      back in June.
  - update to 2023.07.24:
    * Updated the event trigger implementation once again, to allow for
      the possibility of developers redefining MAX_NUM_EVENT_TRIGGERS
      (it must always be <= the number of bits in an "EventTriggerId",
      though.
  - update to 2023.06.20:
    * Updated the event trigger implementation again - in the case where
      "NO_STD_LIB" is defined.  In this case,
      "fTriggersAwaitingHandling" is implemented as an array of "Boolean
      volatile"s, rather than as a 32-bit bitmap.  This should make
      'race conditions' less likely even if "NO_STD_LIB" is defined
      (though you should use the preferred, default implementation -
      that uses an array of "std::atomic_flag"s - if possible).
  - update to 2023.06.16:
    * Changed the (default) implementation of 'event triggers' in
      "BasicTaskScheduler" to implement "fTriggersAwaitingHandling"
      using "std:atomic_flag"s, rather than as a bitmap.
      This should overcome 'race conditions' that some users experienced
      when calling "triggerEvent()" from a non-LIVE555 thread.
    * Note that this is the first time the LIVE555 code has required the
      C++ standard library.
      (If you cannot use the C++ standard library, then you can compile
      the code - but getting the old behavior - by defining "NO_STD_LIB".)
    * Minor change to "RTSPCommon.cpp" to overcome a compilation error
      in XCode on Mac OS X.
  - update to 2023.06.14:
    * Fixed a bug in the Matroska file parsing code that could sometimes
      cause a 'use after free' error. (bsc#1218758, CVE-2023-20573)
  - update to 2023.06.10:
    * Minor change to "GroupsockHelper.cpp" to overcome a compilation
      error in XCode on Mac OS X.
  - update to 2023.06.08:
    * Updated the "dateHeader()" function in "RTSPCommon.cpp" to use
      "gmtime_r()" instead of the older, non-thread-safe "gmtime()".
  - Applied workarounds for the build error with atomic_flag test
* Mon May 29 2023 Dirk Müller <dmueller@suse.com>
  - update to 2023.5.10:
    * Fixed a minor memory leak in the "RTSPServer" code.
    * Calls to "send()" and "sendto()" now explicitly take
      "MSG_NOSIGNAL" rather than 0 as the 'flags' parameter.
      In most systems, 0 seems to work, but apparently not in
      Debian Linux.
* Sat Jan 21 2023 Dirk Müller <dmueller@suse.com>
  - update to 2023.01.19:
    - By default, we no longer compile "groupsock/NetAddress.cpp" for Windows to use
      "gethostbyname()", because of a report that this breaks IPv6 name resolution.
* Mon Jan 16 2023 Dirk Müller <dmueller@suse.com>
  - update to 2023.01.11:
    * Updated the "BasicTaskScheduler"/"DelayQueue" implementation to make the 'token counter'
      a field of the task scheduler object, rather than having it be a static variable.
      This avoids potential problems if an application uses more than one thread (with each thread
      having its own task scheduler).
* Fri Dec 02 2022 Dirk Müller <dmueller@suse.com>
  - update to 2022.12.01:
    - Yet another fix to the previous fix for RTSP-over-HTTP streaming.
    - The previous version's fix to "RTSPClient" (for RTSP-over-HTTP streaming) was incomplete.
      This should fix it for real.
    - Fixed a bug in "RTSPClient" that would cause RTSP-over-HTTP streaming over TLS to
      sometimes fail.  (Thanks to Johannes Gajdosik for reporting this.)
    - Fixed a bug that would cause a RTSP server to use an incorrect URL if it accepted connections
      via TLS, but *without* streaming SRTP.
* Tue Nov 22 2022 Dirk Müller <dmueller@suse.com>
  - update to 2022.11.19:
    - Added a new global variable "ReceivingInterfaceAddr6" (analogous to the existing
      variable "ReceivingInterfaceAddr" for IPv4) to allow applications to optionally
      change the default receiving address for IPv6.
* Sun Oct 02 2022 Dirk Müller <dmueller@suse.com>
  - update to 2022.10.01:
    - Updated the previous revision so that the virtual function "specialHandlingOfAuthenticationFailure()"
      is now called only if there is an actual authentication failure - not on the first time that
      we send back a "401 Unauthorized" response.
    - Added a new virtual function "specialHandlingOfAuthenticationFailure()" to "RTSPServer" to
      allow a subclassed "RTSPServer" to take special action (e.g., statistics logging)
      whenever an authentication failure occurs.
* Fri Jul 22 2022 Dirk Müller <dmueller@suse.com>
  - update to 2022.07.14:
    * use SHA-1 rather than MD5 to hash the latest tarball of our code
* Fri Jun 24 2022 Dominique Leuenberger <dimstar@opensuse.org>
  - 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.
* Wed May 04 2022 Christophe Giboudeaux <christophe@krop.fr>
  - Update to 2022.04.26:
    * Ensure that we don't call "delete[]" on an uninitialized
      pointer.
  - Changes from version 2022.04.15:
    * Fixed a "fprintf()" argument-order-evaluation bug in the
      "mikeyParse" demo application.
  - Changes from version 2022.04.12:
    * Updated the "openRTSP" application (RTSP command-line client)
      to add an option '-L', meaning: receive only an "application"
      (e.g., 'metadata') track, if present, outputting the data to
      'stdout'.
* Tue Feb 15 2022 Dominique Leuenberger <dimstar@opensuse.org>
  - 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).
* Mon Dec 20 2021 Dominique Leuenberger <dimstar@opensuse.org>
  - Update to version 2021.12.18:
    + Fixed a bug in the way that "RTSPClient" handles its two
      separate TCP connections when it does RTSP-over-HTTP.
    + Updated "RTPInterface::sendDataOverTCP()" so that if it's
      necessary to do a blocking send(), we call
      "makeSocketNonBlocking()" immediately after the call to
      "send()".
    + Performed the annual update of the copyright years near the
      start of each file.
* Sat Dec 18 2021 Dirk Müller <dmueller@suse.com>
  - 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.
* Mon Dec 06 2021 Dirk Müller <dmueller@suse.com>
  - 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'.
* Mon Aug 23 2021 Fusion Future <qydwhotmail@gmail.com>
  - 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)
* Thu Aug 12 2021 Fusion Future <qydwhotmail@gmail.com>
  - 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
* Thu Jun 17 2021 tiwai@suse.de
  - 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

/usr/lib64/libliveMedia.so.112
/usr/lib64/libliveMedia.so.112.0.0
/usr/share/licenses/libliveMedia112
/usr/share/licenses/libliveMedia112/COPYING


Generated by rpm2html 1.8.1

Fabrice Bellet, Sat Jul 13 23:22:50 2024