4K竖屏信号旋转盒：FPGA实现横屏转竖屏的完整方案

很多做商用显示的朋友都有过这种体验：现场装了一排竖屏广告机、电梯屏，客户拿过来的片源大多是横屏的。直接放上去，画面要么两边留出大黑边，要么被硬生生拉变形。客户不会跟你聊什么“宽高比”，他只会指着屏幕问一句：能不能把它“转”过来？

我一开始也跟大多数人一样，劝客户自己做竖向素材。后来发现这条路根本走不通——客户不会为了你一块屏幕去改他们的全案内容，而且很多素材来自总部统一投放，压根不给你动手的机会。折腾了两个项目之后，我终于下定决心，做了一台4K竖屏信号旋转盒，放在信号源和屏幕之间，实时把横屏信号旋转成竖屏输出。

这篇文章就把整个项目从设计思路、方案选型、硬件调试、固件参数，到实际踩坑的全过程整理出来。给所有被“横竖问题”折磨过的同行一个可以直接抄作业的参考。

1. 先搞明白：为什么需要一个“信号旋转盒”

1.1 竖向屏与横向信号之间的矛盾

这几年线下屏幕越装越“竖”。商场里的电梯屏、门头屏、斗屏，公交站台的立式信息屏，药店收银台旁边的促销屏，几乎清一色是竖向安装。屏厂出货也很配合，直接给1920x1080的竖屏面板，物理分辨率是1080x1920。

但内容端完全不是这么回事。大部分广告片、宣传片、信息流素材，都是按横屏16:9做的。把1920x1080的信号喂给一块1080x1920的屏，屏幕实际只能显示中间一条，左右全是黑边。有效画面面积算下来只有原本的56%左右，等于一半多的像素在点“空气”。

如果为了去掉黑边做全屏拉伸，那画面人物直接变成“脸谱”，比例全失真，客户更接受不了。所以问题的本质是：信号与面板方向不一致，中间的信号链路缺了一个“旋转”的处理环节。

1.2 软件旋转为什么不行

有人会说，这还不简单，播放器里面设置一下旋转不就行了？几十块钱一个的播放盒，设置里确实有旋转选项。但实际在现场，你会发现软件旋转有各种不好用的地方：

• 很多老旧播放器、监控录像机、会议终端，压根没有旋转功能。
• 部分软件旋转只是改UI方向，HDMI输出时信号仍然是横屏的，屏幕照样黑边。
• 批量部署时，几十台设备要逐台设置，客户现场工人不懂这些，设置错了又得折腾。
• 软件旋转依赖操作系统解码，4K素材实时旋转时经常出现掉帧、花屏。

更麻烦的是，有些专业设备，比如医疗超声仪、工业检测相机、投屏盒子，它们的输出逻辑是写死的横屏，你根本没法改。这时候只能从信号链路上下手：在中间加一个硬件盒子，把HDMI信号截住，旋转完再发给屏幕。

这个思路就是信号旋转盒存在的根本原因。

1.3 旋转盒的工作位置与基本形态

信号旋转盒放在信号源和显示器之间，连接方式非常简单：

信号源（HDMI）→ 旋转盒 → 竖屏显示器（HDMI）

它不需要安装任何驱动，不影响信号源本身的画面，属于完全“旁路”式处理。盒子上一般有拨码开关、串口、或者红外遥控，用来切换旋转方向。这次我做的是一个4K级别的版本，核心参数如下：

这个盒子的核心价值在于：它不是简单“转个方向”，而是把完整的横屏视频流，实时变换成竖屏视频流，保证画面比例正确、边缘无黑边、不卡顿、不花屏。下面详细拆解一下具体是怎么实现的。

2. 核心方案拆解：从HDMI输入到竖屏画面，信号走了什么路

2.1 三条可行的硬件路线对比

做视频旋转盒子，市面上大概有三条路线可选：SoC方案、专用芯片方案、FPGA方案。我在项目初期把三者都认真比划过一遍，这里直接放对比结论。

这次我选用的是FPGA方案。原因很简单：这个盒子最重要的三个指标是“即插即用”“低延迟”“不依赖信号源系统”。FPGA上电后几十毫秒就能完成配置，完全没有系统启动过程，也不存在死机、系统被病毒感染之类的问题。视频进来的数据流是什么样的，FPGA就按什么节奏处理，天然适合做这种纯硬件的实时变换。

