summaryrefslogtreecommitdiffstats
path: root/player/core.h
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-09-29 01:39:17 +0200
committerwm4 <wm4@nowhere>2019-09-29 01:41:19 +0200
commita604dc12be13af547572f18b9e09222eeda193c9 (patch)
treed8ebf6119415ed5dafa7996a0cfa4ed7265c4cf2 /player/core.h
parent2bb5ab07b7ee09fb7ae0e90a74c1e8e5adcc3d59 (diff)
downloadmpv-a604dc12be13af547572f18b9e09222eeda193c9.tar.bz2
mpv-a604dc12be13af547572f18b9e09222eeda193c9.tar.xz
recorder: don't use a magic index for mp_recorder_get_sink()
Although this was sort of elegant, it just seems to complicate things slightly. Originally, the API meant that you cache mp_recorder_sink yourself (which would avoid the mess of passing an index around), but that too seems slightly roundabout. In a later change, I want to change the set of streams passed to mp_recorder_create(), and then I'd have to keep track of the index for each stream, which would suck. With this commit, I can just pass the unambiguous sh_stream to it, and it will be guaranteed to match the correct stream. The disadvantages are barely worth discussing. It's a new linear search per packet, but usually only 2 to 4 streams are active at a time. Also, in theory a user could want to write 2 streams using the same sh_stream (same metadata, just writing different packets or so), but in practice this is never done.
Diffstat (limited to 'player/core.h')
0 files changed, 0 insertions, 0 deletions