音视频方案,音视频扩展内容(编码解码器) (笔记)2

介绍了LAVFilter,一款开源的DirectShow视频分离和解码软件,支持广泛的视音频格式。包括其内部结构、支持的封装格式及编码类型,并对比了其他相关技术。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

 视频方案,雷霄骅的专栏- http://blog.youkuaiyun.com/leixiaohua1020
> LAV Filter
  LAV Filter 是一款开源的DirectShow视频分离和解码软件,他的分离器LAVSplitter封装了FFMPEG中的libavformat,解码器LAVAudio和LAVVideo则封装了FFMPEG中的libavcodec。它支持十分广泛的视音频格式。
  LAV Filter- https://github.com/Nevcairiel/LAVFilters http://code.google.com/p/lavfilters/

LAV Filter支持状况:
 封装格式:MKV/WebM, AVI, MP4/MOV, MPEG-TS/PS (including basic EVO support), FLV, OGG, 以及其他ffmpeg支持的格式!
 视频编码:H264, VC-1, MPEG-2, MPEG4-ASP (Divx/Xvid), VP8, MJPEG 等。
 音频编码:AAC, AC3, DTS(-HD), TrueHD, MP3/MP2, Vorbis, LPCM 等。
 字幕编码:VOB, DVB Subs, PGS, SRT, SSA/ASS, Text

  流媒体数据传输中的时延和抖动是可以通过缓存的办法减少影响,所以流媒体业务可以允许在一定范围内的时延和抖动。但丢包会对流媒体数,据播放质量造成极其重大的影响。丢包率会造成视频和音频质量严重恶化,小的丢包率会造成图像的失真和语音的间歇中断,过高的丢包率甚至可以导致业务的中断。网络设计的目标是丢包率为零,但显然不存在这样的理想网络。所以丢包的大小将直接决定流媒体业务质量的好坏。

  LAV Filter 是一款视频分离和解码软件,他的分离器封装了FFMPEG中的libavformat,解码器则封装了FFMPEG中的libavcodec。它支持十分广泛的视音频格式。LAV Filter 中最著名的就是 LAV Splitter,支持Matroska /WebM,MPEG-TS/PS,MP4/MOV,FLV,OGM / OGG,AVI等其他格式,广泛存在于各种视频播放器(暴风影音这类的)之中。
源代码位于GitHub或Google Code:https://github.com/Nevcairiel/LAVFilters http://code.google.com/p/lavfilters/
 LAV Filter整个解决方案由8个工程组成,以下为一部分:
  baseclasses:DirectShow基类,在DirectShow的SDK中也有,是微软为了简化DirectShow开发而提供的。
  Demuxers:解封装的基类,LAVSplitter需要调用其中的方法完成解封装操作。
  LAVAudio:音频解码Filter。封装了libavcodec。
  LAVSplitter:解封装Filter。封装了libavformat。
  LAVVideo:视频解码Filter。封装了libavcodec。
  libbluray:蓝光的支持。

  LAV Video 是使用很广泛的DirectShow Filter。它封装了FFMPEG中的libavcodec,支持十分广泛的视频格式的解码。
  Media Player Classic - Home Cinema

  Dolphin播放器(Dolphin Player)是一款开源的音频和视频播放器,它支持大多数的音频和视频文件模式,也支持大部分的字幕文件格式。它是基于ffmpeg的。http://code.google.com/p/dolphin-player/。live555是使用十分广泛的开源流媒体服务器。

> DirectShow Filter
  DirectShow Filter,字幕叠加(FilterTitleOverlay)。DirectShow的视频播放器。DirectShow是一个庞大的框架,可以在Windows下实现多种多样的视频处理需求。

> ffdshow
  ffdshow封装了多个视音频解码器,比如libmpeg2,libavcodec,xvid等等。其中最重要的是libavcodec,这个是ffmpeg提供的解码器,在ffdshow中起到了“挑大梁”的作用。
  fdshow支持很多种滤镜,可以支持多种视频和音频的后期效果。例如OSD滤镜支持在视频的左上角显示视频相关的信息。而可视化滤镜则支持显示视频每一帧的运动矢量以及量化参数。位图覆盖(Bitmap)滤镜(Filter)。

