From a82cf7fbf5cb609456741e32504ad6a933b9d0a5 Mon Sep 17 00:00:00 2001
From: Simon Chan <1330321+yume-chan@users.noreply.github.com>
Date: Fri, 3 Jan 2025 01:50:46 +0800
Subject: [PATCH] fix more typos

---
 docs/scrcpy/video/tiny-h264.mdx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/scrcpy/video/tiny-h264.mdx b/docs/scrcpy/video/tiny-h264.mdx
index 0b11387..f69ab26 100644
--- a/docs/scrcpy/video/tiny-h264.mdx
+++ b/docs/scrcpy/video/tiny-h264.mdx
@@ -2,7 +2,7 @@
 sidebar_position: 1
 ---
 
-# Tiny H264 decoder
+# TinyH264 decoder
 
 import Version from "../version-span";
 
@@ -50,7 +50,7 @@ Because H.264 is a complex codec, decoding it is CPU-intensive. It might not be
 
 ### Rendering
 
-Tiny H264 decoder outputs raw YUV frames, which needs to be converted to RGB for rendering.
+TinyH264 decoder outputs buffers containing pixel colors in YUV color space, which needs to be converted to RGB for rendering.
 
 [`yuv-canvas`](https://www.npmjs.com/package/yuv-canvas) package is used to do the conversion and rendering. When supported, it uses a WebGL shader to accelerate the conversion, so it's very fast. But on unsupported devices, it falls back to a software implementation, which is super slow.