| Crates.io | playlists |
| lib.rs | playlists |
| version | 0.1.3 |
| created_at | 2025-03-04 01:55:40.66843+00 |
| updated_at | 2026-01-04 17:04:34.698154+00 |
| description | M3u8 playlist and ring buffers |
| homepage | |
| repository | https://github.com/wavey-ai/playlists |
| max_upload_size | |
| id | 1576631 |
| size | 67,977 |
This crate offers a high-throughput, lock-efficient ring buffer for Low-Latency HLS (LL-HLS) segments and any other workload that needs to push and read binary packets with minimal contention.
Components
bytes::Bytes slotsAll code is asynchronous (Tokio), uses only RwLock plus atomics, and performs no blocking I/O.
ChunkCache layout num_playlists × max_segments × max_parts_per_segment slots slot = size(u32) | hash(u64) | payload
M3u8Cache layout identical shape, but payload is gzip-compressed playlist data
• Each playlist gets its own ring buffer; unrelated playlists never block each other. • Writes lock exactly one slot; reads take shared locks and can run in parallel. • All indices (last_seg, last_part, idxs) are AtomicUsize.
ChunkCache stores raw bytes::Bytes. The cache never parses or validates the
content, so it can be reused for protobuf blobs, encrypted chunks, telemetry
frames, or any other byte slice.
Operation Complexity Details append / add O(1) one atomic + one write-lock get / last O(1) one atomic + one read-lock playlist rollover O(S) zero-fill S = max_segments × max_parts_per_segment
Single-stream sequential writes:
Slot size: 64 KB
Throughput: ~1390 MB/s
Concurrent multi-stream (8 streams, 1 writer + 2 readers each):
Write: 1864 MB/s (29,827 ops/s)
Read: 3966 MB/s (63,461 ops/s)
Combined: 5830 MB/s
Massive concurrent reads (1000 readers, 1 writer):
Read: 22.1M ops/s
Write: 22K ops/s (concurrent)
ChunkCache scales to millions of concurrent reads because:
last() via atomic loadBytes::slice()