作者 主题:EEVblog#698-GPU视频渲染 (Read 86423 times)

0个成员和53位来宾正在查看此主题。

离线 自由电子

  • 超级贡献者
  • ***
  • 职位:7581
  • 国家: 我们
    • 硅谷车库
回复:EEVblog#698-GPU视频渲染
« 在以下问题上回复#50: 2015年1月2日,下午03:07:07»
思考的东西

您要进行多少转码?
'Rendering'是在创建动画叠加层(如tickerbars,greenscreen效果,crossfades等)时使用的术语。'影片中似乎没有做任何这件事。渲染操作正在进行像素操作,gpukicks参与其中。

您正在做的是转码。拍摄一块以x格式录制的视频,然后将其吐出为y格式。

您的相机以x格式拍摄。您的输出是不同的格式吗?如果您保持格式相同(输入和输出相同),那么编码只会在两个剪辑的交集处发生。其他大多数数据只是简单地复制过来。就像合并两个文件一样。 可能会有一个调整,您可以告诉编辑工具调整剪切点,使它们始终与i帧重合。在那种情况下,在切换点不涉及渲染,因为帧序列总是必须以i帧开始。

您知道输入格式和输出格式的gop格式是什么吗?如果gop长度不同,则编码变得很耗时。

您还在运行其他什么效果?色彩校正 ?音频调平?

这里'还有另一件事要考虑。如果您以高清观看商业广播。让's说一个新闻频道。他们有现场直播室供稿,标题栏,底部有动画滚动条,可以注入动画背景,并在采访现场记者时进行画中画。
全部由一台计算机实时完成。

他们如何做到这一点?通过跳过解码/编码。

实时视频以未压缩格式出现,因此计算机不必浪费时间扩展流并重新压缩。对于现代计算机而言,数据速率并不高。叠加层(tickerbar等)在gpu上运行。组装输出视频是其中的一部分,或者是使用遮罩进行的操作获取实时供稿,应用遮罩(将某些区域设置为黑色)。然后将叠加层中非黑色的内容复制到流中黑色的任何内容。完毕。
非常简单的位交换操作。

当最终的视频准备就绪时,然后将其编码为所需的传输格式。

您也许也可以这样做。您的相机通过USB输出实时视频? 这意味着如果您将其插入并启动视频捕获工具,它会看到实时供稿?   您可能想要尝试使用便携式计算机直接以未压缩格式或仅使用i帧的格式捕获。与使用in相机编码相反。您将拥有非常大的文件,但是不再需要装饰压缩步骤。您有未压缩的原始视频和音频。

那 may edit much faster than the native format from the camera. Edit in vegas, save as uncompressed , and let handbrake do the encoding .

值得一试的东西。

我的直觉说,计算机花了所有时间进行解码/重新编码。

« 上次编辑:2015年1月2日,下午03:30:40 by free_electron »
专业电子牧马人。
任何意见或表达的观点,都是我本人的,未经我的雇主认可,诱导或补偿。
 

离线

  • 常客
  • **
  • 帖子:525
  • 国家: 我们
  • 我承认自己是可悲的
回复:EEVblog#698-GPU视频渲染
« 在以下回复#51: 2015年1月2日,下午03:12:39»
戴夫:

为什么不'您发布了一个视频,读者可以下载该视频并指定要输出的内容。 同时发布您的渲染时间。

然后,让EEVBlog用户尝​​试以最少的渲染时间来尝试自己的系统和软件。

然后,他们可以将结果以及他们的软件/硬件/设置发布到这里。
戈尔(Al Gore)出生的那天,地球上有7,000只北极熊。
今天,仅剩26,000。
 

离线 霍华隆

  • 超级贡献者
  • ***
  • 帖子:5023
  • 国家: b
回复:EEVblog#698-GPU视频渲染
« 在以下回复#52: 2015年1月2日,下午03:15:21»
为什么不'您以60fps的速度拍摄4k吗?*





