mirror of
https://github.com/mpv-player/mpv
synced 2024-12-23 07:12:39 +00:00
f9ba1a3ddf
The demuxer infrastructure was originally single-threaded. To make it suitable for multithreading (specifically, demuxing and decoding on separate threads), some sort of tripple-buffering was introduced. There are separate "struct demuxer" allocations. The demuxer thread sets the state on d_thread. If anything changes, the state is copied to d_buffer (the copy is protected by a lock), and the decoder thread is notified. Then the decoder thread copies the state from d_buffer to d_user (again while holding a lock). This avoids the need for locking in the demuxer/decoder code itself (only demux.c needs an internal, "invisible" lock.) Remove the streams/num_streams fields from this tripple-buffering schema. Move them to the internal struct, and protect them with the internal lock. Use accessors for read access outside of demux.c. Other than replacing all field accesses with accessors, this separates allocating and adding sh_streams. This is needed to avoid race conditions. Before this change, this was awkwardly handled by first initializing the sh_stream, and then sending a stream change event. Now the stream is allocated, then initialized, and then declared as immutable and added (at which point it becomes visible to the decoder thread immediately). This change is useful for PR #2626. And eventually, we should probably get entirely of the tripple buffering, and this makes a nice first step. |
||
|---|---|---|
| .. | ||
| cmd_list.c | ||
| cmd_list.h | ||
| cmd_parse.c | ||
| cmd_parse.h | ||
| event.c | ||
| event.h | ||
| input.c | ||
| input.h | ||
| ipc.c | ||
| keycodes.c | ||
| keycodes.h | ||
| pipe-win32.c | ||