2.2 选型时最看重的三个指标

做视频类硬件，有几个指标必须在选型阶段就定清楚，不然到了调试阶段再改，返工量非常大。

第一个是延迟。市面上所谓“低延迟视频处理板”很多在宣传时只说“低延迟”，实际做到1秒以上的都有。对于广告屏来说延迟多高可能无所谓，但如果是监控画面、医疗画面、或者有麦克风通话同步的场景，延迟超过一两帧就非常难受。FPGA方案可以把延迟压到一帧以内，这是它最大的优势。

第二个是带宽。做4K不是一句口号，4K@60的HDMI 2.0有效带宽大约是18Gbps，底层并行处理时RGB888 8bit数据等于24bit位宽。如果FPGA的IO资源或者DDR带宽不够，画面一到高动态场景就掉帧、花屏。我在选型时，直接把DDR带宽按“双倍富余”去算，后续调整缩放算法时才不用处处缩手缩脚。

第三个是开发可迭代性。硬件盒子最大的痛点是现场改不了逻辑。FPGA的好处是底层逻辑可以反复烧录迭代，我甚至在生产前还能根据测试屏的反应微调EDID或旋转方向定义。这种灵活性在项目前期特别值钱。

2.3 整机框架与关键器件选择

整个旋转盒的信号链路大体分成四段：

1. HDMI输入接收：把HDMI串行信号转成并行RGB/YCbCr数据，同时解析出HSYNC、VSYNC、DE、Pixel Clock。
2. 视频缓冲与旋转处理：FPGA内的行缓存、DDR3控制器、旋转坐标引擎。
3. 缩放与时序生成：把旋转后的图像按目标分辨率缩放，并重新生成输出时序。
4. HDMI发送：把并行视频数据重新编码为HDMI串行信号输出给屏幕。

选器件方面，HDMI接收芯片我优先选支持HDMI 2.0、输出RGB888并行接口的型号。市面主流方案很多，发烧友熟知的SiI9134算是个经典老款，但只能到1080p；要上4K，现在国产HDMI接收方案也很成熟，型号众多，关键看是否支持HDMI 2.0和HEAC可选。FPGA这边我选了Lattice ECP5系列，资源量适中，IO够用，功耗低，不需要外挂散热风扇，非常适合做这种小盒子。

DDR3内存是必须的。旋转90度的本质是“整帧数据重排”，输入进来是一行一行的顺序，但输出时可能是一列一列地读。不可能靠几根行缓存就把整个画面旋转变换完，必须先把一帧画面存进去，再从DDR里按旋转后的坐标读出来。存储大小按4K算，一帧RGB888大约24MB，加上多帧缓冲和缩放中间缓存，我建议至少配256MB DDR3。

3. 旋转不是“转一下屏”那么简单：核心原理与实现细节

3.1 像素重新映射的基本逻辑

很多朋友以为旋转就是把屏幕物理转90度，或者直接把行场同步信号对调一下就行。实际完全不是。视频旋转本质是一个像素坐标映射的过程：想把画面顺时针转90度，就要把原始画面每一个像素，搬到内存里另一个对应的位置上去。

以顺时针90度为例，假设源图像宽度为W、高度为H，对源图中的像素点(x, y)，它旋转后应放到目标图的(y, H-1-x)位置。逆时针90度则对应目标位置(W-1-y, x)。180度更简单，直接映射到(W-1-x, H-1-y)。

这些映射关系在我写的Verilog逻辑里就是一套写地址计算模块。输入进来的每一帧数据，按正常顺序写入DDR时，地址计算模块就已经把旋转后的目标地址算出来了。所以DDR里的数据，从写入那一刻起就是“已经旋转过的状态”。等到输出端去读DDR，只需要按正常的行扫描顺序读出来即可，逻辑清晰又不容易出错。

3.2 从横向1080p到纵向4K，缩放不能偷懒

旋转和缩放经常是伴随出现的。比如输入是1920x1080的横屏信号，目标输出是2160x3840的竖屏4K，那旋转角度90度之后，图像尺寸已经变成了1080x1920，还需要再放大两倍，才能符合2160x3840的输出分辨率。