(* =笑话)
 

离线 w

  • 新手
  • 帖子:2
回复:EEVblog#698-GPU视频渲染
« 在以下回复#53: 2015年1月2日,下午03:29:10»
我在NVidia GTX-970卡和某些软件上都遇到了类似的问题,但没有看到CUDA。有趣的信息可能可以从DVDFAB DeCrypter论坛中获得:建议在当前NVidia产品中使用的新的Maxwell架构也对驱动程序架构进行了更改。有人建议,在进行一些重写之后,可以再次使用CUDA。 DVDFab的人员表示,在当前版本中,他们确实支持最新的NVidia芯片组。不幸的是,由于其他原因,我无法测试此语句,但是我的收获是,如果您愿意等待,可能会等待很长的时间(基于Maxwell GPU在GTX 870和880),也将支持较新的芯片。
 

离线 希卡留克

  • 支持者
  • ****
  • 帖子:206
  • 国家: b
回复:EEVblog#698-GPU视频渲染
« 在以下回复#54: 2015年1月2日,下午03:46:37»
我想这是一个很小的社区,目前正在以50 / 60fps的速度运行。   例如在youtube上,如果他们想'up the quality'他们使用的还是4k @still标准30fps,比我做过50 / 60fps的任何人都要多。

60 fps录制在PC游戏人群及其相关的YouTube频道中非常普遍。 至少PC游戏玩家更喜欢更高的帧速率而不是更高的分辨率。
我写软件。  I'd宁愿做其他事情。
 

离线 霍华隆

  • 超级贡献者
  • ***
  • 帖子:5023
  • 国家: b
回复:EEVblog#698-GPU视频渲染
« 在以下回复#55: 2015年1月2日,下午04:50:08»
有了选择,并知道转码和渲染需要多长时间,我个人'd宁愿花时间在内容上,也不愿幻想产生60fps的速率。全高清电视广播的帧速率仍为25/30帧/秒的1080i'我住在一块岩石下,但我不知道'看不到很多对此的抱怨。
 

离线 mp

  • 常客
  • **
  • 帖子:519
  • 国家: b
回复:EEVblog#698-GPU视频渲染
« 在以下回复#56: 2015年1月2日,下午4:55:15»
应该把事情留给他们,因为他们所做的只是为自己制造问题,
增加渲染时间和更大的文件大小等等。
而且有些人无论如何都无法观看1080p60(就像我一样),因为它只是混蛋和口吃,
当我在720p60和1080p60之间切换时,我看不到任何区别
(除了口吃)

希望您不用花更多的钱就能整理好它

 

离线 ovnr

  • 常客
  • **
  • 帖子:658
  • 国家: 不
  • 潜伏者
回复:EEVblog#698-GPU视频渲染
« 在以下回复#57: 2015年1月2日,下午04:57:01»
至少PC游戏玩家更喜欢更高的帧速率而不是更高的分辨率。

无论如何,其中一些。我决定对Nvidia感到更开心's的DSR渲染为〜4k,并以30fps的分辨率下采样到2560x1440 @ 60fps的1080p。
 

离线 伊安

  • 支持者
  • ****
  • 帖子:1166
  • 国家: 苏格兰
  • 多年以前是EE专业人士,现在是业余爱好/家庭企业。
    • 伊安ohnston.com
回复:EEVblog#698-GPU视频渲染
« 在以下回复#58: 2015年1月2日,下午06:23:29»
当我在720p60和1080p60之间切换时,我看不到任何区别
(除了口吃)

那'我在下面的帖子中提到它的原因之一,但是不要'不要误会我的意思... IMO,它仍然需要进行一些测试,以查看720p50 / 60是否可以接受,和/或1080p50 / 60是否值得花额外的时间进行编码。就我个人而言,目前'观看YT影片全屏观看,因此1080与720相比并没有真正的优势, 'd相对于25/30,全天更喜欢50 / 60fps。

