summaryrefslogtreecommitdiffstats
path: root/osdep/atomic.h
Commit message (Collapse)AuthorAgeFilesLines
* atomic: add mp_atomic_uint64wm42019-11-291-0/+2
|
* demux: support for some kinds of timed metadatawm42018-04-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes ICY title changes show up at approximately the correct time, even if the demuxer buffer is huge. (It'll still be wrong if the stream byte cache contains a meaningful amount of data.) It should have the same effect for mid-stream metadata changes in e.g. OGG (untested). This is still somewhat fishy, but in parts due to ICY being fishy, and FFmpeg's metadata change API being somewhat fishy. For example, what happens if you seek? With FFmpeg AVFMT_EVENT_FLAG_METADATA_UPDATED and AVSTREAM_EVENT_FLAG_METADATA_UPDATED we hope that FFmpeg will correctly restore the correct metadata when the first packet is returned. If you seke with ICY, we're out of luck, and some audio will be associated with the wrong tag until we get a new title through ICY metadata update at an essentially random point (it's mostly inherent to ICY). Then the tags will switch back and forth, and this behavior will stick with the data stored in the demuxer cache. Fortunately, this can happen only if the HTTP stream is actually seekable, which it usually is not for ICY things. Seeking doesn't even make sense with ICY, since you can't know the exact metadata location. Basically ICY metsdata sucks. Some complexity is due to a microoptimization: I didn't want additional atomic accesses for each packet if no timed metadata is used. (It probably doesn't matter at all.)
* osdep/atomic: add emulation for atomic_exchange()wm42018-02-281-0/+7
|
* osdep/atomic: fix potential shadowing warningswm42018-02-281-8/+8
| | | | | | | The stdatomic emulation adds "_" to each variable used inside the macros, to avoid that compilers print -Wshadow warnings for identifiers that are also used in surrounding code. Do this more consistently, because new warnings have been showing up.
* ao: simplify hack for float atomicswm42017-11-301-0/+3
| | | | | | | stdatomic.h defines no atomic_float typedef. We can't just use _Atomic unconditionally, because we support compilers without C11 atomics. So just create a custom atomic_float typedef in the wrapper, which uses _Atomic in the C11 code path.
* atomic: remove __atomic builtin usagewm42017-02-131-30/+7
| | | | | | | | Using these was a temporary solution while some compilers implemented the underlying atomic mechanisms, but not the C11 language parts (or that's what I guess). Not really useful for us anymore. Also, there is the slight risk of having subtly incorrect semantics by using potentially changing compiler internals and such.
* atomic: drop __sync builtinswm42017-01-271-19/+0
| | | | | | | | | | The correctness of the stdatomic.h emulation via the __sync builtins is questionable, and we've been relying on exact stdatomic semantics for a while, so just get rid of it. Compilers which support __sync but not stdatomic.h will use to the slow mutex fallback. Not sure about the __atomic builtins. It doesn't seem to harm either, so leave it for now.
* osdep: rename atomics.h to atomic.hwm42016-09-071-0/+132
The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.