一些关于流媒体的基本概念

ASF

ASF是(Advanced Streaming Format 高级串流格式)的缩写,是 Microsoft 为 Windows 98 所开发的串流多媒体文件格式。ASF是微软公司Windows Media的核心。这是一种包含音频、视频、图像以及控制命令脚本的数据格式。这个词汇当前可和 WMA 及 WMV 互换使用。 ASF是一个开放标准,它能依靠多种协议在多种网络环境下支持数据的传送。同JPG、MPG文件一样,ASF文件也是一种文件类型,但它是专为在IP网上传送有同步关系的多媒体数据而设计的,所以ASF格式的信息特别适合在IP网上传输。ASF文件的内容既可以是我们熟悉的普通文件,也可以是一个由编码设备实时生成的连续的数据流,所以ASF既可以传送人们事先录制好的节目,也可以传送实时产生的节目。 ASF用于排列、组织、同步多媒体数据以利于通过网络传输。ASF是一种数据格式,它也可用于指定实况演示。ASF最适于通过网络发送多媒体流,也同样适于在本地播放。任何压缩/解压缩运算法则(编解码器)都可用来编码ASF流。 Windows Media Service的核心是ASF。ASF是一种数据格式,音频、视频、图像以及控制命令脚本等多媒体信息通过这种格式,以网络数据包的形式传输,实现流式多媒体内容发布。其中,在网络上传输的内容就称为ASF Stream。ASF支持任意的压缩/解压缩编码方式,并可以使用任何一种底层网络传输协议,具有很大的灵活性。 Microsoft Media player是能播放几乎所有多媒体文件的播放器,支持ASF在Internet网上的流文件格式,可以一边下载一边实时播放,无需下载完再听。 ASF流文件的数据速率可以在28.8Kbps到3Mbps之间变化。用户可以根据自己应用环境和网络条件选择一个合适的速率,实现VOD点播和直播。

FLV

FLV 是FLASH VIDEO的简称,FLV流媒体格式是随着Flash MX的推出发展而来的视频格式。由于它形成的文件极小、加载速度极快,使得网络观看视频文件成为可能,它的出现有效地解决了视频文件导入Flash后,使导出的SWF文件体积庞大,不能在网络上很好的使用等缺点。 FLV是被众多新一代视频分享网站所采用,是目前增长最快、最为广泛的视频传播格式。是在sorenson公司的压缩算法的基础上开发出来的。FLV格式不仅可以轻松的导入Flash中,速度极快,并且能起到保护版权的作用,并且可以不通过本地的微软或者REAL播放器播放视频。

H264

H.264,同时也是MPEG-4第十部分,是由ITU-T视频编码专家组(VCEG)和ISO/IEC动态图像专家组(MPEG)联合组成的联合视频组(JVT,Joint Video Team)提出的高度压缩数字视频编解码器标准。H.264是ITU-T以H.26x系列为名称命名的标准之一,同时AVC是ISO/IEC MPEG一方的称呼。这个标准通常被称之为H.264/AVC(或者AVC/H.264或者H.264/MPEG-4 AVC或MPEG-4/H.264 AVC)而明确的说明它两方面的开发者。该标准最早来自于ITU-T的称之为H.26L的项目的开发。H.26L这个名称虽然不太常见,但是一直被使用着。该标准第一版的最终草案于2003年5月完成。 H.264是国际标准化组织(ISO)和国际电信联盟(ITU)共同提出的继MPEG4之后的新一代数字视频压缩格式,它既保留了以往压缩技术的优点和精华又具有其他压缩技术无法比拟的许多优点。 1.低码率(Low Bit Rate):和MPEG2和MPEG4 ASP等压缩技术相比,在同等图像质量下,采用H.264技术压缩后的数据量只有MPEG2的1/8,MPEG4的1/3。 显然,H.264压缩技术的采用将大大节省用户的下载时间和数据流量收费。 2.高质量的图象:H.264能提供连续、流畅的高质量图象(DVD质量)。 3.容错能力强:H.264提供了解决在不稳定网络环境下容易发生的丢包等错误的必要工具。 4.网络适应性强:H.264提供了网络抽象层(Network Abstraction Layer),使得H.264的文件能容易地在不同网络上传输(例如互联网,CDMA,GPRS,WCDMA,CDMA2000等)。 H.264最大的优势是具有很高的数据压缩比率,在同等图像质量的条件下,H.264的压缩比是MPEG-2的2倍以上,是MPEG-4的1.5~2倍。举个例子,原始文件的大小如果为88GB,采用MPEG-2压缩标准压缩后变成3.5GB,压缩比为25∶1,而采用H.264压缩标准压缩后变为879MB,从88GB到879MB,H.264的压缩比达到惊人的102∶1。低码率(Low Bit Rate)对H.264的高的压缩比起到了重要的作用,和MPEG-2和MPEG-4 ASP等压缩技术相比,H.264压缩技术将大大节省用户的下载时间和数据流量收费。尤其值得一提的是,H.264在具有高压缩比的同时还拥有高质量流畅的图像,正因为如此,经过H.264压缩的视频数据,在网络传输过程中所需要的带宽更少,也更加经济。

