Channel
@mpv_Yaozhi
On this record: Growth · Engagement · Reactions · Posts · Citations · Cite this entry
293subscribers
+1 since we began measuring on 11 August 2026
Risers and fallers across the register · movement among entries of Under 1,000.
| Telegram ID | -1002532739459 |
|---|---|
| Type | Channel |
| Username | @mpv_Yaozhi |
| Created | Between 1 March 2025 and 31 July 2025— estimated from Telegram’s id allocation, not measured. How this range is calculated. |
| First recorded | 11 August 2026 |
| Last confirmed live | 12 August 2026 |
| Measurements held | 2 |
| Confirmed unchanged | 1 time, most recently 12 August 2026 |
| On Telegram | t.me/mpv_Yaozhi |
| Measured (UTC) | Subscribers | Change |
|---|---|---|
| 12 Aug 2026, 01:52 | 293 | +1 |
| 11 Aug 2026, 18:15 | 292 | first reading |
17 posts held, back to 5 August 2026 — the reader has not yet reached the start of this channel’s public history, so older posts may sit further back, unread. Read across 1 pageof Telegram’s post history, 20 posts per page.
ERR is average views per post over the last 30 days divided by subscribers, the definition TGStat uses, so this figure is comparable with the one you will see elsewhere. It falls structurally as a channel grows: a high ERR on a small channel and a low one on a large channel describe reach mathematics, not quality. We publish the figure and the sample it came from and pass no verdict on it.
ER is defined industry-wide as (forwards + reactions + comments) ÷ views— note the denominator is views, not subscribers. Telegram’s public web preview carries views and reactions but not forward or comment counts, so the reaction rate above is the reactions term only and is therefore a floor: the true ER for this channel is higher by an amount we have not measured and will not estimate. It is computed over the 5 of 13 measured posts that carry a reaction reading, and over those same posts' views.
| Window | Rolling 30 days · latest post in window 11 August 2026 |
|---|---|
| Posts held | 17 (5 August 2026 – 11 August 2026) |
| Views total | 4,999 |
| Reactions total | 5 |
| Forwards / comments | not exposed by the public surface — not measured, not estimated |
| Readings taken | 11 Aug 2026, 18:15 UTC |
Views are a single reading per post, taken at the time above. A post published in the last day or two is still accumulating views, which pulls the 30-day average down slightly. That is a property of the standard definition rather than a fault in it, so we keep the definition rather than “correcting” the number into something nobody can reproduce.
Precision. Telegram publishes view counts on its public widget in short form — 8.12K, 3.7M — so any reading at or above 1,000 reaches us rounded to three significant figures, and only counts below 1,000 are exact. Averages and rates derived from them are shown to the same precision rather than to the unit: a figure like 3,701,250 would assert digits nobody measured.
Reaction counts are published per emoji and rounded the same way, so a total below 1,000 is exact and a larger one is a sum that may carry a rounded component from each emoji above 1,000. Because it is a sum, it does not look rounded — read a large reaction total as three significant figures per contributing emoji rather than as the figure it prints.
5 reactions across 4 posts, in 1 kind.
| Reaction | Count | Share | Share, drawn |
|---|---|---|---|
| ❤ | 5 | 100.0% |
No sentiment is inferred, and none should be read in. This table is ordered by count and by nothing else. Emoji do not carry stable meaning across languages or communities — 🙏 is thanks in one channel and mourning in another — so we publish which ones were pressed and how often, and pass no judgement on what an audience meant by them.
Precision. Telegram publishes reaction counts per emoji and short-forms each one — 4.34K, 1.2M — so any single kind at or above 1,000 reaches us at three significant figures, and only counts below 1,000 are exact. The shares above are ratios of those figures and carry the same error. This is also why the total here can differ slightly from a reaction total printed elsewhere on the page: both are sums of the same rounded parts, taken over samples with different edges.
Coverage. Reactions were read on 5 of the 17 sampled posts in this sample. Summed by Telegram’s own count on each post — not by adding up the per-emoji breakdown above — those same posts carry 5reactions in total: the kind of figure the paragraph above means by “a reaction total printed elsewhere on the page”.
Measured over the 17 most recent posts we hold, published 5 August 2026 to 11 August 2026, using the newest reading held for each. Telegram Stars are excluded: they are a payment, not a reaction, and they have their own section.
2026.8.12 更新： 一、HDR 弹幕滚动流畅度最终优化（重要） 1. 修复 HDR 弹幕从右向左移动不够丝滑的问题 - 解决低帧率 HDR 片源使用独立弹幕图层时，弹幕坐标虽然持续更新、实际画面却只能跟随 24、30、50fps 视频帧显示的问题 - 低帧率滚动弹幕现在会随显示器刷新稳定重绘，使移动过程更加连续，改善类似低帧率、走走停停的观感 - 经实际播放对比，横向滚动丝滑度已明显改善；此前提升的自动弹幕加载速度继续保留 2. 保留 HDR 亮度闪动修复 - PQ / HLG 片源仍不会把弹幕帧率滤镜插入 HDR 视频链路，避免重新引入偶发亮度闪动 - 新方案不生成插值视频帧，不修改 HDR 画面像素、HDR 元数据、色调映射、峰值亮度或色彩管理设置 - 只重复显示当前视频帧来提高弹幕的可见刷新频率，不把普通视频强制转换成高帧率视频 3. HDR 直通与音频直通保持兼容 …
2026.8.11 第二轮更新： 一、弹幕流畅度与 HDR 播放稳定性优化（重要） 1. 修复 HDR 弹幕可能引起的偶发亮度闪动 - PQ / HLG 片源不再把弹幕帧率处理插入 HDR 视频滤镜链，避免改变视频帧时序并干扰动态峰值计算 - HDR 弹幕改由独立图层刷新，不修改视频画面、HDR 元数据、色调映射和音频链路 - SDR 窗口模式继续使用原生 ASS 平滑渲染，原有播放效果不变 2. 优化全屏宽银幕弹幕的连续滚动 - 修复部分 24、50、60fps 片源全屏播放时，弹幕移动存在轻微一顿一顿的问题 - 弹幕位置改用连续时钟推进，并正确跟随倍速、显示同步修正、暂停、缓存和进度跳转 - 兼容渲染继续统一限制为最高 60Hz，不使用可能增加设备负担的高刷新率实验方案 3. 减少高密度弹幕的周期性微卡顿 - 优化弹幕临时内存回收，避免短时间积累后集中清理造成的瞬时停顿 …
Posted without readable text
新徽章预览
2026.8.11 更新： 一、弹幕服务器稳定性与回退链路修复 1. 清理失效的历史弹幕节点 - 移除已经无法正常解析、且不适合作为弹幕搜索接口的历史节点 - 避免播放器反复等待不可用服务器，减少弹幕搜索超时、自动匹配无结果或长时间停留在加载状态的问题 - 继续保留 LogVar 高速节点作为首选，并保留官方 dandanplay 接口作为搜索后备 2. 更新弹幕链接解析兜底 - 换用已经完成实际弹幕解析验证的可用兜底服务 - 当首选或官方接口返回具体剧集链接后，可继续通过兜底链路获取对应弹幕内容 - 兼容兜底服务返回的弹幕数量与弹幕列表字段，避免接口请求成功但播放器无法读出弹幕 二、播放倍速跨集保持 1. 修复切换下一集后倍速恢复 1.0 的问题 - 使用播放器底部倍速按钮设置速度后，同一播放列表切换下一集会继续保持当前倍速 - 音轨、字幕、滤镜与画面参数仍按原有规则重…
2026.8.10 更新： 一、Dolby Vision Profile 7 FEL 播放链路修复（重要） 1. 修复部分 P7 FEL 视频被识别为 HDR10 的问题 - 修复部分 Dolby Vision Profile 7 FEL 视频只处理基础层、界面误显示 HDR10 的问题 - 同时覆盖单轨 FEL 文件、“基础层 / 增强层分列两个视频轨”的双轨 MP4，以及按蓝光规范封装的 ISO / BDMV - 正确配对增强层后，时间轴媒体信息与起播格式徽章会恢复显示 Dolby Vision P7 2. 修复蓝光 ISO / BDMV 的 FEL 识别与播放 - 修复蓝光镜像内 4K 基础层与 1080p 增强层分别存放时，只播放基础层并显示 HDR10 的问题 - 通过蓝光播放列表中明确写入的 Dolby Vision BL / EL 关系完成配对，不根据分辨率、PID 或轨道顺序猜…
❤2
mpv-Yaozhi pinned a photo
收集一些优化建议，大胆提 🐣 讨论组 🐧 个人主页
2026.8.7 第二轮 更新： 一、弹幕加载速度与自动匹配优化（重要） 1. 新增高速弹幕服务器 - 新增 LogVar 高速弹幕节点，并作为优先加载服务器 - 原有弹幕服务器继续保留为后备节点，首选服务器不可用时会自动尝试其他节点 - 优化电视剧等影视内容的搜索兼容性，减少等待时间和搜索不到的问题 2. 修复自动加载弹幕 可能绑定错误剧集 的问题 - 修复部分电视剧片名识别正确，但自动加载成其他集数的问题 - 自动匹配会同时核对文件名集数与服务器返回集数；集数不一致时会拒绝错误结果并继续搜索 - 修复旧版关联历史可能记录错误集数的问题，已有错误记录会在后续播放时自动校正，无需手动清理 二、AList / OpenList 文件排序修复 1. 修复排序状态与实际列表不一致的问题 - 修复切换到“名称↓”后，重新打开 mpv 仍按“名称↑”排列的问题 - 现在重启播放器后…
mpv-Yaozhi pinned a file
2026.8.7 更新： 一、键盘快进 / 后退提示全面优化 1. 统一前进与后退的显示效果 - 修复右方向键前进与左方向键后退使用两套提示的问题 - 轻按方向键不再弹出整条进度条，也不会被顶部弹幕遮挡 - 统一显示跳转方向、累计秒数、当前时间 / 总时长和播放百分比 2. 优化提示样式与位置 - 提示颜色、描边和字号与弹幕加载状态保持同一视觉风格 - 仅在弹幕实际加载并正在显示时，自动排列到最后一排弹幕下方 二、片头片尾编辑即时刷新 1. 修复手动编辑后进度条标记没有立即更新的问题 - 使用剪刀按钮重新标记片头或片尾后，当前集时间轴会立即显示最新范围 - 实际片段时间、章节标记与自动跳过状态保持同步 三、竖屏封面音频起播徽章优化 1. 优化竖屏专辑封面与音频视频的徽章尺寸 - 竖屏画面中的音频格式徽章额外放大 18%，避免右上角标识过小 - 横屏视频继续保持原…
❤1
如启动时提示缺少 dll 文件 把此文件放在根目录即可 - 正常启动的请忽略 -
Showing the 12 most recent of 17 posts we hold for @mpv_Yaozhi. View and reaction counts are the latest single reading for each post, not a live figure, and a recent post is still accumulating both. A view count marked ≈ was rounded by Telegram before we ever saw it — t.me prints views in full below 1,000 and to three significant figures above, so ≈1,200,000 means somewhere between 1,150,000 and 1,249,999. Unmarked counts are exact. Text is reproduced from the public post preview and truncated for length.
Citation-graph rank — 998,726 of 1,548,671entries in the measured graph. A weighted position computed from the forward and mention edges below — republished posts weigh more than named mentions — and recomputed periodically, over the whole graph. Published only as this ordinal position, never as a score: a position is a fact, and a score printed beside one channel’s name would read as a verdict this register does not make. The two counts beneath stay separate for the same reason mentions are never summed with forwards anywhere else on this page — a named-by count costs nothing to manufacture. The top 100 by this measure, or how it is computed.
Named by 1 registered channel — every channel on the register whose own posts have named this one, by its current username or any other username it currently holds, merged from two separately captured readings of the same fact so a namer caught by only one of them is not missed and a namer both caught is not counted twice. A username this channel has since dropped is not matched — that handle may belong to someone else now, and crediting today’s namer to yesterday’s owner would misattribute it.
Named by
Channels on the register whose posts name this channel's handle.
A mention is a weaker signal than a forward and is counted separately for that reason — naming a channel is not republishing it, and a handle in a post body is easy to place deliberately. The post counts beside each row below are distinct posts in which the handle appeared, from posts we have read on both sides — the “Named by N registered channels” figure above is a different count, of distinct NAMING CHANNELS rather than posts, and is not the sum of the rows under it.
A live page changes as we take new readings, so a citation should name the measurement it is based on, not just the URL. The line below cites the subscriber count as measured 12 August 2026 — this entry's latest reading, not the date you are reading this.
“mpv-Yaozhi” (@mpv_Yaozhi), 293 subscribers as measured 12 August 2026. Telegram Register, tgregister.com/channel/mpv_Yaozhi.
Full measurement history, CC BY 4.0. Every reading this register holds for this entry, not just the latest one, as a dated, downloadable record: CSV · JSON. Free to use with attribution to tgregister.com. Each file carries its own generation timestamp, which is the figure to cite for exactly when the data was retrieved.