> SDL播放视频的技术
 实际上SDL本身并不提供视音频播放的功能,它只是封装了视音频播放的底层API。在Windows平台下,SDL封装了Direct3D这类的API用于播放视频;封装了DirectSound这类的API用于播放音频。因为SDL的编写目的就是简化视音频播放的开发难度,所以使用SDL播放视频(YUV/RGB)和音频(PCM)数据非常的容易。
 SDL(Simple DirectMedia Layer)是一套开放源代码的跨平台多媒体开发库,使用C语言写成。SDL提供了数种控制图像、声音、输出入的函数,让开发者只要用相同或是相似的代码就可以开发出跨多个平台(Linux、Windows、Mac OS X等)的应用软件。目前SDL多用于开发游戏、模拟器、媒体播放器等多媒体应用领域。纯音频,不包含视频的那种。SDL播放音频,一般情况下不会有问题。
FFMPEG+SDL的简单播放器,FFMPEG用于编解码,SDL用于视频渲染。Github:https://github.com/leixiaohua1020/simplest_ffmpeg_player
常用编码软件简单使用记录 2 : 非自主编码器- https://blog.youkuaiyun.com/leixiaohua1020/article/details/39510759

> 最简单的视频编码器:编译(libx264,libx265,libvpx), 
 x264,x265,vpx这三个开源的视频编码器可以说是当今“最火”的视频编码器。x264现在占据着H.264视频编码器的半壁江山;x265则是目前实现H.265标准最好的开源视频编码器,并且在未来可能接替x264;而vpx则是Google推出的开源视频编码器,它提出的VP9编码标准的性能也不错。
 1.最简单的视频编码器:基于libx264(编码YUV为H.264)
 “轻量级”的编码器。因为它不再包含FFmpeg的代码,直接调用libx264完成编码。因此项目的体积非常小巧。该编码器可以将输入的YUV数据编码为H.264码流文件。
 2.最简单的视频编码器:基于libx265(编码YUV为H.265),H.265(HEVC)
 “轻量级”的编码器。因为它不再包含FFmpeg的代码,直接调用libx265完成编码。因此项目的体积非常小巧。该编码器可以将输入的YUV数据编码为H.265码流文件。
 3.最简单的视频编码器:基于libvpx(编码YUV为VP8),基于libvpx的VP8视频编码器
  与H.264不同,VP8的裸流(即不包含封装格式的纯视频数据流)是不能播放的。换言之,VP8的裸流必须存放在容器中才可以播放。官方示例代码中存储VP8视频流的封装格式是IVF。

  Dan Grois等人在论文《Performance Comparison of H.265/MPEG-HEVC, VP9, andH.264/MPEG-AVC Encoders》中,比较了下一代编码标准HEVC,VP9的以及当前主流编码标准H.264之间的性能。
 选用的编码器如下:HEVC:HM;VP9:libvpx;H.264:x264。

 Google  VP8/Vorbis/WebM (统称为 WebM)。基于HEVC(H.265)的的应用级别的编码器发展的速度很快。所说的应用级别,就是指速度比较快的,有实际应用价值的编码器。目前可以直接使用的有两个:x265,DivX265。DivX265是DivX发布的HEVC编码器,不开源,但是免费,是基于控制台的。

> libVLC的视频播放器
  最简单的基于libVLC的视频播放器。VLC Media Player是一款优秀的播放器,但是由于它的源代码编译的难度比较大,一直没有深入研究过它的开发方面的技术。最简单的基于libVLC的视频播放器(图形界面版)。最简单的基于libVLC的推流器。

> YUV/RGB播放器,既支持YUV又支持RGB的播放器
 与RGB每个像素点的每个分量取值范围为0-255不同(每个分量占8bit),YUV取值范围有两种:
