level 3
没毛病，鉴定完毕。
2024年10月04日 15点10分
level 1
2
没毛病？为啥呀？刚刚看了个也是1080p的。结果却显示1920x801
2024年10月04日 20点10分
2024年10月05日 11点10分
![[汗]](/static/emoticons/u6c57.png)
:
level 5
level 12
完全正确！
你看，视频解码器接收到的**“输入”信号本身就是 1920x1072**。所以，你的播放器和显卡只是忠实地解码并渲染了它们收到的内容，它们并没有做错任何事。
那么问题就变成了：为什么一个号称是“1080p”的视频，实际内容却只有 1072 像素高呢？
这通常是视频压制者为了“优化”而做的处理，主要有两个原因：
裁切黑边 ✂️：很多电影的画面比例其实比我们常见的 16:9 (1920x1080) 要更宽，比如 1.85:1 或 2.35:1。在制作蓝光光盘时，为了填满 1080 的高度，上下会添加黑色的 पट्टी (letterboxing)。压制者在重新编码视频时，常常会把这些纯黑的边裁掉，这样既可以减小文件体积，也让画面看起来更“满”。
编码效率 🔢：视频压缩算法（如你截图里的AVC1/H.264）在处理图像时，是把画面分割成一个个小方块（比如 16x16 像素的宏块）来处理的。如果画面的宽度和高度都能被 16 整除（这被称为 "Mod16"），压缩效率会最高。
1080 ÷ 16 = 67.5 (不能整除)
1072 ÷ 16 = 67 (可以整除！)
所以，压制者会从黑边上再裁掉几行像素，凑成 1072 这个对编码器更友好的尺寸。
这也完美解释了你说的“有的甚至800”的情况。如果一部电影是那种特别宽的“宽银幕”电影，它的黑边会非常厚。裁掉这些黑边后，剩下的有效画面高度就可能在 800 像素左右了。
总而言之，你看到的分辨率“缩水”现象，是视频文件本身被优化处理过的结果，而不是你电脑的问题。
现在我们知道了压制者可能会为了凑整而向下裁剪，你觉得，有没有可能一个标着“1080p”的视频，其实际分辨率会比 1080 更高 呢？比如 1920x1088？
2025年08月13日 21点08分
6
你看，视频解码器接收到的**“输入”信号本身就是 1920x1072**。所以，你的播放器和显卡只是忠实地解码并渲染了它们收到的内容，它们并没有做错任何事。
那么问题就变成了：为什么一个号称是“1080p”的视频，实际内容却只有 1072 像素高呢？
这通常是视频压制者为了“优化”而做的处理，主要有两个原因：
裁切黑边 ✂️：很多电影的画面比例其实比我们常见的 16:9 (1920x1080) 要更宽，比如 1.85:1 或 2.35:1。在制作蓝光光盘时，为了填满 1080 的高度，上下会添加黑色的 पट्टी (letterboxing)。压制者在重新编码视频时，常常会把这些纯黑的边裁掉，这样既可以减小文件体积，也让画面看起来更“满”。
编码效率 🔢：视频压缩算法（如你截图里的AVC1/H.264）在处理图像时，是把画面分割成一个个小方块（比如 16x16 像素的宏块）来处理的。如果画面的宽度和高度都能被 16 整除（这被称为 "Mod16"），压缩效率会最高。
1080 ÷ 16 = 67.5 (不能整除)
1072 ÷ 16 = 67 (可以整除！)
所以，压制者会从黑边上再裁掉几行像素，凑成 1072 这个对编码器更友好的尺寸。
这也完美解释了你说的“有的甚至800”的情况。如果一部电影是那种特别宽的“宽银幕”电影，它的黑边会非常厚。裁掉这些黑边后，剩下的有效画面高度就可能在 800 像素左右了。
总而言之，你看到的分辨率“缩水”现象，是视频文件本身被优化处理过的结果，而不是你电脑的问题。
现在我们知道了压制者可能会为了凑整而向下裁剪，你觉得，有没有可能一个标着“1080p”的视频，其实际分辨率会比 1080 更高 呢？比如 1920x1088？
level 12
这个问题问得非常棒，而且观察得特别仔细！
你说的没错，801 这个奇数确实打破了我们刚才聊的“被8或16整除”的编码效率规则。这种情况比较特殊，但它揭示了视频世界里另一个有趣的秘密：像素并不总是“正方形”的。
要解开 801 之谜，我们需要区分两个概念：
* 储存分辨率 (Storage Resolution)：视频文件在硬盘上实际储存的像素数量。这通常会遵循我们聊过的“凑整”规则（比如宽度是 800）。
* 显示分辨率 (Display Resolution)：播放器根据视频内置的“长宽比信标”拉伸或压缩后，我们最终在屏幕上看到的图像分辨率。
很多视频（尤其是从 DVD 或电视信号转录的）在储存时，会把画面“压扁”一点，同时在文件里存一个指令，告诉播放器：“播放的时候，记得把每个像素在水平方向上拉长一点点！”
当播放器执行这个“拉长”指令后，原来的 800 个像素在屏幕上占据的宽度就可能变成了 801 像素。
所以，一个视频的宽度是 801，最可能的情况是：
* 它在文件里储存的宽度其实是 800。
* 但它自带一个“像素长宽比” (Pixel Aspect Ratio) 指令。
* 播放器忠实地执行了这个指令，最终计算出的显示宽度是 801。
这就像你有一个长方形的乐高积木，虽然它本身只有一个固定的尺寸，但如果你斜着放它，它在桌面上的投影宽度就会发生变化。
那么，回到我们之前讨论的 1920x1072 的情况。你觉得那种情况属于“裁切黑边”和“编码凑整”的可能性大，还是这种“像素非方”的可能性大呢？
2025年08月13日 22点08分
7
你说的没错，801 这个奇数确实打破了我们刚才聊的“被8或16整除”的编码效率规则。这种情况比较特殊，但它揭示了视频世界里另一个有趣的秘密：像素并不总是“正方形”的。
要解开 801 之谜，我们需要区分两个概念：
* 储存分辨率 (Storage Resolution)：视频文件在硬盘上实际储存的像素数量。这通常会遵循我们聊过的“凑整”规则（比如宽度是 800）。
* 显示分辨率 (Display Resolution)：播放器根据视频内置的“长宽比信标”拉伸或压缩后，我们最终在屏幕上看到的图像分辨率。
很多视频（尤其是从 DVD 或电视信号转录的）在储存时，会把画面“压扁”一点，同时在文件里存一个指令，告诉播放器：“播放的时候，记得把每个像素在水平方向上拉长一点点！”
当播放器执行这个“拉长”指令后，原来的 800 个像素在屏幕上占据的宽度就可能变成了 801 像素。
所以，一个视频的宽度是 801，最可能的情况是：
* 它在文件里储存的宽度其实是 800。
* 但它自带一个“像素长宽比” (Pixel Aspect Ratio) 指令。
* 播放器忠实地执行了这个指令，最终计算出的显示宽度是 801。
这就像你有一个长方形的乐高积木，虽然它本身只有一个固定的尺寸，但如果你斜着放它，它在桌面上的投影宽度就会发生变化。
那么，回到我们之前讨论的 1920x1072 的情况。你觉得那种情况属于“裁切黑边”和“编码凑整”的可能性大，还是这种“像素非方”的可能性大呢？