//www.villagehousevacs.com/forum/blog/eevblog-698-gpu-video-rendering/msg579014/#msg579014

伊恩
伊恩·约翰斯顿(Ian Johnston)
www.ianjohnston.com
PDVS2的制造商& PDVS2mini
 

离线 cmpxchg

  • 贡献者
  • 帖子:12
  • 国家: 德
回复:EEVblog#698-GPU视频渲染
« 在以下回复#59: 2015年1月2日,下午06:45:36»
坦白说,似乎我们在这里遗漏了重点。 Dave说他在Handbrake中进行了实际编码。因此,理想情况下,您不希望该Sony工具执行任何*编码*!进行两个单独的有损编码步骤对质量是不行的,如此处所示,它也会损害编码时间。

Sony是否有无损编解码器,理想情况下根本没有耗时的压缩?当然,生成的文件将很大,但是'这只是手刹工作的中间步骤。然后,您让Sony做*合成*,而Handbrake做*编码*。这些是独立的过程。在低压缩下使用适当的无损编解码器,您可以'可能会受到硬盘吞吐量进行编码的限制,所以它'会比实时快得多。
 

离线 莱特曼

  • 贡献者
  • 帖子:7
回复:EEVblog#698-GPU视频渲染
« 在以下回复#60: 2015年1月2日,下午7:35:40»
这个线程是无价的,它有很多信息!

到目前为止,以我对视频编码(15年)的经验来说,最重要的是:
1- CPU核心数量/处理器数量
2- L3缓存

通常,您不会注意到i7顶级产品与Xeon处理器之间有多少区别。

我认为您能做的最好的事情是购买双或四处理器eATX板,但是不确定i7是否有这样的解决方案,我过去曾为AMD处理器使用过两块双处理器板。

我在这里有几个带有单至双至强处理器的服务器,因此如果您愿意,我可以进行一些测试,它们不是最新的,但足以看到单至双处理器之间的区别。

顺便说一句:有人评论将mainconcepts编码器与cuda!一起使用的结果,非常有趣!释放麦克斯韦卡后,我会立即对其进行测试。
« 上次修改时间:2015年1月2日,下午7:58:10,作者:lightman »
 

离线 Rollat​​orwieltje

  • 支持者
  • ****
  • 帖子:571
  • 国家: nl
  • 我为你做饭。
回复:EEVblog#698-GPU视频渲染
« 在以下回复#61: 2015年1月2日,下午08:00:53»
坦白说,似乎我们在这里遗漏了重点。 Dave说他在Handbrake中进行了实际编码。因此,理想情况下,您不希望该Sony工具执行任何*编码*!进行两个单独的有损编码步骤对质量是不行的,如此处所示,它也会损害编码时间。

Sony是否有无损编解码器,理想情况下根本没有耗时的压缩?当然,生成的文件将很大,但是'这只是手刹工作的中间步骤。然后,您让Sony做*合成*,而Handbrake做*编码*。这些是独立的过程。在低压缩下使用适当的无损编解码器,您可以'可能会受到硬盘吞吐量进行编码的限制,所以它'会比实时快得多。
它可以做到无损,甚至完全没有压缩,但是它仍然需要花费很长时间,并且文件每分钟大约12GB(使用Windows视频->创建一个无损模板)。有没有'似乎是一种有用的中间编解码器,压缩量最少。

我不知道'也没有采取额外的“手刹”步骤,但是我对此没有真正的经验。 Youtube直接接受Movie Studio的输出AVC。如果该文件太大,为什么不降低Movie Studio中的比特率而不是再次对其进行压缩?
 

离线 罗格

  • 定期贡献者
  • *
  • 帖子:206
  • 国家: 我们
回复:EEVblog#698-GPU视频渲染
« 在以下回复#62: 2015年1月2日,晚上08:28:56»
如果你不是 '如果使用SSD,您将无法以25MB / s的速度写入数据。
 