X264

x264是一个开源的H.264视频编码函数库。是最好的有损视频编码器。 x264始于2003年,从当开源社区的MPEG4-ASP编码器Xvid小有所成时开始的,经过几年的开发,特别是Dark Shikari加入开发后,x264逐渐成为了最好的视频编码器。

ffm

FFM and FFM2 are formats used by ffserver. They allow storing a wide variety of video and audio streams and encoding options, and can store a moving time segment of an infinite movie or a whole movie. FFM is version specific, and there is limited compatibility of FFM files generated by one version of ffmpeg/ffserver and another version of ffmpeg/ffserver. It may work but it is not guaranteed to work. FFM2 is extensible while maintaining compatibility and should work between differing versions of tools. FFM2 is the default.

AVI

AVI英文全称为Audio Video Interleaved,即音频视频交错格式。是将语音和影像同步组合在一起的文件格式。它对视频文件采用了一种有损压缩方式,但压缩比较高,因此尽管画面质量不是太好,但其应用范围仍然非常广泛。AVI支持256色和RLE压缩。AVI信息主要应用在多媒体光盘上,用来保存电视、电影等各种影像信息。 它于1992年被Microsoft公司推出,随Windows3.1一起被人们所认识和熟知。所谓“音频视频交错”,就是可以将视频和音频交织在一起进行同步播放。这种视频格式的优点是可以跨多个平台使用,其缺点是体积过于庞大,而且更加糟糕的是压缩标准不统一,最普遍的现象就是高版本Windows媒体播放器播放不了采用早期编码编辑的AⅥ格式视频,而低版本Windows媒体播放器又播放不了采用最新编码编辑的AⅥ格式视频,所以我们在进行一些AⅥ格式的视频播放时常会出现由于视频编码问题而造成的视频不能播放或即使能够播放,但存在不能调节播放进度和播放时只有声音没有图像等一些莫名其妙的问题,如果用户在进行AⅥ格式的视频播放时遇到了这些问题,可以通过下载相应的解码器来解决。是目前视频文件的主流。这种格式的文件随处可见,比如一些游戏、教育软件的片头,多媒体光盘中,都会有不少的AVI。

rtsp

RTSP(Real Time Streaming Protocol),实时流传输协议,是TCP/IP协议体系中的一个应用层协议,由哥伦比亚大学、网景和RealNetworks公司提交的IETF RFC标准。该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP在体系结构上位于RTP和RTCP之上,它使用TCP或RTP完成数据传输。HTTP与RTSP相比,HTTP传送HTML,而RTSP传送的是多媒体数据。HTTP请求由客户机发出,服务器作出响应;使用RTSP时,客户机和服务器都可以发出请求,即RTSP可以是双向的。 RTSP是用来控制声音或影像的多媒体串流协议,并允许同时多个串流需求控制,传输时所用的网络通讯协定并不在其定义的范围内,服务器端可以自行选择使用TCP或UDP来传送串流内容,它的语法和运作跟HTTP 1.1类似,但并不特别强调时间同步,所以比较能容忍网络延迟。而前面提到的允许同时多个串流需求控制(Multicast),除了可以降低服务器端的网络用量,更进而支持多方视讯会议(Video Conference)。因为与HTTP1.1的运作方式相似,所以代理服务器〈Proxy〉的快取功能〈Cache〉也同样适用于RTSP,并因RTSP具有重新导向功能,可视实际负载情况来转换提供服务的服务器,以避免过大的负载集中于同一服务器而造成延迟。 该协议用于C/S模型,是一个基于文本的协议,用于在客户端和服务器端建立和协商实时流会话。 实时流协议(RTSP)是应用级协议,控制实时数据的发送。RTSP提供了一个可扩展框架,使实时数据,如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接,为选择发送通道,如UDP、组播UDP与TCP,提供途径,并为选择基于RTP上发送机制提供方法。 实时流协议(RTSP)建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的,通常它本身并不发送连续流。换言之,RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接,如TCP。在RTSP连接期间,RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外,可使用无连接传输协议,如UDP。RTSP流控制的流可能用到RTP,但RTSP操作并不依赖用于携带连续媒体的传输机制。

rtp

RTP(Real-time Transport Protocol,实时传输协议)是一个网络传输协议,它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的,后在RFC3550中进行更新。 国际电信联盟ITU-T也发布了自己的RTP文档,作为H.225.0,但是后来当IETF发布了关于它的稳定的标准RFC后就被取消了。它作为因特网标准在RFC 3550(该文档的旧版本是RFC 1889)有详细说明。RFC 3551(STD 65,旧版本是RFC 1890)详细描述了使用最小控制的音频和视频会议。 RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议,但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议),视频会议和一键通(Push to Talk)系统(配合H.323或SIP),使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用,而且它是建立在用户数据报协议上的。 实时传输协议(RTP)为数据提供了具有实时特征的端对端传送服务,如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP 上运行 RTP 以便使用其多路结点和校验服务;这两种协议都提供了传输层协议的功能。但是 RTP 可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式,那么 RTP 可以使用该组播表传输数据到多个目的地。 RTP 本身并没有提供按时发送机制或其它服务质量(QoS)保证,它依赖于低层服务去实现这一过程。 RTP 并不保证传送或防止无序传送,也不确定底层网络的可靠性。 RTP 实行有序传送, RTP 中的序列号允许接收方重组发送方的包序列,同时序列号也能用于决定适当的包位置,例如:在视频解码中,就不需要顺序解码。 RTP 由两个紧密链接部分组成: RTP ― 传送具有实时属性的数据;

