引用:

原帖由 卖哥 于 2012-10-29 09:48 发表
http://club.tgfcer.com/thread-6559652-1-1.html
社长已经回答了
视频不是四帧一压甚至不是单帧压缩传输，而是以16*16的棋盘格压缩传输，所以传输过程的延迟可以小于1帧。
但是高档电视却会缓冲数帧做插值等后处 ...

老实说我是没怎么明白这个做法的高明之处。因为
1：控制器需要gather到一帧画面的所有block才会刷新————否则就不是现在游戏中存在的画面撕裂这么简单的问题了。
2：虽说GPU渲染也是以block形式，但现代游戏的渲染机制复杂，有诸多rendering pass存在，只有最后一个pass才是要直接输出到屏幕的东西，而且对于Edram做临时FrameBuffer的机器来说，还需要把RenderTarget从Edram中Resolve出来才行。那么这个分block传输的流程，也就是每resolve出16x16 pixel就传输过去，因此它的延迟就是resolve 16x16pixel的时间而不是resolve出整个720p/1080p画面的时间。但问题是，即使是X360，resolve出720p的画面，用时也不过0.2-0.3ms而已（30fps代表一帧总时间是33ms），那么这个节省的延迟，不只是一个微乎其微的时间么？
我不知道是不是哪块我没理解对。

引用:

原帖由 卖哥 于 2012-10-29 15:04 发表

编码传输解码三个步骤
要消耗一帧的编码时间一帧的传输时间一帧的解码时间

这三个过程互为先决条件没法流水
但是如果最小单位是16*16，那么同样一帧的过程就可以流水成一帧的编码时间+16*16的传输时间+16*16的 ...

嗯,我把编码时间给忽略了.光关注于从framebuffer中取block的过程了。
不过话说回来，如果如我前面说的无法从渲染流程中得到额外的延迟优势。那这技术不就是很常见的流式编码传输方式么，网络上的语音或文件压缩传输之类不都是这么做的么？

[ 本帖最后由 hourousha 于 2012-10-29 17:31 编辑 ]