离线 马可

  • 超级贡献者
  • ***
  • 帖子:5018
  • 国家: nl
回复:EEVblog#698-GPU视频渲染
« 在以下回复#63: 一月02,2015,08:43:43下午»
总的来说,编码并不是一个令人尴尬的并行问题……所有事物都是超分支的和相互联系的,根本不适合GPU。对于编码器的一些有限部分(最重要的是运动估计),您可以制作GPU版本,以寻求更多的压缩,但是's about it.
 

离线 Rollat​​orwieltje

  • 支持者
  • ****
  • 帖子:571
  • 国家: nl
  • 我为你做饭。
回复:EEVblog#698-GPU视频渲染
« 在以下回复#64: 一月02,2015,08:49:36下午»
如果你不是 '如果使用SSD,您将无法以25MB / s的速度写入数据。

那 would be quite a poor harddrive... Even to my NAS I can write with more than twice that speed.
它具有WD Green 2TB,甚至没有性能磁盘。
 

离线 马里什

  • 超级贡献者
  • ***
  • 帖子:4013
  • 国家: RO
  • .
回复:EEVblog#698-GPU视频渲染
« 在以下回复#65: 2015年1月2日,下午08:51:03»
我的4 TB Hitachi NAS系列驱动器可以在表面上的任何一点上以80 MB / s的速度持续工作……从大约160 MB / s的速度开始,然后随着磁头朝磁盘的另一侧移动而下降。保存使用无损编解码器(如MagicYUV)编码的视频确实不是问题。

除非需要处理多个视频和音频轨道并且进行大量剪切并添加大量效果/过渡,否则无需SSD

Dave只有一条视频轨道,而他的视频主要包括将片段粘在一起并切掉他没有的部分't want anymore. 因此,Sony软件会从输入的视频文件中缓冲一堆数据,然后将视频编解码器中的数据写入光盘。
那里'最小的读/写访问权限,因此常规硬盘驱动器的缺点(访问时间长,必须在读和写操作之间移动磁头)在这里不会引起任何问题。

 

离线 霍华隆

  • 超级贡献者
  • ***
  • 帖子:5023
  • 国家: b
回复:EEVblog#698-GPU视频渲染
« 在以下回复#66: 2015年1月2日,晚上10:24:35»
甚至在五年前,当我最后一次进行高清视频时,我持续的大容量(即未缓存)硬盘驱动器吞吐量为80MB / s。不确定25MB / s来自何处,可能是数量级还是数量级?
« 最后编辑:Howardlong,2015年1月2日,晚上11:39:07 »
 

离线 cmpxchg

  • 贡献者
  • 帖子:12
  • 国家: 德
回复:EEVblog#698-GPU视频渲染
« 在以下回复#67: 2015年1月2日,晚上11:08:52»
坦白说,似乎我们在这里遗漏了重点。 Dave说他在Handbrake中进行了实际编码。因此,理想情况下,您不希望该Sony工具执行任何*编码*!进行两个单独的有损编码步骤对质量是不行的,如此处所示,它也会损害编码时间。

Sony是否有无损编解码器,理想情况下根本没有耗时的压缩?当然,生成的文件将很大,但是'这只是手刹工作的中间步骤。然后,您让Sony做*合成*,而Handbrake做*编码*。这些是独立的过程。在低压缩下使用适当的无损编解码器,您可以'可能会受到硬盘吞吐量进行编码的限制,所以它'会比实时快得多。
它可以做到无损,甚至完全没有压缩,但是它仍然需要花费很长时间,并且文件每分钟大约12GB(使用Windows视频->创建一个无损模板)。有没有'似乎是一种有用的中间编解码器,压缩量最少。

我不知道'也没有采取额外的“手刹”步骤,但是我对此没有真正的经验。 Youtube直接接受Movie Studio的输出AVC。如果该文件太大,为什么不降低Movie Studio中的比特率而不是再次对其进行压缩?