(1)以Rec.601为代表(还包括BT.709 / BT.2020)的广播电视标准中,Y的取值范围是16-235,U、V的取值范围是16-240。FFmpeg中称之为“mpeg”范围。
(2)以JPEG为代表的标准中,Y、U、V的取值范围都是0-255。FFmpeg中称之为“jpeg” 范围。
原版项目地址:https://sourceforge.net/projects/raw-yuvplayer/
修改版源码地址:https://github.com/leixiaohua1020/YUVplayer

> RTMP播放器
 基于Flash的RTMP播放器/推流器才能算得上是RTMP技术中的“正规军”。RTMP本身设计出来就是用于Flash平台之间通信的,而且RTMP最大的优势——“无插件直播”,也是得益于广泛安装在客户端的Flash Player。
  基于Flash的网页播放器相比于其他网页播放器来说最大的优势就是“免插件安装”了,这一点可以很大的提高用户的体验质量。早些时候网络视频(尤其是直播)一般都使用ActiveX控件作为视频播放器,而这些控件并不普及,所以终端用户必须下载相关的插件才能收看节目,因而对很多不熟悉电脑的用户造成了很大的障碍。直到Flash网页播放器的出现,这一障碍才得到了解决。

 -- RTMP Sample Player VideoJS,Video.js官网:http://www.videojs.com/
 注:Video.js是一个基于JavaScript的HTML5视频播放器,本身是开源的。

  RTMP Sample Player VideoJS是基于Video.js的RTMP播放器。其中包含两个播放器:
1.Sample Player VideoJS:HTTP点播网页播放器
2.RTMP Sample Player VideoJS:RTMP网页播放器

 -- RTMP Sample Player Flowplayer,FlowPlayer官网:http://flash.flowplayer.org/
注:FlowPlayer有两个版本:HTML5版本和Flash版本,本文中使用的是Flash版本。

  RTMP Sample Player Flowplayer是基于FlowPlayer的网页播放器。其中包含两个播放器:
Sample Player Flowplayer:HTTP点播网页播放器
RTMP Sample Player Flowplayer:RTMP网页播放器

 -- RTMP Sample Player JWPlayer,JW Player官网:http://www.jwplayer.com
 注:最新版的JW Player似乎不能免费使用RTMP播放功能了,这里使用的是旧版的JW Player

  RTMP Sample Player JWPlayer是基于JW Player的RTMP播放器。其中包含两个播放器:
Sample Player JWPlayer:HTTP点播网页播放器
RTMP Sample Player JWPlayer:RTMP网页播放器