mms

Microsoft Media Server (MMS), a Microsoft proprietary network-streaming protocol, serves to transfer unicast data in Windows Media Services (previously called NetShow Services). MMS can be transported via UDP or TCP. The MMS default port is UDP/TCP 1755. Microsoft deprecated MMS in favor of RTSP (TCP/UDP port 554) in 2003 with the release of the Windows Media Services 9 Series, but continued to support the MMS for some time in the interest of backwards compatibility. Support for the protocol was finally dropped in Windows Media Services 2008. As of 2012 Microsoft still recommends[1] using “mms://” as a “protocol rollover URL”. As part of protocol rollover a Windows Media Player version 9, 10, or 11 client opening an “mms://” URL will attempt to connect first with RTSP over UDP and if that fails it will attempt RTSP over TCP. After an RTSP attempt fails, Windows Media Player versions 9 & 10 will attempt MMS over UDP, then MMS over TCP. If using Windows Media Player 11 and an RTSP attempt fails, or if using a previous version of Windows Media Player and MMS fails, a modified version of a HTTP over TCP connection will be attempted. This modified version is referred to by some third parties as MMSH, and by Microsoft as MS-WMSP (Windows Media HTTP Streaming Protocol). The URI scheme “mms://” has also been proposed to be used for the unrelated Multimedia Messaging Service (MMS) protocol. For several years developers of the SDP Multimedia download-tool reverse-engineered the MMS protocol and published unofficial documentation for it. However, Microsoft finally released the protocol specification in February 2008.

mmsh

MMS is a proprietary digital media streaming protocol developed by Microsoft. It is supported in Windows Media Player and Microsoft® Windows® Media Server v4.0 or later. MMSH is MMS over HTTP.

ref:http://wiki.videolan.org/MMSH ref:http://baike.baidu.com/view/7704.htm ref:http://en.wikipedia.org/wiki/Microsoft_Media_Server ref:http://baike.baidu.com/view/364757.htm ref:http://baike.baidu.com/view/56322.htm?fromId=403562 ref:http://nmm-hd.org/doc/X264%E4%BD%BF%E7%94%A8%E4%BB%8B%E7%BB%8D ref:http://www.videolan.org/developers/x264.html ref:http://ffmpeg.org/ffserver.html#What-is-FFM_002c-FFM2 ref:http://baike.baidu.com/view/7697.htm ref:http://baike.baidu.com/view/610472.htm#sub7572724

linux + ffmpeg + eclipse 调试

使用linux + ffmpeg + eclipse调试步骤 OS : ubuntu 12.04 Eclipse : 3.7.2

  • 为Eclipse安装cdt插件,使其支持c/c++
  • 导入ffmpeg项目

File —-> Import —-> c / c++ —-> Existing Code as Makefile Project

  • 输入 Project Name, 选择ffmpeg所在目录, Toolchain选择Linux GCC
  • 项目右键 —-> Debug As —-> Local C/C++ Application —-> 选择需要调试的项目

​ 你需要选择带_g的程序才能做调试(如ffplay_g)

ffmpeg库调试

如果使用make install安装ffmpeg的动态链接库是不带调试信息的。所以需要手工拷贝。

  • 删除/usr/lib或者/usr/local/lib中的所有ffmpeg库文件

  • 进入ffmpeg源代码目录,拷贝编译出来的库文件到/usr/local/lib

    sudo cp -av `find "*.so*"`  /usr/local/lib/ 
    

DDS图像格式

名词解释

DDS是一种图片格式。DirectDraw Surface的缩写,它是DirectX纹理压缩(DirectX Texture Compression,简称DXTC)的产物。 我们可以利用一些程序轻松地将bmp,tga等文件转化为dds文件,也有photo, gimp的插件能帮助我们利用我们所熟悉的工具来完成转化工作。dds档还起到了压缩文件大小的作用,这在游戏制作中是很重要的,更小的纹理容量意味着显示速度的增加和显存要求的降低在选择生成文件时,有多种格式可供选择。 DDS文件格式要追述到S3(Silicon & Software Systems)公司提出的一种纹理压缩格式S3TC(S3 Texture Compression), 其目的是通过对纹理的压缩, 以达到节约系统带宽并提高效能的目的. S3TC就是通过压缩方式, 利用有限的纹理缓存空间来存储更多的纹理, 因为它支持6:1的压缩比例, 所以6M的纹理可以被压缩为1M存放在材质缓存中, 从而在节约了缓存的同时也提高了显示性能. 后来的DXTC和FXT1都是与S3TC类似的技术, 它们分别是微软和3dfx开发的纹理压缩标准, FXT1能提供比S3TC更高的压缩比, 达到8:1, 同时它也在3DFX新版本的Glide中得到支持. DXTC是1999年微软从S3公司取得S3TC的授权后更名而来的, 并在DirectX6中提供了支持, 即使用户的图形硬件不能支持S3TC, DirectX API会自动解码压缩后的纹理贴图. 压缩纹理贴图可以使用高品质的离线压缩器, 不会造成加载程序时有很多延时, 而DDS文件就可以使用DXTC方式压缩或是存储未压缩的像素格式。