这里有个细节要特别提醒：放大不能直接复制像素。有人图省事，一个像素点复制成2x2的四个像素，结果就是画面全是锯齿，文字边缘跟狗啃一样。稍微讲究一点的做法是用双线性插值，取周围四个像素做加权平均；再讲究一点可以用Lanczos-2或者三次卷积。实测下来，在这个盒子的FPGA资源限制下，双线性插值的画质/资源性价比最高，人眼在广告屏距离下看，几乎察觉不到和原画质的差距。

如果输入本身是4K超高清素材，旋转加缩放的运算量会成倍增长。比如输入3840x2160，输出2160x3840，这时本质上也是先旋转到2160x3840，再缩放到目标2160x3840？不，这种情况宽高比例一样，旋转后分辨率正好是2160x3840，不需要缩放。这是最理想的情况。但实际输入1920x1080的情况更多，所以缩放引擎是必须的。

3.3 帧缓冲、行缓存与流水线延迟

新手做旋转最容易踩的一个坑：以为数据流进来可以边收边发。实际90度旋转里，输出第一行的第一个像素，来自输入第一列的最后一个像素，那要等输入数据完整进来一段时间之后才能开始输出。所以旋转盒基本都要靠帧缓冲来兜底。

我的做法是“双缓冲”机制。DDR里开两个帧区，输入引擎往帧A写当前帧时，输出引擎从帧B读上一帧。这样读写互不干扰，只是整条链路天然多出一帧的等待时间，加上DDR访问和HDMI本身的传输延迟，最终实测大概在25ms左右，人眼基本无感。

但双缓冲会带来一个常见毛病：如果输入帧率不是恒定的60Hz，偶尔掉了一帧，输出端会重复显示上一帧，看起来就是卡顿一下。我后来加了简单的帧同步逻辑，通过对比输入De计数和输出时钟，自动调整输出vsync相位，实测在播放24p、30p、60p各种素材时都能平稳切换。

3.4 旋转模式与镜像组合：解决安装方向的最后一公里

盒子上最难跟客户解释的，其实是“哪个方向算顺转”。不同的安装现场，屏幕有可能正着挂、倒着挂、屏幕面朝里、信号源本身又转了方向。为了把这些情况全部兜住，我设计了旋转角度和镜像的组合模式：

这套组合逻辑通过盒子上4位拨码开关编码，0-15共16个状态，去掉几个保留位，正好覆盖全部模式。现场切换时，客户只需要对照外壳上贴的模式表拨码就行，不用重启盒子，也不怕误操作烧坏什么。

4. 一步步做出这个盒子：从零开始的实操记录

4.1 准备工作和测试环境

硬件开发最怕“缺东少西”。这次调旋转盒，我提前准备了以下工具和材料：

• FPGA开发板（带HDMI RX/TX子卡），一开始用开发板验证，后面再画正式PCBA。
• USB转UART模块，用于串口查看内部状态、切换模式。
• HDMI信号源：一台笔记本电脑、一台4K播放器，交替测试。
• 竖屏显示器：现场用的一台1080x1920竖屏广告屏。
• 一台普通横屏显示器：用来做对比验证，防止显示器本身“吃掉”部分画面。
• HDMI线若干，准备几根质量好的短线，4K信号对线材敏感，不建议用老旧长线。
• 示波器、逻辑分析仪，用于测量行场同步和DDR读写时序。

正式动手前，我先把目标分辨率、像素时钟、行场参数都列成了表格，方便后面查错。

4.2 硬件连接与上电验证

先把开发板上电，用串口连接，确认FPGA配置成功。然后接上HDMI输入信号源，先不要开旋转功能，让盒子处于直通状态，此时如果画面能正常显示，说明HDMI接收、发送、DDR读写链路是通的。

这一步非常关键，我建议所有调试都从直通开始。直通模式能过，才说明底层通路没问题；如果直通就无图，那旋转逻辑写得再好也白搭。

直通验证通过后，把拨码切到90度旋转模式。此时如果你用的是普通横屏显示器，看到的应该是整个画面横躺着竖起来显示？不对，准确的说是画面被旋转了90度，显示器横屏显示的话，画面会横过来铺不满屏幕。这时不要慌，直接看画面是否“转正”，重点看文字方向、画面比例有没有变形。

