live555
No description set
- Devel package for openSUSE:Factory
-
6
derived packages
- Links to openSUSE:Factory / live555
- Download package
-
Checkout Package
osc -A https://api.opensuse.org checkout multimedia:libs/live555 && cd $_
- Create Badge
Refresh
Refresh
Source Files
Filename | Size | Changed |
---|---|---|
live.2023.11.30.tar.gz | 0000689042 673 KB | |
live555-fpic.patch | 0000000491 491 Bytes | |
live555.changes | 0000081698 79.8 KB | |
live555.spec | 0000005892 5.75 KB |
Revision 74 (latest revision is 78)
Takashi Iwai (tiwai)
accepted
request 1138554
from
Takashi Iwai (tiwai)
(revision 74)
- 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. (Thanks to Jan Rørgaard Hansen for this suggestion.) - 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
Comments 0