格式介绍

有3种DXTC的格式可供使用,分别是DXT1,DXT3和DXT5。

  • DXT1 压缩比例:1:8 压缩比最高,它只有1Bit Alpha,Alpha通道信息几乎完全丧失。一般将不带Alpha通道的图片压缩成这种格式。如Worldwind 用的卫星图片。

DXT1 支持 1 bit 的 alpha 通道。这个其实是可选的。每个 4×4 的块可以根据需要有或没有这个透明通道。不需要 alpha 通道时,每个块可以有四种颜色(其中两个是插值得到的);需要 alpha 通道时,则只能有三种颜色,11 被保留用来描述透明的点。区分是否用通道,要根据每个块开始的两个高彩颜色值:color_0 和color_1 。如果 color_0 在数值上(当作无符号短整型)大于 color_1 则没有通道。 可惜的是,在 dds 文件的文件头中,没有任何一个地方描述了:整个图片是否有至少一个块包含了 alpha 通道。但是在 3d 程序中,却需要知道这一信息以使程序可以更高效的运行。 对于软解码程序,更需要知道这一信息。因为带通道时,我们需要把数据解码成 RGBA5551 的格式;而不带通道时,则需要解码成 RGB565 格式。 一开始我以为需要扫描整个数据段,检查是否至少有一个块的 color_0 小于等于 color_1 。实际看了几个用工具生成的 dds 文件才发现自己错了。nvidia 的 dxt tools 压缩 DXT1 图片时,需要手动指明是否需要 1 bit 的通道。如果你指定不带通道,那么每个 4×4 数据块头上的两个调色盘颜色值的大小次序是无关的(这样做,由于插值方案的差异,有可能得到更好一点的图象质量)。也就是说,只有压缩图片的人知道图片上是否有通道,而文件头上并无记录。

  • DXT3 压缩比例:1:4 使用了4Bit Alpha,可以有16个Alpha值,可很好地用于alpha通道锐利、对比强烈的半透和镂空材质。

DXT3 就是在 DXT1 的基础上,增加了 4bit 的 alpha 通道,每个 4×4 块多用了 64bit 来保存这些 alpha 通道信息。(数据储存时,在每个数据块中,alpha 通道信息放在颜色信息的前面)

  • DXT5 压缩比例:1:4 使用了线形插值的4Bit Alpha,特别适合Alpha通道柔和的材质,比如高光掩码材质。

DXT5 对 alpha 通道的储存作了改进,有点意思,值得一提的是:它依旧用 64bit 储存 16 个 alpha 信息。前面 2 个字节(16bit)保存了当前块的最大 alpha 值和最小 alpha 值。接下来的 48 bit ,每个像素占用 3bit 空间,刚好描述 4×4 个像素。 当 alpha_0 大于 alpha_1时,我们后面的 3bit 可以表示 8 级的插值;反之则保留 110 和 111 分别表示 alpha 为 0 和 255 的情况,中间可以有 6 级过度的插值。

DDS压缩

如果要使用dds压缩,源图片的长宽必须是2的整数次方。

ref1: http://baike.baidu.com/view/5470373.htm ref2: http://blog.codingnow.com/2007/05/dxt.html

C++创建DDS文件

OS: ubuntu12.04

创建DDS文件头

这里只使用DXT1压缩,mipmaps为1,输入格式为GBR

   #define PUTL32(buf, l) \
        (buf)[0] = ((l)      ) & 0xff; \
	(buf)[1] = ((l) >>  8) & 0xff; \
	(buf)[2] = ((l) >> 16) & 0xff; \
	(buf)[3] = ((l) >> 24) & 0xff;

    int compression = DDS_COMPRESS_BC1;
    unsigned int rmask = 0x00ff0000;
    unsigned int gmask = 0x0000ff00;
    unsigned int bmask = 0x000000ff;
    unsigned int amask = 0xff000000;
    unsigned int data_size = 0;
    unsigned int ddsSZ = 0;
    unsigned int fourcc = 0;

    unsigned char hdr[DDS_HEADERSIZE] = {0};
    int fmtbpp = 3, flags = 0, pflags = 0, caps = 0, caps2 = 0, num_mipmaps = 1, size = 0;

    PUTL32(hdr, FOURCC('D', 'D', 'S', ' '));
    PUTL32(hdr + 4, 124);
    PUTL32(hdr + 12, height);
    PUTL32(hdr + 16, width);
    PUTL32(hdr + 76, 32);
    PUTL32(hdr + 88, fmtbpp << 3);
    PUTL32(hdr + 92, rmask);
    PUTL32(hdr + 96, gmask);
    PUTL32(hdr + 100, bmask);
    PUTL32(hdr + 104, amask);

    flags = DDSD_CAPS | DDSD_PIXELFORMAT | DDSD_WIDTH | DDSD_HEIGHT;
    caps = DDSCAPS_TEXTURE;

    PUTL32(hdr + 28, num_mipmaps);
    PUTL32(hdr + 108, caps);
    PUTL32(hdr + 112, caps2);

    flags |= DDSD_LINEARSIZE;
    pflags |= DDPF_FOURCC;
    fourcc = FOURCC('D', 'X', 'T', '1');

    PUTL32(hdr + 8, flags);
    PUTL32(hdr + 80, pflags);
    PUTL32(hdr + 84, fourcc);

    size = ((width + 3) >> 2) * ((height + 3) >> 2);
    size *= 8;

    PUTL32(hdr + 20, size);

