1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
//! Refcounted byte buffer for WebCodecs decoder output.
//!
//! `mediadecode::decoder::VideoStreamDecoder::Buffer` requires
//! `AsRef<[u8]>`. WebCodecs' native `VideoFrame` exposes pixels
//! only via the asynchronous `copyTo()` method, which returns one
//! contiguous `BufferSource` plus a `PlaneLayout` array describing
//! the offset and stride of each plane.
//!
//! `WebCodecsBuffer` represents a *view* into that contiguous
//! allocation. Planes share a single `Arc<Vec<u8>>`; each plane's
//! buffer carries an offset + length so its `AsRef<[u8]>` returns
//! only the bytes belonging to that plane. Cloning a buffer is an
//! `Arc::clone` plus copying two `usize` words — no per-plane
//! memcpy.
use Arc;
/// Refcounted view over a slice of an `Arc<Vec<u8>>`.
/// Multiple buffers can share the same underlying allocation
/// without per-plane memcpy.
///
/// Wraps `Arc<Vec<u8>>` rather than `Arc<[u8]>` so the
/// allocation pipeline stays fallible end-to-end: the data
/// `Vec` itself is allocated via `Vec::try_reserve_exact`
/// upstream (see `copy_video_frame`), and `Arc::new` here
/// only allocates the small refcount header (~32 bytes).
/// Codex round 21 flagged that the prior `Arc::from(Vec)`
/// path performed a *second* `size`-byte allocation when
/// promoting the Vec to `Arc<[u8]>`; for cap-near frames
/// (~256 MiB) that allocation could panic on OOM and abort
/// the wasm tab. With `Arc<Vec<u8>>` the second allocation
/// is bounded to the refcount header — a size that almost
/// never fails to allocate, and even on failure the tab
/// has already exhausted memory in ways the adapter can't
/// recover from.