moudy 发表于 2013-5-16 12:30

劈马甲 发表于 2013-5-16 13:15 static/image/common/back.gif
理论上应该是可行的,一个文件相当于是一个container,大装小呗
反正都是2进制,它只要知道哪里去抓它 ...

理论也不简单吧,关键要没有冗余啊。就是片子以240p打底,480p是240p+补丁,720p是480p+补丁…………
jpeg这么弄好办,反正一副静止画面愿意怎么切怎么切。视频编码各种预测,各种补偿一弄,这补丁真不好打的说。估计能弄个博士学位了吧。

tkkk3 发表于 2013-5-16 12:34

moudy 发表于 2013-5-16 13:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式,同一个stream里同时有240p, 480p, 720p, 1080p几种信息,根据带宽和喜 ...

视频格式里做带宽侦测应该是很麻烦,还是把带宽侦测放到单独的module里写代码更灵活,然后发给客户端相应码率的视频流,目前Youtube的HTML5 Video感觉不给力的原因不在于视频格式的大小,可能是因为被调用的几率太低,CDN分布不够给力。VP9的优势就是能帮助大流量的网站节省流量成本。

劈马甲 发表于 2013-5-16 12:40

moudy 发表于 2013-5-16 13:30 static/image/common/back.gif
理论也不简单吧,关键要没有冗余啊。就是片子以240p打底,480p是240p+补丁,720p是480p+补丁…………
jp ...


那肯定的不会简单,人家一个编码就那么多人研究那么些年呢
你这个全揉一块儿随意缩放,弄一个博士都不算多啊 {:2_232:}

mymy365 发表于 2013-5-16 12:52

moudy 发表于 2013-5-16 13:05 static/image/common/back.gif
我一直琢磨有没有人做一种压片格式,同一个stream里同时有240p, 480p, 720p, 1080p几种信息,根据带宽和喜 ...

各种流媒体服务器都可以实现这个功能。

mymy365 发表于 2013-5-16 12:57

VP8的瓶颈之一就在于编码时间过长,所以这是很不讨好的。
这就导致了,该格式无法用于直播,按照目前的用户体验,延迟在30秒-1分钟是撑死了,如果你弄一个直播,结果延迟达到3分钟,那是10年前的直播标准,放到今天就没有意义了。
而客户端浏览器不支持,那么再怎么折腾都没戏,你不能要求用户全部都安装某一个特定的浏览器。
即使是YouTube这种视频网站,如果客户上传一个视频,编码需要超过几个小时,这是跟时代潮流背道而驰了。

mymy365 发表于 2013-5-16 12:58

weltall 发表于 2013-5-16 13:29 static/image/common/back.gif
致富信息,先把专利注册了吧

类似的专利已经有很多,欧洲或者美国。

mymy365 发表于 2013-5-16 13:04

tkkk3 发表于 2013-5-16 13:34 static/image/common/back.gif
视频格式里做带宽侦测应该是很麻烦,还是把带宽侦测放到单独的module里写代码更灵活,然后发给客户端相应 ...

你换个浏览器就行了,YouTube的HTML5视频格式并不是只有WebM,H.264是同样被支持的,所以不存在不给力之说。

moudy 发表于 2013-5-16 13:47

mymy365 发表于 2013-5-16 13:52 static/image/common/back.gif
各种流媒体服务器都可以实现这个功能。

求科普

mymy365 发表于 2013-5-16 14:10

moudy 发表于 2013-5-16 14:47 static/image/common/back.gif
求科普

比如RTMP服务器的多码率,最简单的,你看CNTV的许多电视剧的视频,还有搜狐的电影的视频,都是RTMP的,德国的话好像ZDF的也是。(这是前几年的研究,今年没把重心放在这个上面,所以可能会有些更改。)
这些视频都支持动态码率切换,也就是你在流畅/高清/超清之间的实时随意切换。而这个应用最简单的实现原理,就是分别生成比如450K,700K,1500K的三个文件,然后编写目录文件,把他们打包导入服务器,即可,当用户选择或者更改清晰度时,就能够无缝即时切换。此外,很多客户端的播放器软件,比如JW Player就支持实时带宽测侦测并调整码率(- 这个播放器目前算是使用最广泛的了,作者有点能力,YouTube最早的播放器就是他写的。)
而更复杂的一些的呢,包括已经基本淘汰的Windows Media Server以及Real的Server服务,都支持实时的编码转换。也就是说,一个1500K的文件源,可以给你实时转成450K的流输出,当然这个硬件开销比较大,现在很少有人再干这种事情了。

一些相关内容你可以根据关键字:flash media server multi bitrate 搜索,或者搜索 HTTP动态流

tkkk3 发表于 2013-5-16 14:26

mymy365 发表于 2013-5-16 14:04 static/image/common/back.gif
你换个浏览器就行了,YouTube的HTML5视频格式并不是只有WebM,H.264是同样被支持的,所以不存在不给力之说 ...

这个和浏览器没关系吧,同一个video,VP8的buffer的速度要比flash慢的明显的多。
页: 1 [2] 3
查看完整版本: 古狗公布新视频格式WebM VP9 同等画质比H.264编码小63%