BMP图像格式

BMP(全称Bitmap)是Window操作系统中的标准图像文件格式,可以分成两类:设备相关位图(DDB)和设备无关位图(DIB),使用非常广。它采用位映射存储格式,除了图像深度可选以外,不采用其他任何压缩,因此,BMP文件所占用的空间很大。BMP文件的图像深度可选lbit、4bit、8bit及24bit。BMP文件存储数据时,图像的扫描方式是按从左到右、从下到上的顺序。由于BMP文件格式是Windows环境中交换与图有关的数据的一种标准,因此在Windows环境中运行的图形图像软件都支持BMP图像格式。

文件格式

格式组成

典型的BMP图像文件由四部分组成:

  • 位图头文件数据结构,它包含BMP图像文件的类型、显示内容等信息;
  • 位图信息数据结构,它包含有BMP图像的宽、高、压缩方法,以及定义颜色等信息;
  • 调色板,这个部分是可选的,有些位图需要调色板,有些位图,比如真彩色图(24位的BMP)就不需要调色板;
  • 位图数据,这部分的内容根据BMP位图使用的位数不同而不同,在24位图中直接使用RGB,而其他的小于24位的使用调色板中颜色索引值。

格式类型

位图一共有两种类型,即:设备相关位图(DDB)和设备无关位图(DIB)。DDB位图在早期的Windows系统(Windows 3.0以前)中是很普遍的,事实上它也是唯一的。然而,随着显示器制造技术的进步,以及显示设备的多样化,DDB位图的一些固有的问题开始浮现出来了。比如,它不能够存储(或者说获取)创建这张图片的原始设备的分辨率,这样,应用程序就不能快速的判断客户机的显示设备是否适合显示这张图片。为了解决这一难题,微软创建了DIB位图格式。 设备无关位图 (Device-Independent Bitmap) DIB位图包含下列的颜色和尺寸信息:

  • 原始设备(即创建图片的设备)的颜色格式。
  • 原始设备的分辨率。
  • 原始设备的调色板
  • 一个位数组,由红、绿、蓝(RGB)三个值代表一个像素。
  • 一个数组压缩标志,用于表明数据的压缩方案(如果需要的话)。

以上这些信息保存在BITMAPINFO结构中,该结构由BITMAPINFOHEADER结构和两个或更多个RGBQUAD结构所组成。BITMAPINFOHEADER结构所包含的成员表明了图像的尺寸、原始设备的颜色格式、以及数据压缩方案等信息。RGBQUAD结构标识了像素所用到的颜色数据。 DIB位图也有两种形式,即:底到上型DIB(bottom-up),和顶到下型DIB(top-down)。底到上型DIB的原点(origin)在图像的左下角,而顶到下型DIB的原点在图像的左上角。如果DIB的高度值(由BITMAPINFOHEADER结构中的biHeight成员标识)是一个正值,那么就表明这个DIB是一个底到上型DIB,如果高度值是一个负值,那么它就是一个顶到下型DIB。注意:顶到下型的DIB位图是不能被压缩的。 位图的颜色格式是通过颜色面板值(planes)和颜色位值(bitcount)计算得来的,颜色面板值永远是1,而颜色位值则可以是1、4、8、16、24、32其中的一个。如果它是1,则表示位图是一张单色位图(译者注:通常是黑白位图,只有黑和白两种颜色,当然它也可以是任意两种指定的颜色),如果它是4,则表示这是一张VGA位图,如果它是8、16、24、或是32,则表示该位图是其他设备所产生的位图。如果应用程序想获取当前显示设备(或打印机)的颜色位值(或称位深度),可调用API函数GetDeviceCaps(),并将第二个参数设为BITSPIXEL即可。 显示设备的分辨率是以每米多少个像素来表明的,应用程序可以通过以下三个步骤来获取显示设备或打印机的水平分辨率:

  • 调用GetDeviceCaps()函数,指定第二个参数为HORZRES。
  • 再次调用GetDeviceCaps()函数,指定第二个参数为HORZSIZE。
  • 用第一个返回值除以第二个返回值。即:GetDeviceCaps(hDC,HORZRES)/GetDeviceCaps(hDC,HORZSIZE);