4.3 旋转方向与缩放参数配置

固件里我预留了一组UART命令，可以动态修改旋转方向和缩放范围。串口连接后用115200波特率进入命令行，输入rotate 90就能切换方向，输入scale full可以设置全屏缩放。

现场调试时，笔记本输出1920x1080信号，我把旋转方向设成90度，然后逐步调整缩放参数：

• 原始信号是1080p，竖屏分辨率也是1080x1920，宽高比都是16:9，旋转后刚好满屏，不需要额外裁剪。
• 如果输入是4K横屏，输出是2160x3840竖屏，同样旋转90度后分辨率是2160x3840，满屏无黑边。
• 如果输入是普通16:9横屏，但客户给的素材里本身自带上下黑边（俗称信箱模式），这时旋转后画面虽然方向正确，但两侧会出现黑边。我在缩放设置里加了一个“裁剪”选项，可以把黑边区域裁掉，再放大到全屏。这个功能现场非常有用，客户通常只关心“满屏”，不关心素材里原本的黑边。

4.4 与竖屏显示器联调时最容易翻车的点

盒子和显示器对接时，有一个问题比旋转本身更让人头疼：很多竖屏显示器内部也有“画面旋转”设置。有些显示器固件在检测到竖屏信号时，会自作聪明地认为“这是横屏信号，我必须帮你转成竖屏显示”，结果就是把我已经旋转好的画面又转了一遍，画面直接倒立或偏转90度。

解决办法是，在最终交付前，务必把所有与竖屏显示相关的菜单项全部设为“关闭”或“直通”，或者统一刷新EDID，让显示器认为它接的是一个标准的横屏信号源，不触发它的自动旋转逻辑。不过EDID刷新这事各家屏幕方案不一样，有时需要刷屏体固件，比较麻烦。我的经验是：首先在显示器菜单里找“自动旋转”“信息屏模式”“竖屏模式”之类的选项，统统关掉；找不到的情况下，再通过旋转盒的拨码组合去针对性地反向补偿。

另一件容易忽略的事是热插拔。项目测试期间，我习惯开机后插拔HDMI线，结果某次把HDMI接收芯片直接打到花屏状态。后来在电路上加了TVS管做ESD保护，并且告诉测试同事：先接线再上电，尽量不要在通电状态下频繁拔插。虽然HDMI接口号称支持热插拔，但那是在合规线缆和合规设备前提下，真机调试时静电干扰很凶。

4.5 稳定性测试与老化测试

功能调通之后，稳定性测试同样不能马虎。我把盒子接到竖屏广告屏上，连续播放一个4K素材，跑了整整72小时。测试期间重点观察：

这轮测试还帮我发现了一个细节：当使用一台4K@60播放器输入信号时，最开始屏幕偶尔会闪一下黑屏。排查下来是HDMI线的问题——换上一条屏蔽层完好的短线，闪黑现象彻底消失。所以项目现场如果遇到偶发黑屏，不要一上来就怀疑旋转盒，先换线，九成问题都在线材。

5. 实测中遇到的坑：竖屏旋转盒调试记录

做硬件没有不踩坑的。这个项目从第一版逻辑跑通到最终稳定，我整理了最典型的几个问题，做成速查表，方便大家对照排查。

5.1 常见故障与排查对照表

5.2 两个必须写进固件里的“隐藏”功能

除了上面的排查项，我还额外在固件里加了两个功能，属于做过产品之后才会想到的刚需：

第一个是EDID透传与自定义。旋转盒必须告诉信号源“我应该输出什么分辨率”，很多4K播放器默认只到1080p，接上旋转盒之后如果不做EDID写操作，它可能一直在1080p下输出，画面会偏模糊。我在固件里做了两种模式：一种是透传显示器真实EDID；另一种是强制写一个自定义EDID，把分辨率限制在1920x1080或3840x2160。这样既能兼容老设备，又能让新设备输出正确的4K分辨率。

第二个是输入信号丢失时的蓝屏/黑屏处理。有的屏幕在无信号时会弹自己厂家的Logo，很难看。旋转盒在检测到输入无信号后，可以主动输出一个全黑画面或者“无信号”提示画面，避免屏幕显示厂家Logo造成客户误解。这个功能虽然小，但在商显项目里特别受用。