以12GiB /分钟的速度,戴夫斯摄像机必须是一个真正的怪物,才能维持200MiB / s的速度并同时完成所有摄像机的工作。您当然可以无损地进行压缩。那's WinRAR和ZIP分别用于什么,我'确保存在以下视频编解码器"无损,但压缩"同样,肯定有音频编解码器。因此,这种编解码器的输出大小将与原始摄像机数据相同,并且显然i7的性能优于摄像机,或者很可能,因为您可以使用i7进行压缩,所以其大小可能要小得多。
 

离线 EEV博客

  • 行政人员
  • *****
  • 帖子:32413
  • 国家: au
    • EEV博客
回复:EEVblog#698-GPU视频渲染
« 在以下回复#68: 2015年1月2日,晚上11:25:59»
坦白说,似乎我们在这里遗漏了重点。 Dave说他在Handbrake中进行了实际编码。因此,理想情况下,您不希望该Sony工具执行任何*编码*!进行两个单独的有损编码步骤对质量是不行的,如此处所示,它也会损害编码时间。
Sony是否有无损编解码器,理想情况下根本没有耗时的压缩?

不支持我所知道的50 / 60fps。除非有某种插件。
是的,Sony仅用于生成转到Handbrake的中间文件,然后将其删除。
 

离线 EEV博客

  • 行政人员
  • *****
  • 帖子:32413
  • 国家: au
    • EEV博客
回复:EEVblog#698-GPU视频渲染
« 在以下回复#69: 2015年1月2日,晚上11:32:33»
我不知道'也没有采取额外的“手刹”步骤,但是我对此没有真正的经验。 Youtube直接接受Movie Studio的输出AVC。如果该文件太大,为什么不降低Movie Studio中的比特率而不是再次对其进行压缩?

因为Handbrake(实际上是x264编解码器,所以Handbrake只是外壳)在其功能方面非常出色。它只有一个通行证"constant quality"模式可确保每一帧的图像质量最佳。不用选择目标比特率,而是选择目标"quality" rate.
因此,无论我制作哪种类型的视频,无论是带有大量细节的户外运动,说话的头部还是屏幕捕捉教程,Handbrake每次都能做到最好,而无需我思考和摸索。
户外运动视频的文件很大,并且屏幕捕获的尺寸非常小,而且质量始终如一。
 

离线 EEV博客

  • 行政人员
  • *****
  • 帖子:32413
  • 国家: au
    • EEV博客
回复:EEVblog#698-GPU视频渲染
« 回复#70: 2015年1月2日,晚上11:33:51»
我认为您能做的最好的事情是购买双或四处理器eATX板,但是不确定i7是否有这样的解决方案,我过去曾为AMD处理器使用过两块双处理器板。

我以为只有至强才允许多个处理器?
 

离线 持有人

  • 定期贡献者
  • *
  • 帖子:72
  • 国家: 我们
    • 韦恩's Tinkering Page
回复:EEVblog#698-GPU视频渲染
« 在以下回复#71: 2015年1月2日,晚上11:35:03»
I'我想知道这里是否可以进行一些众包采购有帮助。 也许您可以以测试过的60fps格式发布RAW,一分钟的剪辑,然后查看观众可以得到的结果。 也许不是每个解决方案都对您有用,但是它会给出可能的想法。

韦恩
 

离线 EEV博客

  • 行政人员
  • *****
  • 帖子:32413
  • 国家: au
    • EEV博客
回复:EEVblog#698-GPU视频渲染
« 在以下回复#72: 2015年1月2日,晚上11:40:44»
'Rendering'是在创建动画叠加层(如tickerbars,greenscreen效果,crossfades等)时使用的术语。'影片中似乎没有做任何这件事。渲染操作正在进行像素操作,gpukicks参与其中。
您正在做的是转码。

I'我不会对确切的术语感到困惑。通常会叫您的视频编辑器吐出任何东西"rendering".
然后那之后的一切"transcoding".
这就是我所说的。