应用程序也可以使用相同的三个步骤来获取设备的垂直分辨率,不同之处只是要将HORZRES替换为VERTRES,把HORZSIZE替换为VERTSIZE,即可。 调色板是被保存在一个RGBQUAD结构的数组中,该结构指出了每一种颜色的红、绿、蓝的分量值。位数组中的每一个索引都对应于一个调色板项(即一个RGBQUAD结构),应用程序将根据这种对应关系,将像素索引值转换为像素RGB值(真实的像素颜色)。应用程序也可以通过调用GetDeviceCaps()函数来获取当前显示设备的调色板尺寸(将该函数的第二个参数设为NUMCOLORS即可)。 Win32 API支持位数据的压缩(只对8位和4位的底到上型DIB位图)。压缩方法是采用运行长度编码方案(RLE),RLE使用两个字节来描述一个句法,第一个字节表示重复像素的个数,第二个字节表示重复像素的索引值。有关压缩位图的详细信息请参见对BITMAPINFOHEADER结构的解释。 应用程序可以从一个DDB位图创建出一个DIB位图,步骤是,先初始化一些必要的结构,然后再调用GetDIBits()函数。不过,有些显示设备有可能不支持这个函数,你可以通过调用GetDeviceCaps()函数来确定一下(GetDeviceCaps()函数在调用时指定RC_DI_BITMAP作为RASTERCAPS的标志)。 应用程序可以用DIB去设置显示设备上的像素(译者注:也就是显示DIB),方法是调用SetDIBitsToDevice()函数或调用StretchDIBits()函数。同样,有些显示设备也有可能不支持以上这两个函数,这时你可以指定RC_DIBTODEV作为RASTERCAPS标志,然后调用GetDeviceCaps()函数来判断该设备是否支持SetDIBitsToDevice()函数。也可以指定RC_STRETCHDIB作为RASTERCAPS标志来调用GetDeviceCaps()函数,来判断该设备是否支持StretchDIBits()函数。 如果应用程序只是要简单的显示一个已经存在的DIB位图,那么它只要调用SetDIBitsToDevice()函数就可以。比如一个电子表格软件,它可以打开一个图表文件,在窗口中简单的调用SetDIBitsToDevice()函数,将图形显示在窗口中。但如果应用程序要重复的绘制位图的话,则应该使用BitBlt()函数,因为BitBlt()函数的执行速度要比SetDIBitsToDevice()函数快很多。 设备相关位图 (Device-Dependent Bitmaps) 设备相关位图(DDB)之所以现在还被系统支持,只是为了兼容旧的Windows 3.0软件,如果程序员现在要开发一个与位图有关的程序,则应该尽量使用或生成DIB格式的位图。 DDB位图是被一个单个结构BITMAP所描述,这个结构的成员标明了该位图的宽度、高度、设备的颜色格式等信息。 DDB位图也有两种类型,即:可废弃的(discardable)DDB和不可废弃的(nondiscardable)DDB。可废弃的DDB位图就是一种当系统内存缺乏,并且该位图也没有被选入设备描述表(DC)的时候,系统就会把该DDB位图从内存中清除(即废弃)。不可废弃的DDB则是无论系统内存多少都不会被系统清除的DDB。API函数CreateDiscardableBitmap()函数可用于创建可废弃位图。而函数CreateBitmap()、CreateCompatibleBitmap()、和CreateBitmapIndirect()可用于创建不可废弃的位图。 应用程序可以通过一个DIB位图而创建一个DDB位图,只要先初始化一些必要的结构,然后再调用CreateDIBitmap()函数就可以。如果在调用该函数时指定了CBM_INIT标志,那么这一次调用就等价于先调用CreateCompatibleBitmap()创建当前设备格式的DDB位图,然后又调用SetDIBits()函数转换DIB格式到DDB格式。(可能有些设备并不支持SetDIBits()函数,你可以指定RC_DI_BITMAP作为RASTERCAPS的标志,然后调用GetDeviceCaps()函数来判断一下)。 对应数据结构

  • BMP文件组成

BMP文件由文件头、位图信息头、颜色信息和图形数据四部分组成。

  • BMP文件头(14字节)

BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。 其结构定义如下:

typedef struct tagBITMAPFILEHEADER
{
	WORD bfType; // 位图文件的类型,必须为BM(1-2字节)
	DWORD bfSize; // 位图文件的大小,以字节为单位(3-6字节)
	WORD bfReserved1; // 位图文件保留字,必须为0(7-8字节)
	WORD bfReserved2; // 位图文件保留字,必须为0(9-10字节)
	DWORD bfOffBits; // 位图数据的起始位置,以相对于位图(11-14字节)
	// 文件头的偏移量表示,以字节为单位
} BITMAPFILEHEADER;
  • 位图信息头(40字节)