世界上最快的VP9视频解码器 As before , I was very excited when Google released VP9 – for one, because I was one of the people involved in creating it back when I worked for Google (I no longer do). How good is it, and how much better can it be? To evaluate that question, Clément Bœsch and I set out to write a VP9 decoder from scratch for FFmpeg. The goals never changed from the original ffvp8 situation (community-developed, fast, free from the beginning). We also wanted to answer new questions: how does a well-written decoder compare, speed-wise, with a well-written decoder for other codecs? TLDR (see rest of post for details): as a codec, VP9 is quite impressive – it beats x264 in many cases. However, the encoder is slow, very slow. At higher speed settings, the quality gain melts away. This seems to be similar to what people report about HEVC (using e.g. x265 as an encoder). single-threaded decoding speed of libvpx isn’t great. FFvp9 beats it by 25-50% on a variety of machines. FFvp9 is somewhat slower than ffvp8, and somewhat faster than ffh264 decoding speed (for files encoded to matching SSIM scores). Multi-threading performance in libvpx is deplorable, it gains virtually nothing from its loopfilter-mt algorithm. FFvp9 multi-threading gains nearly as much as ffh264/ffvp8 multithreading, but there’s a cap (material-, settings- and resolution-dependent, we found it to be around 3 threads in one of our clips although it’s typically higher) after which further threads don’t cause any more gain. The codec itself To start, we did some tests on the encoder itself. The direct goal here was to identify bitrates at which encodings would give matching SSIM-scores so we could do same-quality decoder performance measurements. However, as such, it also allows us to compare encoder performance in itself. We used settings very close to recommended settings forVP8,VP9andx264, optimized for SSIM as a metric. As source clips, we chose Sintel (1920×1080 CGI content, source ), a 2-minute clip from Tears of Steel (1920×800 cinematic content, source ), and a 3-minute clip from Enter the Void (1920×818 high-grain/noise content,screenshot). For each, we encoded at various bitrates and plotted effective bitrate versus SSIM . sintel_ssimtos_ssimetv_ssim You’ll notice that in most cases, VP9 can indeed beat x264, but, there’s some big caveats: VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. Higher –cpu-used=X parameters make the quality gains melt away. libvpx’ VP9 encodes miss the target bitrates by a long shot (100% off) for the ETV clip, possibly because of our use of –aq-mode=1. libvpx tends to slowly crumble at higher bitrates for hard content – again, look at the ETV clip, where x264 shows some serious mature killer instinct at the high bitrate end of things. Overall, these results are promising, although the lack-of-speed is a serious issue. Decoder performance For decoding performance measurements, we chose (Sintel)500 (VP9), 1200 (VP8) and 700 (x264) kbps (SSIM=19.8); Tears of Steel4.0 (VP9), 7.9 (VP8) and 6.3 (x264) mbps (SSIM=19.2); and Enter the Void 9.7 (VP9), 16.6 (VP8) and 10.7 (x264) mbps (SSIM=16.2). We used FFmpeg to decode each of these files, either using the built-in decoder (to compare between codecs), or using libvpx-vp9 (to compare ffvp9 versus libvpx). Decoding time was measured in seconds using “time ffmpeg -threads 1 [-c:v libvpx-vp9] -i $file -f null -v 0 -nostats – 2>&1 | grep user”, with this FFmpeg and this libvpx revision (downloaded on Feb 20th, 2014). sintel_archs tos_archsetv_archs A few notes on ffvp9 vs. libvpx-vp9 performance: ffvp9 beats libvpx consistently by 25-50%. In practice, this means that typical middle- to high-end hardware will be able to playback 4K content using ffvp9, but not using libvpx. Low-end hardware will struggle to playback even 720p content using libvpx (but do so fine using ffvp9). on Haswell, the difference is significantly smaller than on sandybridge, likely because libvpx has some AVX2 optimizations (e.g. for MC and loop filtering), whereas ffvp9 doesn’t have that yet; this means this difference might grow over time as ffvp9 gets AVX2 optimizations also. on the Atom, the differences are significantly smaller than on other systems; the reason for this is likely that we haven’t done any significant work on Atom-performance yet. Atom has unusually large latencies between GPRs and XMM registers, which means you need to take special care in ordering your instructions to prevent unnecessary halts – we haven’t done anything in that area yet (for ffvp9). Some users may find that ffvp9 is a lot slower than advertised on 32bit; this is correct, most of our SIMD only works on 64bit machines. If you have 32bit software, port it to 64bit. Can’t port it? Ditch it. Nobody owns 32bit x86 hardware anymore these days. So how does VP9 decoding performance compare to that of other codecs? There’s basically two ways to measure this: same-bitrate (e.g. a 500kbps VP8 file vs. a 500kbps VP9 file, where the VP9 file likely looks much better), or same-quality (e.g. a VP8 file with SSIM=19.2 vs. a VP9 file with SSIM=19.2, where the VP9 file likely has a much lower bitrate). We did same-quality measurements, and found: ffvp9 tends to beat ffh264 by a tiny bit (10%), except on Atom (which is likely because ffh264 has received more Atom-specific attention than ffvp9). ffvp9 tends to be quite a bit slower than ffvp8 (15%), although the massive bitrate differences in Enter the Void actually makes it win for that clip (by about 15%, except on Atom). Given that Google promised VP9 would be no more than 40% more complex than VP8, it seems they kept that promise. we did some same-bitrate comparisons, and found that x264 and ffvp9 are essentially identical in that scenario (with x264 having slightly lower SSIM scores); vp8 tends to be about 50% faster, but looks significantly worse. Multithreading One of the killer-features in FFmpeg is frame-level multithreading, which allows multiple cores to decode different video frames in parallel. Libvpx also supports multithreading. So which is better?
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值