引用
您的相机以x格式拍摄。您的输出是不同的格式吗?如果您保持格式相同(输入和输出相同),那么编码只会在两个剪辑的交集处发生。其他大多数数据只是简单地复制过来。就像合并两个文件一样。 可能会有一个调整,您可以告诉编辑工具调整剪切点,使它们始终与i帧重合。在那种情况下,在切换点不涉及渲染,因为帧序列总是必须以i帧开始。

如果你能告诉我's possible in Sony I'm all ears.

引用
您还在运行其他什么效果?色彩校正 ?音频调平?

没有。仅有一些淡入淡出,文字和偶发的双视频叠加。

引用
实时视频以未压缩格式出现,因此计算机不必浪费时间扩展流并重新压缩。对于现代计算机而言,数据速率并不高。叠加层(tickerbar等)在gpu上运行。组装输出视频是其中的一部分,或者是使用遮罩进行的操作获取实时供稿,应用遮罩(将某些区域设置为黑色)。然后将叠加层中非黑色的内容复制到流中黑色的任何内容。完毕。
非常简单的位交换操作。

It'很好地说这一切,并展示如何为我们录音,等等,但是'与我的情况无关'm afraid.

引用
您也许也可以这样做。您的相机通过USB输出实时视频? 这意味着如果您将其插入并启动视频捕获工具,它会看到实时供稿?   您可能想要尝试使用便携式计算机直接以未压缩格式或仅使用i帧的格式捕获。与使用in相机编码相反。您将拥有非常大的文件,但是不再需要装饰压缩步骤。您有未压缩的原始视频和音频。

我不能'没有比从相机到PC的实时拍摄更可怕的事情会破坏我的工作效率了。 (可以通过HDMI完成)
只是后勤工作将是一场噩梦。

引用
我的直觉说,计算机花了所有时间进行解码/重新编码。

当然如此。
 

离线 EEV博客

  • 行政人员
  • *****
  • 帖子:32413
  • 国家: au
    • EEV博客
回复:EEVblog#698-GPU视频渲染
« 在以下回复#73: 2015年1月2日,晚上11:44:40»
I'我想知道这里是否可以进行一些众包采购有帮助。

我知道结果。一世'd对于他们的方式/程序为何是最佳的,最终得出了1000条不同的意见。

这真的很简单。我要么需要更快的处理器,要么需要Sony上可用的编解码器,而编解码器渲染速度可能太快。
我确实曾尝试过Frameserver,从理论上讲它应该是最快的渲染,因为它's的原始输出,但是很混乱并且没有't work right.
 

离线 warp_foo

  • 支持者
  • ****
  • 职位:117
  • 国家: 我们
回复:EEVblog#698-GPU视频渲染
« 在以下方面回复#74: 2015年1月3日,上午12:02:12»
我在NVidia GTX-970卡和某些软件上都遇到了类似的问题,但没有看到CUDA。有趣的信息可能可以从DVDFAB DeCrypter论坛中获得:建议在当前NVidia产品中使用的新的Maxwell架构也对驱动程序架构进行了更改。有人建议,在进行一些重写之后,可以再次使用CUDA。 DVDFab的人员表示,在当前版本中,他们确实支持最新的NVidia芯片组。不幸的是,由于其他原因,我无法测试此语句,但是我的收获是,如果您愿意等待,可能会等待很长的时间(基于Maxwell GPU在GTX 870和880),也将支持较新的芯片。

如果上述正确,则-Maxwell架构会影响CUDA处理-如果可能,请尝试借用GTX 770。'基于Kepler的GPU。

m

预计到达时间:是的。  :)
« 上次修改时间:2015年1月3日,上午12:05:16 by warp_foo »
我们要去哪里,为什么要买手提篮?
 


分享我

掘客  Facebook  SlashDot  可口的  Technorati  推特  谷歌  雅虎
中频