用浏览器打开4K视频！6K转4K流媒体测试，VP9编码挑战H.265
视频网站流媒体超高清时代即将来临？高清已经普及，4K和更高解析度的视频也在向前发展。Youtube已经可以让用户选择2160p视频上传，但是如此高清晰的视频对网站和用户电脑都是考验。各界一直在寻找一个完美的高清流媒体解决方案，既可以最大限度的保持视频清晰度和细节，又能降低视频码率。大家下载后看到的是一个不到200M的两分钟4K视频， 使用VP9编码后只有的15M/s的码率。不过这段素材并不是原始素材，原始素材是Red Dragon拍摄的6K视频，VP9编码技术是由谷歌率领， Panasonic, Sigma, Sony, ARM 等多家合作参与开发的一种新型编码。以下为视频截图：下载 Phil Holland制作的6K Red Dragon 素材
, 使用谷歌VP9编码压缩成4K 15M/s测试文件下载链接：请使用最新版的VLC Player 或Google Chrome浏览器播放。欢迎回帖分享你的观看体验和感受！本文为作者分享，影视工业网鼓励从业者分享原创内容，影视工业网不会对原创文章作任何编辑！如作者有特别标注，请按作者说明转载，如无说明，则转载此文章须经得作者同意，并请附上出处(影视工业网)及本页链接。原文链接 /stream/50648/
扫一扫，快速分享到微信
你需要登录才可以回帖
01:09:27 H265是什么个情况？VP9编码技术是由谷歌率领， Panasonic, Sigma, Sony, ARM 等多家合作参与开发的一种新型编码
10:55:02 很兴奋能用谷歌浏览器播放VP9流媒体视频，很流畅，可惜我的显示器不是4K，未来4K流媒体涉及到音频和中文字幕，不知道谷歌浏览器能否完美解决？如果能，那4K视频通过互联网传播真的不是梦了，如果有大量资源，我一定买4K显示器或者4K投影机.希望多发布测试视频，最好有7.1音轨。
10:58:29 同级编码，码流越大越清晰。4K还是要看码流的。
作者:个人认证会员[北京]
人气：1126893
作者的其它文章
扫一扫，即可添加影视工业网为微信好友.
还可添加微信账号：Ilove107cine QQ号
加我们为微信好友
今日热销产品
【京公网安备16号】【图文】流媒体基本知识_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
评价文档：
流媒体基本知识
上传于|0|0|文档简介
&&流媒体技术原理
大小：20.25MB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢3702人阅读
流媒体（4）
& & & 相信很多做流媒体开发的朋友都在纠结如何抓取RTSP中的实际码流吧，因为从RTSP中提取h264文件不但可以让你详细分析码流，更让你能不通过任何其他方式分析网络流媒体的丢包、丢帧、卡顿、花屏等一些现实视频传输中经常遇到的问题。
& & & 网络抓包工具神器wireshark一定是大部分同仁都钟意的一款很好用的网络抓包工具吧，下面就教你怎么使用wireshark从rtsp中提取h264码流吧，这能助你解决问题一臂之力！
& & &代码（来自互联网）：
-- Dump RTP h.264 payload to raw h.264 file (*.264)
-- According to RFC3984 to dissector H264 payload of RTP to NALU, and write it
-- to from&sourceIp_sourcePort&to&dstIp_dstPort&.264 file. By now, we support single NALU,
-- STAP-A and FU-A format RTP payload for H.264.
-- You can access this feature by menu &Tools-&Export H264 to file [HQX's plugins]&
-- Author: Huang Qiangxiong (qiangxiong.)
-- change log:
-- Just can play
------------------------------------------------------------------------------------------------
-- for geting h264 data (the field's value is type of ByteArray)
local f_h264 = Field.new(&h264&)
-- menu action. When you click &Tools-&Export H264 to file [HQX's plugins]& will run this function
local function export_h264_to_file()
-- window for showing information
local tw = TextWindow.new(&Export H264 to File Info Win&)
local pgtw = ProgDlg.new(&Export H264 to File Process&, &Dumping H264 data to file...&)
-- add message to information window
function twappend(str)
tw:append(str)
tw:append(&\n&)
-- running first time for counting and finding sps+pps, second time for real saving
local first_run = true
-- variable for storing rtp stream and dumping parameters
local stream_infos = {}
-- trigered by all h264 packats
local my_h264_tap = Listener.new(tap, &h264&)
-- get rtp stream info by src and dst address
function get_stream_info(pinfo)
local key = &from_& .. tostring(pinfo.src) .. &_& .. tostring(pinfo.src_port) .. &to& .. tostring(pinfo.dst) .. &_& .. tostring(pinfo.dst_port)
local stream_info = stream_infos[key]
if not stream_info then -- if not exists, create one
stream_info = { }
stream_info.filename = key.. &.264&
stream_info.file = io.open(stream_info.filename, &wb&)
stream_info.counter = 0 -- counting h264 total NALUs
stream_info.counter2 = 0 -- for second time running
stream_infos[key] = stream_info
twappend(&Ready to export H.264 data (RTP from & .. tostring(pinfo.src) .. &:& .. tostring(pinfo.src_port)
.. & to & .. tostring(pinfo.dst) .. &:& .. tostring(pinfo.dst_port) .. & to file:\n [& .. stream_info.filename .. &] ...\n&)
return stream_info
-- write a NALU or part of NALU to file.
function write_to_file(stream_info, str_bytes, begin_with_nalu_hdr)
if first_run then
stream_info.counter = stream_info.counter + 1
if begin_with_nalu_hdr then
-- save SPS or PPS
local nalu_type = bit.band(str_bytes:byte(0,1), 0x1F)
if not stream_info.sps and nalu_type == 7 then
stream_info.sps = str_bytes
elseif not stream_info.pps and nalu_type == 8 then
stream_info.pps = str_bytes
else -- second time running
if stream_info.counter2 == 0 then
-- write SPS and PPS to file header first
if stream_info.sps then
stream_info.file:write(&\00\00\00\01&)
stream_info.file:write(stream_info.sps)
twappend(&Not found SPS for [& .. stream_info.filename .. &], it might not be played!\n&)
if stream_info.pps then
stream_info.file:write(&\00\00\00\01&)
stream_info.file:write(stream_info.pps)
twappend(&Not found PPS for [& .. stream_info.filename .. &], it might not be played!\n&)
if begin_with_nalu_hdr then
-- *.264 raw file format seams that every nalu start with 0x
stream_info.file:write(&\00\00\00\01&)
stream_info.file:write(str_bytes)
stream_info.counter2 = stream_info.counter2 + 1
if stream_info.counter2 == stream_info.counter then
stream_info.file:flush()
twappend(&File [& .. stream_info.filename .. &] generated OK!\n&)
-- update progress window's progress bar
if stream_info.counter & 0 then pgtw:update(stream_info.counter2 / stream_info.counter) end
-- read RFC3984 about single nalu/stap-a/fu-a H264 payload format of rtp
-- single NALU: one rtp payload contains only NALU
function process_single_nalu(stream_info, h264)
write_to_file(stream_info, h264:tvb()():string(), true)
-- STAP-A: one rtp payload contains more than one NALUs
function process_stap_a(stream_info, h264)
local h264tvb = h264:tvb()
local offset = 1
local size = h264tvb(offset,2):uint()
write_to_file(stream_info, h264tvb(offset+2, size):string(), true)
offset = offset + 2 + size
until offset &= h264tvb:len()
-- FU-A: one rtp payload contains only one part of a NALU (might be begin, middle and end part of a NALU)
function process_fu_a(stream_info, h264)
local h264tvb = h264:tvb()
local fu_idr = h264:get_index(0)
local fu_hdr = h264:get_index(1)
if bit.band(fu_hdr, 0x80) ~= 0 then
-- start bit is set then save nalu header and body
local nalu_hdr = bit.bor(bit.band(fu_idr, 0xE0), bit.band(fu_hdr, 0x1F))
write_to_file(stream_info, string.char(nalu_hdr), true)
-- start bit not set, just write part of nalu body
write_to_file(stream_info, h264tvb(2):string(), false)
-- call this function if a packet contains h264 payload
function my_h264_tap.packet(pinfo,tvb)
local h264s = { f_h264() } -- using table because one packet may contains more than one RTP
for i,h264_f in ipairs(h264s) do
if h264_f.len & 2 then
local h264 = h264_f.value -- is ByteArray
local hdr_type = bit.band(h264:get_index(0), 0x1F)
local stream_info = get_stream_info(pinfo)
if hdr_type & 0 and hdr_type & 24 then
-- Single NALU
process_single_nalu(stream_info, h264)
elseif hdr_type == 24 then
-- STAP-A Single-time aggregation
process_stap_a(stream_info, h264)
elseif hdr_type == 28 then
process_fu_a(stream_info, h264)
twappend(&Error: unknown type=& .. hdr_type .. & ; we only know 1-23(Single NALU),24(STAP-A),28(FU-A)!&)
-- close all open files
function close_all_files()
if stream_infos then
for id,stream in pairs(stream_infos) do
if stream and stream.file then
stream.file:close()
stream.file = nil
function my_h264_tap.reset()
-- do nothing now
function remove()
close_all_files()
my_h264_tap:remove()
tw:set_atclose(remove)
-- first time it runs for counting h.264 packets and finding SPS and PPS
retap_packets()
first_run = false
-- second time it runs for saving h264 data to target file.
retap_packets()
-- close progress window
pgtw:close()
-- Find this feature in menu &Tools-&&Export H264 to file [HQX's plugins]&&
register_menu(&Export H264 to file [HQX's plugins]&, export_h264_to_file, MENU_TOOLS_UNSORTED)
把代码保存成h264_export.lua文件，放到wireshark安装目录下，然后修改wireshark安装目录下的init.lua文件：
（1）若有disable_lua = true这样的行，则注释掉；
（2）在文件末加入dofile(&h264_export.lua&)
另外，在过滤栏目输入RTP，可以过滤所有的rtp报文，可以看到type为96.
点击：edit--&preference--》protocol--&H264,填上96，保存即可。
在打开包含H.264码流的抓包后，选菜单“Tools-&Export H264 to file [HQX's plugins]”后，把抓包文件里的H.264码流自动导出到抓包文件所在目录（用户工作目录）里，名为from_&RTP流源ip&_&RTP流源端口&_to_&RTP流目的ip&_&RTP流目的端口&.264的264裸码流文件里。（文件格式为每个NALU前加0x分隔符）。
抓取了h.264文件之后，可以用Elecard打开h264文件进行码流分析
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：162192次
排名：千里之外
原创：18篇
转载：24篇
评论：57条
(3)(1)(1)(1)(1)(2)(1)(2)(2)(4)(24)您现在的位置：&&>&&>&
深入浅出看流媒体前世今生，分分钟二逼变牛逼
作者：观止创想 &&&来源：&&&发布时间： 09:10:44
　　【流媒体网】消息：CDN这几年爆炸式增长，带宽提速是根源，而HTTP始终还是那个屌样，因此目前CDN大多是资本性行业，不用多少知识就能干了;直到流媒体粗现，直播咋这么难搞呢?因为它是流媒体，让我带你深入浅出看流媒体前世今生，分分钟二逼变牛逼。
　　流媒体分为点播和直播，点播已经堕落为HTTP文件了，直播永远不可能只用HTTP就OK，这是他们的业务差异导致的。流媒体本质上是：现实的图像，经过编码器压缩，持久化为点播文件或者直播流，经过传输，在终端解码和展示。
　　点播为何属于HTTP而不是流媒体呢?点播，譬如电影或者录制的影像，传输给观看的终端时是不变的，一万个人看一个电影无论什么时候看都是一样的媒体数据，因此传输上直接使用HTTP就可以了。点播的流媒体特征还是有的：
　　点播的重新编码，譬如为不同终端输出不同码率和尺寸的点播文件，需要媒体知识了。这部分因为使用太广泛，所以开源届早就支持得很成熟，ffmpeg对文件重新编码已经做得很好了。
　　点播P2P，这个实际上分为客户端的P2P和web P2P，这个和媒体没有什么关系，但属于点播需要做的范围，没有现成的方案。(插播广告：观止创想已经支持了点播HLS的P2P，现有系统不用修改就可以加上web P2P)
　　其他的什么分片，DRM，弹幕，分享，多终端转封装，文件调度，HTTP API调度，热点，mp4/flv-range请求，存储等等。大多都有了成熟的方案，和HTTP文件一样的技术，要么就是播放器支持，这些和流媒体一毛钱关系都没有。
　　这就是为何CDN支持点播支持得很得心应手，几乎所有的CDN都能直接支持点播分发，甚至一些新兴的行业公司，譬如在线教育，对于点播都能自己搞。点播就是HTTP而已，不属于流媒体范畴。
　　直播呢，从古老的RTSP到RTMP，HTTP渐进式下载，到HTTP流，到HLS和HDS，到DASH，到私有的websocket。这些不过是直播分发的表象，譬如HTTP直播流就是HTTP点播吗?不是。HTTP点播本质上是文件分发，而HTTP流是流媒体服务器在内存中将直播的包，打包成RTSP、RTMP、HTTP后发送给每个客户端。
　　当然总有例外的，有一个公司尝试过直播进行点播化，就是时移直播，将直播流录制成点播文件，然后客户端请求时总是请求点播。这种私有协议迟早是要死掉的，只有自己的播放器能播，而且得在CDN上部署自己的流媒体;现在这个公司也放弃了自己的“高大上”的私有协议——互联网的基本精神就是开放标准。可惜中国人很难认同这个理念，牛逼的总喜欢搞私有协议，譬如使用websocket的公司，大多属于这种类型，牛逼的人太多就是这种结果，一般这种公司也很有钱，譬如某上市的做在线秀场的公司。
　　目前直播分发有几个特点：
　　偏好flv，少用ts：flv标准11页，ts标准174页。标准文档十倍差异，代码实现起来十倍都不止。因此一般的公司都喜欢flv，pc时代都是flv的天下，什么flv流，flv切片;因为自己写代码支持ts比较麻烦，用ffmpeg的代码又太庞大。直到移动端粗现，现在直播只支持pc的少之又少了，使用flv作为基础结构的产品要么艰难转型，要么就掩耳盗铃说FLV很优雅，HLS太垃圾。
　　rtmp和hls并存：rtmp一般用于pc-flash播放直播，而hls用于移动端播放。flash能播放hls吗?前年jwplayer就支持了，可惜是商业版不开源;去年有很多开源的as播放器支持hls。而直播系统，特别是cdn的直播，不会更新这么快，pc端还是rtmp系为主。这个特点是由于平台客户端支持的流决定的，并非最佳方案，也不是用户愿意这么干。
　　实时流大多使用rtmp：实时流，延迟要求在5秒之内的流，大多使用rtmp协议。pc上可以直接播放，移动端就需要使用ffmpeg解码播放。有没有更好的分发方案?实际上http-flv比rtmp更合适，延迟一样，要求服务器支持，pc能直接播，移动端需要使用ffmpeg，还有个好处是能穿墙。为何cdn大多不支持http-flv直播?因为一般的web服务器支持不了，这是个流媒体问题。
　　rtsp永远死不了：这是监控行业的协议，我们都有门户之见，“RTMP这个烂货怎么还在互联网上用呢?RTSP多么优美!”因此有监控行业背景的公司做互联网业务，都带着门户之见不得已将RTSP转RTMP，而且还要愤愤的说——只不过是不用装个插件而已。
　　直播的本质特点，就是需要专门的服务器分发，至少需要直播源站切片HLS后分发。也就是直播需要专门的流媒体服务器，目前开源的流媒体，最古老的是RED5，后面是CRTMPD，风生水起的是NGINX-RTMP，目前最新出的是SRS。
　　为何RED5不能一统天下?RED5和FMS一样古老，先行者如果不能放掉自己的光环，迟迟不肯变革，就会被后来者超越。RED5性能是很差，但并非是因为使用了java的原因，这个看看wowza就知道了，商业服务器wowza虽然是个内存杀手，但是支持的并发一点都不含糊。RED5没有广泛商用的原因可能一直是一个先行者，祖先的角色。软件只有快速变化适应需求才能发展，和年纪没有关系。
　　那么CRTMPD怎样?牛逼!使用单进程单线程异步socket，这是和nginx同时代的产物。CRTMFPD是有不少铁杆粉丝的，以那个时代开始做直播业务的为主。CRTMDP生不逢时，遇到NGINX了，不少NGINX的粉丝是技术牛逼的人物，不然怎么能看懂void*****呢?除了社区的差异之外，CRTMPD没有支持HLS，倒是支持了RTSP，这就是典型的倒行逆施，互联网上支持RTSP，大约只有CRTMPD能想到了。
　　NGINX-RTMP风生水起有几个很重要的因素。首先2012年开始CDN业务开始快速增长，随之直播业务也需求暴涨，没有特别满意的流媒体服务器;其次，NGINX在HTTP领域绝对是霸主，大家对于NGINX系的熟悉程度很高，便于维护;再次，直播点播使用一套服务器，很有诱惑力，这可以算是“万金油”效应，很多套服务器搞得焦头烂额，肯定一套服务器能解决问题;最后，CDN是运维比技术牛逼的行业，运维的信心都是运行出来的，NGINX运行那么良好，那么NGINX-RTMP也肯定不错。
　　SRS粗来了，并非石头缝里蹦粗来个SRS，SRS其实诞生的历史是：第一个版本实际上是参考NGINX，基本上和NGINX-RTMP同时间点做出来;第二版本是改用ST作为基础结构，支持RTMP直播点播;第三版本是从CDN出来后重写的，只支持直播。为何SRS不使用NGINX那种基础结构，这个和google为何开发golang的原因一样。SRS和NGINX-RTMP最重要的区别有两点：其一，使用类似golang的服务器架构;其二，流媒体业务驱动的产品管理，如果可以装装逼，SRS是以流媒体业务为主的服务器，而不是以分发协议为主的服务器。
　　什么是以流媒体为主?流媒体系统的层次包括：网络层(socket或st)负责传输，协议层(rtmp或http)负责网络打包，封装层(flv、ts、hls、hds、adts、annexb)负责编解码数据的封装，编码层(h.264和aac)负责图像压缩。流媒体服务器的重点在于封装层，譬如flv、ts、hls、hds、adts和annexb的解析和打包都是自己实现的代码，参考标准规范，支持完善的封装转换和解析。而网络层因为使用st简化，使得协议层更简单，错误的概率更低，这个和流媒体的关系就不大了。
　　什么是以业务为主?“跑起来”和“商用”是两回事情，商用需要对于流媒体的业务有很好的支持：譬如vhost，这个是计费才有的概念，基于app的也能计费，结果就是要求用户不能app重复，新增app需要联系运维，凡是添加app需要联系运维的cdn，肯定是NGINX-RTMP;譬如日志，出现问题能将流媒体的整个链条的日志都能找出来，从边缘到回源链接，到上层节点的日志，一直追溯到推流连接的日志，每个日志都是基于连接的;譬如rtmp+http-flv+hls，国内主要的直播业务都能支持，还有hds可以供那些想装逼的客户用;更多牛逼的业务功能就不啰嗦了。
　　对于流媒体服务器，除非能忘记HTTP服务器，才能看清楚到底为何流媒体和HTTP没有一毛钱关系，而流媒体在于团队对于流媒体和服务器的理解，而并非找到一个万金油服务器能涂抹掉客户问题。
　　直播这么多协议，这多么服务器，当前直播重心在哪里?该如何选择合适的协议?只要问自己三个问题就可以了：
　　延迟要求，是否要求低于5秒的延迟?如果是硬指标，就只能选择RTMP或HTTP-FLV流。移动端需要自己编译FFMPEG支持，无法直接播放。
　　终端适配，是否要求支持PC和移动端(IOS和Android)?如果需要广泛支持移动端，HLS是最好的选择。
　　节约带宽，是否要求支持WebP2P?如果需要支持FlashP2P，或者移动端P2P，选择HLS。
　　当初有个跨国老牌的流媒体公司，劝说不要使用RTMP了，因为半年时间RTMP就会死掉，DASH会替代所有的流媒体协议。现在2年过去了，RTMP和HLS除了更加爆炸性应用之外，我看死掉的是那些过于技术至上的公司。
　　如果用一句话说流媒体直播：实时性要求高的用RTMP或HTTP-FLV，其他都用HLS。
　　协议请参考：/winlinvip/simple-rtmp-server/wiki/v2_CN_DeliveryHLS
　　服务器请参考：/winlinvip/simple-rtmp-server/wiki/v1_CN_Compare
　　关于SRS的架构参考：/winlinvip/simple-rtmp-server/wiki/v1_CN_Architecture
责任编辑:lmtwadmin
版权声明：凡来源标注有“流媒体网”字样的文章，版权均属流媒体网站，如需转载，请注明出处“流媒体网”。非本站出处的文章为本站转载，观点供业内参考，不代表本站观点。
上一篇技术平台：
关注流媒体微信iptvott
运 营 商：
合作媒体：
合作伙伴：}