BMP位图信息头数据用于说明位图的尺寸等信息。 typedef struct tagBITMAPINFOHEADER{ DWORD biSize; // 本结构所占用字节数(15-18字节) LONG biWidth; // 位图的宽度,以像素为单位(19-22字节) LONG biHeight; // 位图的高度,以像素为单位(23-26字节) WORD biPlanes; // 目标设备的级别,必须为1(27-28字节) WORD biBitCount;// 每个像素所需的位数,必须是1(双色),(29-30字节) // 4(16色),8(256色)或24(真彩色)之一 DWORD biCompression; // 位图压缩类型,必须是 0(不压缩),(31-34字节) // 1(BI_RLE8压缩类型)或2(BI_RLE4压缩类型)之一 DWORD biSizeImage; // 位图的大小,以字节为单位(35-38字节) LONG biXPelsPerMeter; // 位图水平分辨率,每米像素数(39-42字节) LONG biYPelsPerMeter; // 位图垂直分辨率,每米像素数(43-46字节) DWORD biClrUsed;// 位图实际使用的颜色表中的颜色数(47-50字节) DWORD biClrImportant;// 位图显示过程中重要的颜色数(51-54字节) } BITMAPINFOHEADER;

  • 颜色表

颜色表用于说明位图中的颜色,它有若干个表项,每一个表项是一个RGBQUAD类型的结构,定义一种颜色。RGBQUAD结构的定义如下: typedef struct tagRGBQUAD { BYTE rgbBlue;// 蓝色的亮度(值范围为0-255) BYTE rgbGreen; // 绿色的亮度(值范围为0-255) BYTE rgbRed; // 红色的亮度(值范围为0-255) BYTE rgbReserved;// 保留,必须为0 } RGBQUAD; 颜色表中RGBQUAD结构数据的个数有biBitCount来确定: 当biBitCount=1,4,8时,分别有2,16,256个表项; 当biBitCount=24时,没有颜色表项。 位图信息头和颜色表组成位图信息,BITMAPINFO结构定义如下: typedef struct tagBITMAPINFO { BITMAPINFOHEADER bmiHeader; // 位图信息头 RGBQUAD bmiColors[1]; // 颜色表 } BITMAPINFO;

  • 位图数据

位图数据记录了位图的每一个像素值,记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。位图的一个像素值所占的字节数: 当biBitCount=1时,8个像素占1个字节; 当biBitCount=4时,2个像素占1个字节; 当biBitCount=8时,1个像素占1个字节; 当biBitCount=24时,1个像素占3个字节; Windows规定一个扫描行所占的字节数必须是 4的倍数(即以long为单位),不足的以0填充, biSizeImage = ((((bi.biWidth * bi.biBitCount) + 31) & ~31) / 8) * bi.biHeight; 具体数据举例: 如某BMP文件开头: 424D 4690 0000 0000 0000 4600 0000 2800 0000 8000 0000 9000 0000 01001000 0300 0000 0090 0000 A00F 0000 A00F 0000 0000 0000 0000 000000F8 E007 1F00 0000*02F1 84F1 04F1 84F1 84F1 06F2 84F1 06F2 04F2 86F2 06F2 86F2 86F2 …. …. 读取方法

/*
功能:在图片的第50行画一条黑线
为简化代码,只支持24位色的图片
codeblocks下正确运行。VC下需要将二维数组img改为malloc动态分配。
*/
#include 
#include 
typedef struct{
BYTE b;
BYTE g;
BYTE r;
}RGB;
int main( void )
{
BITMAPFILEHEADER fileHeader;
BITMAPINFOHEADER infoHeader;
FILE* pfin =fopen("原始图像.bmp","rb");
FILE* pfout = fopen( "修改后的图像.bmp" , "wb");
//Read the Bitmap file header;
fread(&fileHeader,sizeof(BITMAPFILEHEADER),1,pfin);
//Read the Bitmap info header;
fread(&infoHeader,sizeof(BITMAPINFOHEADER),1,pfin);
//为简化代码,只处理24位彩色
if( infoHeader.biBitCount == 24 )
{
int size = infoHeader.biWidth*infoHeader.biHeight;
RGB img[infoHeader.biHeight][infoHeader.biWidth];
fread( img , sizeof(RGB) , size , pfin );
//把第50行染成黑色
int i = 0;
for( ; i < infoHeader.biWidth ; i++ )
{
img[50][i].b =img[50][i].g=img[50][i].r= 0;
}
//将修改后的图片保存到文件
fwrite( &fileHeader , sizeof(fileHeader) , 1 , pfout );
fwrite( &infoHeader , sizeof(infoHeader) , 1 , pfout );
fwrite( img , sizeof(RGB) , size , pfout );
}
}

文件部分

图像文件头

1)1-2:(这里的数字代表的是”字”,即两个字节,下同)图像文件头。0x4d42=’BM’,表示是Windows支持的BMP格式。(注意:查ascii表B 0x42,M0x4d,bfType 为两个字节,B为low字节,M为high字节所以bfType=0x4D42,而不是0x424D,但注意) 2)3-6:整个文件大小。4690 0000,为00009046h=36934。 3)7-8:保留,必须设置为0。 4)9-10:保留,必须设置为0。 5)11-14:从文件开始到位图数据之间的偏移量(14+40+4*(2^biBitCount))。4600 0000,为00000046h=70,上面的文件头就是35字=70字节。