5.3 软件仿真是硬件调试的“后悔药”

硬件烧录一次很耗时，为了减少在板调试的盲目性，我养成了一个习惯：先在PC端把坐标映射和缩放算法用Python仿一遍，产生一组测试数据，再把这组数据作为逻辑仿真的激励。做得比较顺利时，甚至能在FPGA综合前就把旋转方向的bug消灭掉。

比如我曾在Python里模拟了一个8x8像素的小图像，分别做0/90/180/270度旋转，打印出旋转前后的像素映射表。拿到这张表，再去对照Verilog里写的地址计算模块，哪里多减一、哪里坐标反了，一眼就能看出来。这个习惯帮我少烧了好几版固件，也让我在真实硬件调通之前，心里已经有八成把握。

6. 除了广告机，这个盒子还能用在哪儿

做硬件方案最怕只盯着一个场景。4K竖屏信号旋转盒虽然最初是为广告屏做的，但实际测试过程中我发现它能在很多地方派上用场。

6.1 商用显示与线下智能终端

这类应用是最直接的。电梯屏、楼宇广告屏、货架屏、户外立式屏，几乎都是竖屏安装。把旋转盒放在播放器和屏幕之间，素材可以继续用横屏，播放器也不用改设置，屏幕显示效果却是满屏竖屏。这在实际项目中省去了大量素材重制的人力成本。

有些商场做的双屏联动、多屏矩阵，同样可以用多个旋转盒组合，统一把横屏素材转换为竖屏画面。盒子本身成本不高，相比换竖屏播放器或者重做素材，性价比非常明显。

6.2 直播、监控与医疗等专业场景

直播行业有一个典型痛点：相机、摄像机输出的是HDMI横屏信号，但抖音、快手等手机直播App要求竖屏画面。之前大多数人靠采集卡进电脑，再用软件旋转推流，一套设备又大又重。现在用这个盒子，相机信号过来直接旋转成竖屏输出，再接采集卡或者直接给竖屏显示器监看，现场搭建非常简单，延迟还低。

监控行业也适用。很多地方用的是竖屏监视器，但NVR输出的画面是横屏布局，通过旋转盒可以把主码流画面转成满屏竖屏，便于保安室集中查看竖条形的重点区域。

医疗场景更特殊。部分超声设备、内窥镜仪器，视频输出是固定的横屏信号，但现场空间限制需要竖屏显示器。对这类不允许改动原设备的场景，旋转盒这种“黑盒旁路”式设备反而是最好的解决方案。

6.3 个人玩家和改装项目

其实这个盒子拿来做个人项目也很有意思。比如有人喜欢玩老式街机模拟器，想把显示器竖起来玩纵版射击游戏，用旋转盒就可以直接解决。还有人做数字相框、提词器、竖屏虚拟背景直播，原理都差不多：把设备固定的横屏输出，变成现场需要的任何方向。盒子本身预留了串口控制，想接单片机二次开发也完全可行。

最后再说两句

这个项目做下来，我最大的体会是：很多时候用户要的不是多复杂的解决方案，而是稳定的、不添乱的工具。旋转盒本质上就是一个“信号适配器”，它不生产画面，不修改内容，只是让画面和屏幕在方向上终于能对得上。

如果你也要做类似的东西，我给你三个小建议：

第一，把旋转方向定义搞清楚。别用什么“顺时针”“逆时针”去口头描述，直接做成拨码表贴在盒子上。客户在现场对着拨码表拨，永远比电话里用嘴描述“往左转还是往右转”靠谱得多。

第二，预留一套串口调试命令。哪怕产品最终不需要客户用串口，开发阶段也一定要留。我后面所有的现场调参、固件升级、故障定位，都靠这一根串口线救场。

第三，首板一定不要画多功能一体板。先用开发板把方案验证透了，再考虑缩小体积做正式PCBA。不然原理图一点小错误，改板一次至少两周，整个项目进度都会被拖垮。

这个盒子后续我还在继续迭代，目前已经在研究给它加上画面分割功能，做到“一路输入、多路输出、各自旋转”，或者“两路输入拼接成一个大竖屏”。等有了稳定成果，再来跟大家分享。