位图信息头

6)15-18:位图图信息头长度。 7) 19-22:位图宽度,以像素为单位。8000 0000,为00000080h=128。 8)23-26:位图高度,以像素为单位。9000 0000,为00000090h=144。 9)27-28:位图的位面数,该值总是1。0100,为0001h=1。 10)29-30:每个像素的位数。有1(单色),4(16色),8(256色),16(64K色,高彩色),24(16M色,真彩色),32(4096M色,增强型真彩色)。1000为0010h=16。 11)31-34:压缩说明:有0(不压缩),1(RLE 8,8位RLE压缩),2(RLE 4,4位RLE压缩,3(Bitfields,位域存放)。RLE简单地说是采用像素数+像素值的方式进行压缩。T408采用的是位域存放方式,用两个字节表示一个像素,位域分配为r5b6g5。图中0300 0000为00000003h=3。 12)35-38:用字节数表示的位图数据的大小,该数必须是4的倍数,数值上等于(≥位图宽度的最小的4的倍数)×位图高度×每个像素位数。0090 0000为00009000h=80×90×2h=36864。 13)39-42:用象素/米表示的水平分辨率。A00F 0000为0000 0FA0h=4000。 14)43-46:用象素/米表示的垂直分辨率。A00F 0000为0000 0FA0h=4000。 15)47-50:位图使用的颜色索引数。设为0的话,则说明使用所有调色板项。 16)51-54:对图象显示有重要影响的颜色索引的数目。如果是0,表示都重要。

彩色板

17)(55+0)到(50-1+2^biBitCount):彩色板规范。对于调色板中的每个表项,用下述方法来描述RGB的值: 1字节用于蓝色分量 1字节用于绿色分量 1字节用于红色分量 1字节用于填充符(设置为0) 对于24-位真彩色图像就不使用彩色板,因为位图中的RGB值就代表了每个象素的颜色。 如,彩色板为00F8 0000 E007 0000 1F00 0000 0000 0000,其中: 00F8为F800h = 1111 1000 0000 0000(二进制),是蓝色分量的掩码。 E007 为 07E0h = 0000 0111 1110 0000(二进制),是绿色分量的掩码。 1F00为001Fh = 0000 0000 0001 [1]1111(二进制),是红色分量的掩码。 0000 总设置为0。 将掩码跟像素值进行“与”运算再进行移位操作就可以得到各色分量值。看看掩码,就可以明白事实上在每个像素值的两个字节16位中,按从高到低取5、6、5位分别就是r、g、b分量值。取出分量值后把r、g、b值分别乘以8、4、8就可以补齐第个分量为一个字节,再把这三个字节按rgb组合,放入存储器(同样要反序),就可以转换为24位标准BMP格式了。 图像数据阵列 18)55(无调色板)-bfSize:每两个字节表示一个像素。阵列中的第一个字节表示位图左下角的象素,而最后一个字节表示位图右上角的象素。

图像数据阵列

每两个字节表示一个像素。阵列中的第一个字节表示位图左下角的象素,而最后一个字节表示位图右上角的象素。

存储算法

BMP文件通常是不压缩的,所以它们通常比同一幅图像的压缩图像文件格式要大很多。例如,一个800×600的24位几乎占据1.4MB空间。因此它们通常不适合在因特网或者其它低速或者有容量限制的媒介上进行传输。根据颜色深度的不同,图像上的一个像素可以用一个或者多个字节表示,它由n/8所确定(n是位深度,1字节包含8个数据位)。图片浏览器等基于字节的ASCII值计算像素的颜色,然后从调色板中读出相应的值。更为详细的信息请参阅下面关于位图文件的部分。n位2n种颜色的位图近似字节数可以用下面的公式计算:BMP文件大小约等于 54+42的n次方+(wh*n)/8,其中高度和宽度都是像素数。需要注意的是上面公式中的54是位图文件的文件头,是彩色调色板的大小。另外需要注意的是这是一个近似值,对于n位的位图图像来说,尽管可能有最多2n中颜色,一个特定的图像可能并不会使用这些所有的颜色。由于彩色调色板仅仅定义了图像所用的颜色,所以实际的彩色调色板将小于。如果想知道这些值是如何得到的,请参考下面文件格式的部分。由于存储算法本身决定的因素,根据几个图像参数的不同计算出的大小与实际的文件大小将会有一些细小的差别。

存储序列

图象数据BGRA:默认的BMP是不支持ALPHA通道的,但对32位BMP而言,每个象素用32位(4个字节)表示,前三个字节表示RGB分量,最后一个字节可以做为ALPHA通道的值,因此32位位图可以存储带ALPHA通道的图像,在文件中,各分量的存储顺序为BGRA,BGRA,BGRA,BGRA… 另外要注意的是,BMP图像的象素存储顺序是从下到上