MARKDOWN-SYNTAX-CN

@weibo:badwtg1111

EMail

My Personal Homepage

<< 访问 Wow!Ubuntu

NOTE: This is Simplelified Chinese Edition Document of Markdown Syntax. If you are seeking for English Edition Document. Please refer to Markdown: Syntax.

声明： 这份文档派生(fork)于繁体中文版，在此基础上进行了繁体转简体工作，并进行了适当的润色。此文档用 Markdown 语法编写，你可以到这里查看它的源文件。「繁体中文版的原始文件可以查看这里 。」–By @riku

注： 本项目托管于 GitCafe上，请通过”派生”和”合并请求”来帮忙改进本项目。

Markdown 语法说明 (简体中文版) /

(点击查看快速入门)

概述

宗旨

Markdown 的目标是实现「易读易写」。

可读性，无论如何，都是最重要的。一份使用 Markdown 格式撰写的文件应该可以直接以纯文本发布，并且看起来不会像是由许多标签或是格式指令所构成。Markdown 语法受到一些既有 text-to-HTML 格式的影响，包括 Setext、atx、Textile、reStructuredText、Grutatext 和 EtText，而最大灵感来源其实是纯文本电子邮件的格式。

总之， Markdown 的语法全由一些符号所组成，这些符号经过精挑细选，其作用一目了然。比如：在文字两旁加上星号，看起来就像*强调*。Markdown 的列表看起来，嗯，就是列表。Markdown 的区块引用看起来就真的像是引用一段文字，就像你曾在电子邮件中见过的那样。

兼容 HTML

Markdown 语法的目标是：成为一种适用于网络的书写语言。

Markdown 不是想要取代 HTML，甚至也没有要和它相近，它的语法种类很少，只对应 HTML 标记的一小部分。Markdown 的构想不是要使得 HTML 文档更容易书写。在我看来， HTML 已经很容易写了。Markdown 的理念是，能让文档更容易读、写和随意改。HTML 是一种发布的格式，Markdown 是一种书写的格式。就这样，Markdown 的格式语法只涵盖纯文本可以涵盖的范围。

不在 Markdown 涵盖范围之内的标签，都可以直接在文档里面用 HTML 撰写。不需要额外标注这是 HTML 或是 Markdown；只要直接加标签就可以了。

要制约的只有一些 HTML 区块元素――比如 <div>、<table>、<pre>、<p> 等标签，必须在前后加上空行与其它内容区隔开，还要求它们的开始标签与结尾标签不能用制表符或空格来缩进。Markdown 的生成器有足够智能，不会在 HTML 区块标签外加上不必要的 <p> 标签。

例子如下，在 Markdown 文件里加上一段 HTML 表格：

这是一个普通段落。

<table>
    <tr>
        <td>Foo</td>
    </tr>
</table>

这是另一个普通段落。

请注意，在 HTML 区块标签间的 Markdown 格式语法将不会被处理。比如，你在 HTML 区块内使用 Markdown 样式的*强调*会没有效果。

HTML 的区段（行内）标签如 <span>、<cite>、<del> 可以在 Markdown 的段落、列表或是标题里随意使用。依照个人习惯，甚至可以不用 Markdown 格式，而直接采用 HTML 标签来格式化。举例说明：如果比较喜欢 HTML 的 <a> 或 <img> 标签，可以直接使用这些标签，而不用 Markdown 提供的链接或是图像标签语法。

和处在 HTML 区块标签间不同，Markdown 语法在 HTML 区段标签间是有效的。

特殊字符自动转换

在 HTML 文件中，有两个字符需要特殊处理： < 和 & 。 < 符号用于起始标签，& 符号则用于标记 HTML 实体，如果你只是想要显示这些字符的原型，你必须要使用实体的形式，像是 &lt; 和 &amp;。

& 字符尤其让网络文档编写者受折磨，如果你要打「AT&T」 ，你必须要写成「AT&amp;T」。而网址中的 & 字符也要转换。比如你要链接到：

http://images.google.com/images?num=30&q=larry+bird

你必须要把网址转换写为：

http://images.google.com/images?num=30&amp;q=larry+bird

才能放到链接标签的 href 属性里。不用说也知道这很容易忽略，这也可能是 HTML 标准检验所检查到的错误中，数量最多的。

Markdown 让你可以自然地书写字符，需要转换的由它来处理好了。如果你使用的 & 字符是 HTML 字符实体的一部分，它会保留原状，否则它会被转换成 &amp;。

所以你如果要在文档中插入一个版权符号 ©，你可以这样写：

&copy;

Markdown 会保留它不动。而若你写：

AT&T

Markdown 就会将它转为：

AT&amp;T

类似的状况也会发生在 < 符号上，因为 Markdown 允许 兼容 HTML ，如果你是把 < 符号作为 HTML 标签的定界符使用，那 Markdown 也不会对它做任何转换，但是如果你写：

4 < 5

Markdown 将会把它转换为：

4 &lt; 5

不过需要注意的是，code 范围内，不论是行内还是区块， < 和 & 两个符号都一定会被转换成 HTML 实体，这项特性让你可以很容易地用 Markdown 写 HTML code （和 HTML 相对而言， HTML 语法中，你要把所有的 < 和 & 都转换为 HTML 实体，才能在 HTML 文件里面写出 HTML code。）

区块元素

段落和换行

一个 Markdown 段落是由一个或多个连续的文本行组成，它的前后要有一个以上的空行（空行的定义是显示上看起来像是空的，便会被视为空行。比方说，若某一行只包含空格和制表符，则该行也会被视为空行）。普通段落不该用空格或制表符来缩进。

「由一个或多个连续的文本行组成」这句话其实暗示了 Markdown 允许段落内的强迫换行（插入换行符），这个特性和其他大部分的 text-to-HTML 格式不一样（包括 Movable Type 的「Convert Line Breaks」选项），其它的格式会把每个换行符都转成 <br /> 标签。

如果你确实想要依赖 Markdown 来插入 <br /> 标签的话，在插入处先按入两个以上的空格然后回车。

的确，需要多费点事（多加空格）来产生 <br /> ，但是简单地「每个换行都转换为 <br />」的方法在 Markdown 中并不适合， Markdown 中 email 式的 区块引用 和多段落的 列表 在使用换行来排版的时候，不但更好用，还更方便阅读。

Markdown 支持两种标题的语法，类 Setext 和类 atx 形式。

类 Setext 形式是用底线的形式，利用 = （最高阶标题）和 - （第二阶标题），例如：

This is an H1
=============

This is an H2
-------------

任何数量的 = 和 - 都可以有效果。

类 Atx 形式则是在行首插入 1 到 6 个 # ，对应到标题 1 到 6 阶，例如：

# 这是 H1

## 这是 H2

###### 这是 H6

你可以选择性地「闭合」类 atx 样式的标题，这纯粹只是美观用的，若是觉得这样看起来比较舒适，你就可以在行尾加上 #，而行尾的 # 数量也不用和开头一样（行首的井字符数量决定标题的阶数）：

# 这是 H1 #

## 这是 H2 ##

### 这是 H3 ######

区块引用 Blockquotes

Markdown 标记区块引用是使用类似 email 中用 > 的引用方式。如果你还熟悉在 email 信件中的引言部分，你就知道怎么在 Markdown 文件中建立一个区块引用，那会看起来像是你自己先断好行，然后在每行的最前面加上 > ：

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
> consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
> Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
> 
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
> id sem consectetuer libero luctus adipiscing.

Markdown 也允许你偷懒只在整个段落的第一行最前面加上 > ：

> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.

> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
id sem consectetuer libero luctus adipiscing.

区块引用可以嵌套（例如：引用内的引用），只要根据层次加上不同数量的 > ：

> This is the first level of quoting.
>
> > This is nested blockquote.
>
> Back to the first level.

引用的区块内也可以使用其他的 Markdown 语法，包括标题、列表、代码区块等：

> ## 这是一个标题。
> 
> 1.   这是第一行列表项。
> 2.   这是第二行列表项。
> 
> 给出一些例子代码：
> 
>     return shell_exec("echo $input | $markdown_script");

任何像样的文本编辑器都能轻松地建立 email 型的引用。例如在 BBEdit 中，你可以选取文字后然后从选单中选择增加引用阶层。

列表

Markdown 支持有序列表和无序列表。

无序列表使用星号、加号或是减号作为列表标记：

*   Red
*   Green
*   Blue

等同于：

+   Red
+   Green
+   Blue

也等同于：

-   Red
-   Green
-   Blue

有序列表则使用数字接着一个英文句点：

1.  Bird
2.  McHale
3.  Parish

很重要的一点是，你在列表标记上使用的数字并不会影响输出的 HTML 结果，上面的列表所产生的 HTML 标记为：

<ol>
<li>Bird</li>
<li>McHale</li>
<li>Parish</li>
</ol>

如果你的列表标记写成：

1.  Bird
1.  McHale
1.  Parish

或甚至是：

3. Bird
1. McHale
8. Parish

你都会得到完全相同的 HTML 输出。重点在于，你可以让 Markdown 文件的列表数字和输出的结果相同，或是你懒一点，你可以完全不用在意数字的正确性。

如果你使用懒惰的写法，建议第一个项目最好还是从 1. 开始，因为 Markdown 未来可能会支持有序列表的 start 属性。

列表项目标记通常是放在最左边，但是其实也可以缩进，最多 3 个空格，项目标记后面则一定要接着至少一个空格或制表符。

要让列表看起来更漂亮，你可以把内容用固定的缩进整理好：

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
    Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
    viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
    Suspendisse id sem consectetuer libero luctus adipiscing.

但是如果你懒，那也行：

*   Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi,
viverra nec, fringilla in, laoreet vitae, risus.
*   Donec sit amet nisl. Aliquam semper ipsum sit amet velit.
Suspendisse id sem consectetuer libero luctus adipiscing.

如果列表项目间用空行分开，在输出 HTML 时 Markdown 就会将项目内容用 <p> 标签包起来，举例来说：

*   Bird
*   Magic

会被转换为：

<ul>
<li>Bird</li>
<li>Magic</li>
</ul>

但是这个：

*   Bird

*   Magic

会被转换为：

<ul>
<li><p>Bird</p></li>
<li><p>Magic</p></li>
</ul>

列表项目可以包含多个段落，每个项目下的段落都必须缩进 4 个空格或是 1 个制表符：

1.  This is a list item with two paragraphs. Lorem ipsum dolor
    sit amet, consectetuer adipiscing elit. Aliquam hendrerit
    mi posuere lectus.

    Vestibulum enim wisi, viverra nec, fringilla in, laoreet
    vitae, risus. Donec sit amet nisl. Aliquam semper ipsum
    sit amet velit.

2.  Suspendisse id sem consectetuer libero luctus adipiscing.

如果你每行都有缩进，看起来会看好很多，当然，再次地，如果你很懒惰，Markdown 也允许：

*   This is a list item with two paragraphs.

    This is the second paragraph in the list item. You're
only required to indent the first line. Lorem ipsum dolor
sit amet, consectetuer adipiscing elit.

*   Another item in the same list.

如果要在列表项目内放进引用，那 > 就需要缩进：

*   A list item with a blockquote:

    > This is a blockquote
    > inside a list item.

如果要放代码区块的话，该区块就需要缩进两次，也就是 8 个空格或是 2 个制表符：

*   一列表项包含一个列表区块：

        <代码写在这>

当然，项目列表很可能会不小心产生，像是下面这样的写法：

1986. What a great season.

换句话说，也就是在行首出现数字-句点-空白，要避免这样的状况，你可以在句点前面加上反斜杠。

1986\. What a great season.

代码区块

和程序相关的写作或是标签语言原始码通常会有已经排版好的代码区块，通常这些区块我们并不希望它以一般段落文件的方式去排版，而是照原来的样子显示，Markdown 会用 <pre> 和 <code> 标签来把代码区块包起来。

要在 Markdown 中建立代码区块很简单，只要简单地缩进 4 个空格或是 1 个制表符就可以，例如，下面的输入：

这是一个普通段落：

    这是一个代码区块。

Markdown 会转换成：

<p>这是一个普通段落：</p>

<pre><code>这是一个代码区块。
</code></pre>

这个每行一阶的缩进（4 个空格或是 1 个制表符），都会被移除，例如：

Here is an example of AppleScript:

    tell application "Foo"
        beep
    end tell

会被转换为：

<p>Here is an example of AppleScript:</p>

<pre><code>tell application "Foo"
    beep
end tell
</code></pre>

一个代码区块会一直持续到没有缩进的那一行（或是文件结尾）。

在代码区块里面， & 、 < 和 > 会自动转成 HTML 实体，这样的方式让你非常容易使用 Markdown 插入范例用的 HTML 原始码，只需要复制贴上，再加上缩进就可以了，剩下的 Markdown 都会帮你处理，例如：

    <div class="footer">
        &copy; 2004 Foo Corporation
    </div>

会被转换为：

<pre><code>&lt;div class="footer"&gt;
    &amp;copy; 2004 Foo Corporation
&lt;/div&gt;
</code></pre>

代码区块中，一般的 Markdown 语法不会被转换，像是星号便只是星号，这表示你可以很容易地以 Markdown 语法撰写 Markdown 语法相关的文件。

分隔线

你可以在一行中用三个以上的星号、减号、底线来建立一个分隔线，行内不能有其他东西。你也可以在星号或是减号中间插入空格。下面每种写法都可以建立分隔线：

* * *

***

*****

- - -

---------------------------------------

区段元素

Markdown 支持两种形式的链接语法： 行内式和参考式两种形式。

不管是哪一种，链接文字都是用 [方括号] 来标记。

要建立一个行内式的链接，只要在方块括号后面紧接着圆括号并插入网址链接即可，如果你还想要加上链接的 title 文字，只要在网址后面，用双引号把 title 文字包起来即可，例如：

This is [an example](http://example.com/ "Title") inline link.

[This link](http://example.net/) has no title attribute.

会产生：

<p>This is <a href="http://example.com/" title="Title">
an example</a> inline link.</p>

<p><a href="http://example.net/">This link</a> has no
title attribute.</p>

如果你是要链接到同样主机的资源，你可以使用相对路径：

See my [About](/about/) page for details.

参考式的链接是在链接文字的括号后面再接上另一个方括号，而在第二个方括号里面要填入用以辨识链接的标记：

This is [an example][id] reference-style link.

你也可以选择性地在两个方括号中间加上一个空格：

This is [an example] [id] reference-style link.

接着，在文件的任意处，你可以把这个标记的链接内容定义出来：

[id]: http://example.com/  "Optional Title Here"

链接内容定义的形式为：

  • 方括号（前面可以选择性地加上至多三个空格来缩进），里面输入链接文字
  • 接着一个冒号
  • 接着一个以上的空格或制表符
  • 接着链接的网址
  • 选择性地接着 title 内容，可以用单引号、双引号或是括弧包着

下面这三种链接的定义都是相同：

[foo]: http://example.com/  "Optional Title Here"
[foo]: http://example.com/  'Optional Title Here'
[foo]: http://example.com/  (Optional Title Here)

请注意：有一个已知的问题是 Markdown.pl 1.0.1 会忽略单引号包起来的链接 title。

链接网址也可以用方括号包起来：

[id]: <http://example.com/>  "Optional Title Here"

你也可以把 title 属性放到下一行，也可以加一些缩进，若网址太长的话，这样会比较好看：

[id]: http://example.com/longish/path/to/resource/here
    "Optional Title Here"

网址定义只有在产生链接的时候用到，并不会直接出现在文件之中。

链接辨别标签可以有字母、数字、空白和标点符号，但是并不区分大小写，因此下面两个链接是一样的：

[link text][a]
[link text][A]

隐式链接标记功能让你可以省略指定链接标记，这种情形下，链接标记会视为等同于链接文字，要用隐式链接标记只要在链接文字后面加上一个空的方括号，如果你要让 “Google” 链接到 google.com，你可以简化成：

[Google][]

然后定义链接内容：

[Google]: http://google.com/

由于链接文字可能包含空白，所以这种简化型的标记内也许包含多个单词：

Visit [Daring Fireball][] for more information.

然后接着定义链接：

[Daring Fireball]: http://daringfireball.net/

链接的定义可以放在文件中的任何一个地方，我比较偏好直接放在链接出现段落的后面，你也可以把它放在文件最后面，就像是注解一样。

下面是一个参考式链接的范例：

I get 10 times more traffic from [Google] [1] than from
[Yahoo] [2] or [MSN] [3].

  [1]: http://google.com/        "Google"
  [2]: http://search.yahoo.com/  "Yahoo Search"
  [3]: http://search.msn.com/    "MSN Search"

如果改成用链接名称的方式写：

I get 10 times more traffic from [Google][] than from
[Yahoo][] or [MSN][].

  [google]: http://google.com/        "Google"
  [yahoo]:  http://search.yahoo.com/  "Yahoo Search"
  [msn]:    http://search.msn.com/    "MSN Search"

上面两种写法都会产生下面的 HTML。

<p>I get 10 times more traffic from <a href="http://google.com/"
title="Google">Google</a> than from
<a href="http://search.yahoo.com/" title="Yahoo Search">Yahoo</a>
or <a href="http://search.msn.com/" title="MSN Search">MSN</a>.</p>

下面是用行内式写的同样一段内容的 Markdown 文件，提供作为比较之用：

I get 10 times more traffic from [Google](http://google.com/ "Google")
than from [Yahoo](http://search.yahoo.com/ "Yahoo Search") or
[MSN](http://search.msn.com/ "MSN Search").

参考式的链接其实重点不在于它比较好写，而是它比较好读，比较一下上面的范例，使用参考式的文章本身只有 81 个字符，但是用行内形式的却会增加到 176 个字元，如果是用纯 HTML 格式来写，会有 234 个字元，在 HTML 格式中，标签比文本还要多。

使用 Markdown 的参考式链接，可以让文件更像是浏览器最后产生的结果，让你可以把一些标记相关的元数据移到段落文字之外，你就可以增加链接而不让文章的阅读感觉被打断。

强调

Markdown 使用星号（*）和底线（_）作为标记强调字词的符号，被 * 或 _ 包围的字词会被转成用 <em> 标签包围，用两个 * 或 _ 包起来的话，则会被转成 <strong>，例如：

*single asterisks*

_single underscores_

**double asterisks**

__double underscores__

会转成：

<em>single asterisks</em>

<em>single underscores</em>

<strong>double asterisks</strong>

<strong>double underscores</strong>

你可以随便用你喜欢的样式，唯一的限制是，你用什么符号开启标签，就要用什么符号结束。

强调也可以直接插在文字中间：

un*frigging*believable

但是如果你的 * 和 _ 两边都有空白的话，它们就只会被当成普通的符号。

如果要在文字前后直接插入普通的星号或底线，你可以用反斜线：

\*this text is surrounded by literal asterisks\*

代码

如果要标记一小段行内代码，你可以用反引号把它包起来（`），例如：

Use the `printf()` function.

会产生：

<p>Use the <code>printf()</code> function.</p>

如果要在代码区段内插入反引号，你可以用多个反引号来开启和结束代码区段：

``There is a literal backtick (`) here.``

这段语法会产生：

<p><code>There is a literal backtick (`) here.</code></p>

代码区段的起始和结束端都可以放入一个空白，起始端后面一个，结束端前面一个，这样你就可以在区段的一开始就插入反引号：

A single backtick in a code span: `` ` ``

A backtick-delimited string in a code span: `` `foo` ``

会产生：

<p>A single backtick in a code span: <code>`</code></p>

<p>A backtick-delimited string in a code span: <code>`foo`</code></p>

在代码区段内，& 和方括号都会被自动地转成 HTML 实体，这使得插入 HTML 原始码变得很容易，Markdown 会把下面这段：

Please don't use any `<blink>` tags.

转为：

<p>Please don't use any <code>&lt;blink&gt;</code> tags.</p>

你也可以这样写：

`&#8212;` is the decimal-encoded equivalent of `&mdash;`.

以产生：

<p><code>&amp;#8212;</code> is the decimal-encoded
equivalent of <code>&amp;mdash;</code>.</p>

图片

很明显地，要在纯文字应用中设计一个「自然」的语法来插入图片是有一定难度的。

Markdown 使用一种和链接很相似的语法来标记图片，同样也允许两种样式： 行内式和参考式。

行内式的图片语法看起来像是：

![Alt text](/path/to/img.jpg)

![Alt text](/path/to/img.jpg "Optional title")

详细叙述如下：

  • 一个惊叹号 !
  • 接着一个方括号，里面放上图片的替代文字
  • 接着一个普通括号，里面放上图片的网址，最后还可以用引号包住并加上 选择性的 ‘title’ 文字。

参考式的图片语法则长得像这样：

![Alt text][id]

「id」是图片参考的名称，图片参考的定义方式则和连结参考一样：

[id]: url/to/image  "Optional title attribute"

到目前为止， Markdown 还没有办法指定图片的宽高，如果你需要的话，你可以使用普通的 <img> 标签。

其它

Markdown 支持以比较简短的自动链接形式来处理网址和电子邮件信箱，只要是用方括号包起来， Markdown 就会自动把它转成链接。一般网址的链接文字就和链接地址一样，例如：

<http://example.com/>

Markdown 会转为：

<a href="http://example.com/">http://example.com/</a>

邮址的自动链接也很类似，只是 Markdown 会先做一个编码转换的过程，把文字字符转成 16 进位码的 HTML 实体，这样的格式可以糊弄一些不好的邮址收集机器人，例如：

<address@example.com>

Markdown 会转成：

<a href="&#x6D;&#x61;i&#x6C;&#x74;&#x6F;:&#x61;&#x64;&#x64;&#x72;&#x65;
&#115;&#115;&#64;&#101;&#120;&#x61;&#109;&#x70;&#x6C;e&#x2E;&#99;&#111;
&#109;">&#x61;&#x64;&#x64;&#x72;&#x65;&#115;&#115;&#64;&#101;&#120;&#x61;
&#109;&#x70;&#x6C;e&#x2E;&#99;&#111;&#109;</a>

在浏览器里面，这段字串（其实是 <a href="mailto:address@example.com">address@example.com</a>）会变成一个可以点击的「address@example.com」链接。

（这种作法虽然可以糊弄不少的机器人，但并不能全部挡下来，不过总比什么都不做好些。不管怎样，公开你的信箱终究会引来广告信件的。）

反斜杠

Markdown 可以利用反斜杠来插入一些在语法中有其它意义的符号，例如：如果你想要用星号加在文字旁边的方式来做出强调效果（但不用 <em> 标签），你可以在星号的前面加上反斜杠：

\*literal asterisks\*

Markdown 支持以下这些符号前面加上反斜杠来帮助插入普通的符号：

\   反斜线
`   反引号
*   星号
_   底线
{}  花括号
[]  方括号
()  括弧
#   井字号
+   加号
-   减号
.   英文句点
!   惊叹号

感谢

感谢 leafy7382 协助翻译，hlb、Randylien 帮忙润稿，ethantw 的汉字标准格式・CSS Reset， WM 回报文字错误。

感谢 fenprace，addv。

Markdown 免费编辑器

Windows 平台

Linux 平台

Mac 平台

在线编辑器

浏览器插件

高级应用

*** 如有更好的 Markdown 免费编辑器推荐，请到这里反馈，谢谢！

Chrome Markdown Preview

Chrome中实时预览Markdown

FEB 27TH, 2015 | COMMENTS

改用Octopress后，我就经常用Vim来写blog了，在Vim中安装了一个Markdown语法高亮的插件，叫做：vim-markdown ，用起来还不错。

虽然在Mac OS下，早已经有一款大名鼎鼎的Markdown编辑器，叫做Mou。Mou强大的地方还在于，支持Markdown的实时预览，能立马看到发布成页面后的效果。 不过，我还是习惯了Vim的各种快捷键，难以割舍。最近，刚好在Chrome发现了一个扩展，叫做：Markdown Preview Plus，这样Vim配合Chrome，也能实现”预览” Markdown效果的功能了。

其大致原理，就是在Chrome现实的时候，这款扩展能够自动把Markdown转换为HTML语法并进行显示。而且，每次当你在Vim中保存Markdown文件后，还能自动刷新。

使用的方法也很简单，直接在Chrome的store中安装这款扩展，然后，记得在Chrome的扩展设置页面，允许这个扩展访问本地文件。因为我们要直接从Chrome中打开我们在本地编辑的那个Markdown文件。

这样，就能一边用Vim写blog，一边用Chrome预览效果了，实在是相当的方便啊！

另外，这款Markdown Preview的扩展，还支持在显示的时候选择主题，包括Github等风格的主题，可以自由选择。另外，还支持直接导出成HTML文件的功能，供各位慢慢折腾……

Posted by badwtg1111

Android平台Gallery2应用分析(七)—PhotoPage图片解码

Android平台Gallery2应用分析(七)—PhotoPage图片解码 分类： Android多媒体 2013-12-23 16:15 1347人阅读 评论(1) 收藏 举报 AndroidGallery2应用相册多媒体 PhotoPage图片解码 从前文可知，PhotoPage的图片解码始于PhotoPage的onResume()调用updateImageRequests()。先看下代码： [java] view plaincopy在CODE上查看代码片派生到我的代码片 private void updateImageRequests() {
……
int currentIndex = mCurrentIndex;
MediaItem item = mData[currentIndex % DATA_CACHE_SIZE];
……
// 1. 遍历sImageFetchSeq，查看当前图片符合哪种类型，调用startTaskIfNeeded
Future<?> task = null;
for (int i = 0; i < sImageFetchSeq.length; i++) {
int offset = sImageFetchSeq[i].indexOffset;
int bit = sImageFetchSeq[i].imageBit;
if (bit == BIT_FULL_IMAGE && !mNeedFullImage) continue;
task = startTaskIfNeeded(currentIndex + offset, bit);
if (task != null) break;
}

// 2. 释放任务和内存  
for (ImageEntry entry : mImageCache.values()) {  
    if (entry.screenNailTask != null && entry.screenNailTask != task) {  
        entry.screenNailTask.cancel();  
        entry.screenNailTask = null;  
        entry.requestedScreenNail = MediaObject.INVALID_DATA_VERSION;  
    }  
    if (entry.fullImageTask != null && entry.fullImageTask != task) {  
        entry.fullImageTask.cancel();  
        entry.fullImageTask = null;  
        entry.requestedFullImage = MediaObject.INVALID_DATA_VERSION;  
    }  
}

接下来，重点分析startTaskIfNeeded()，看它是如何对一张图片做解析的。还是先看下面代码： [java] view plaincopy在CODE上查看代码片派生到我的代码片 private Future<?> startTaskIfNeeded(int index, int which) {
if (index < mActiveStart || index >= mActiveEnd) return null;

ImageEntry entry = mImageCache.get(getPath(index));  
if (entry == null) return null;  
// 先得到当前图片，类型为LocalImage  
MediaItem item = mData[index % DATA_CACHE_SIZE];  
Utils.assertTrue(item != null);  
long version = item.getDataVersion();  

// 第一次代码执行暂时screenNailTask和fullImageTask为null  
if (which == BIT_SCREEN_NAIL && entry.screenNailTask != null  
        && entry.requestedScreenNail == version) {  
    return entry.screenNailTask;  
} else if (which == BIT_FULL_IMAGE && entry.fullImageTask != null  
        && entry.requestedFullImage == version) {  
    return entry.fullImageTask;  
}  
// 匹配到格式后，先创建ScreenNailJob、ScreenNailListener并返回screenNailTask  
if (which == BIT_SCREEN_NAIL && entry.requestedScreenNail != version) {  
    entry.requestedScreenNail = version;  
    entry.screenNailTask = mThreadPool.submit(  
            new ScreenNailJob(item),  
            new ScreenNailListener(item));  
    // request screen nail  
    return entry.screenNailTask;  
}

配到格式后，先创建FullImageJob、FullImageListener并返回fullImageTask
if (which == BIT_FULL_IMAGE && entry.requestedFullImage != version
&& (item.getSupportedOperations()
& MediaItem.SUPPORT_FULL_IMAGE) != 0) {
entry.requestedFullImage = version;
entry.fullImageTask = mThreadPool.submit(
new FullImageJob(item),
new FullImageListener(item));
// request full image
return entry.fullImageTask;
}
return null;
参数which就是静态数组sImageFetchSeq中的图片类型，android原生代码默认两种BIT_SCREEN_NAIL和BIT_FULL_IMAGE。当然我们也可以自己加入一种解析图片的格式，例如BIT_GIF_IMAGE。在详细分析下面的代码后，详细你自己加入一种图片格式应该问题不大。流程大致如下： 1） 从传入参数index获取当前图片MediaItem，图片为LocalImage类型。第一次执行时screenNailTask和fullImageTask为null，匹配到格式后，创建ScreenNailJob、ScreenNailListener（或者screenNailTask和fullImageTask为null），并最终返回screenNailTask或者fullImageTask。 2） 以FullImage为例。ThreadPool的机制这里再大致讲述一下。看下mThreadPool.submit的代码： [java] view plaincopy在CODE上查看代码片派生到我的代码片 public Future submit(Job job, FutureListener listener) {
Worker w = new Worker(job, listener);
mExecutor.execute(w);
return w;
}
由前文分析，execute会启动Worker的线程进入run()函数： [java] view plaincopy在CODE上查看代码片派生到我的代码片 @Override
public void run() {
T result = null;

 // A job is in CPU mode by default. setMode returns false  
 // if the job is cancelled.  
 if (setMode(MODE_CPU)) {  
     try {  
         // 1、执行job的run()  
         result = mJob.run(this);  
     } catch (Throwable ex) {  
         Log.w(TAG, "Exception in running a job", ex);  
     }  
 }  

 synchronized(this) {  
     setMode(MODE_NONE);  
     mResult = result;  
     mIsDone = true;  
     notifyAll();  
 }  
 // 2、执行完毕，调用listener的onFutureDone  
 if (mListener != null) mListener.onFutureDone(this);

}
这里面分两步： 2.1）执行job的run()。这里会调用传入参数new FullImageJob (item).run()。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 private class FullImageJob implements Job {
private MediaItem mItem;

public FullImageJob(MediaItem item) {  
    mItem = item;  
}  

@Override  
public BitmapRegionDecoder run(JobContext jc) {  
    if (isTemporaryItem(mItem)) {  
        return null;  
    }  
    return mItem.requestLargeImage().run(jc);  
}

}
这段代码实际就是在线程池的某个线程中执行LocalImage的requestLargeImage().run(jc)。而该函数会创建一个LocalLargeImageRequest对象，而run(jc)实际就是DecodeUtils.createBitmapRegionDecoder(jc, mLocalFilePath, false)，最终创建一个BitmapRegionDecoder实例。该实例会调用JNI层的BitmapRegionDecoder中的nativeNewInstanceFromStream接口，在doBuildTileIndex(JNIEnv env, SkStream stream)里可以看到，图片会根据stream的header判断解码器是SkJPEGImageDecoder，SkPNGImageDecoder，SkBMPImageDecoder还是SkWEBPImageDecoder等，最后得到解码数据。 2.2） 调用FullImageListener的onFutureDone。此时会将2.1)中创建好的BitmapRegionDecoder实例返回传给mFuture。而FullImageListener则再发送一个MSG_RUN_OBJECT消息给MainThread，MainThread再执行FullImageListener的run()，即再执行updateFullImage(mPath, mFuture)。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 private void updateFullImage(Path path, Future future) {
ImageEntry entry = mImageCache.get(path);
……
entry.fullImageTask = null;
entry.fullImage = future.get();
if (entry.fullImage != null) {
if (path == getPath(mCurrentIndex)) {
updateTileProvider(entry);
mPhotoView.notifyImageChange(0);
}
}
updateImageRequests();
}
其中mPhotoView.notifyImageChange(0)取到当前图片后并reload，其中mPictures当前为FullPicture。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 public void notifyImageChange(int index) {
……
mPictures.get(index).reload();
……
invalidate();
那么再看看FullPicture的reload(), 该函数会对mTileView的screenNail做更新。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 @Override
public void reload() {
// mImageWidth and mImageHeight will get updated
mTileView.notifyModelInvalidated();
……
setScreenNail(mModel.getScreenNail(0));
……
}
代码段中的mModel就是PhotoDataAdapter。mModel.getScreenNail(0)得到当前图片的ScreenNail以做更新。由此可知，我们看到的全屏的图片，就是TileImageView类型的。 欢迎转载和技术交流，转载请帮忙注明出处，http://blog.csdn.net/discovery_by_joseph%EF%BC%8C%E8%B0%A2%E8%B0%A2%EF%BC%81

Android平台Gallery2应用分析(一)—背景知识

Android平台Gallery2应用分析(一)—背景知识 分类： Android多媒体 2013-12-23 09:51 1631人阅读 评论(4) 收藏 举报 Android多媒体系统应用线程池Gallery2 Android系统概括来讲可分为GUI、多媒体以及网络相关三个部分，在学习了GUI部分如何去编写应用外，多媒体系统是接下来重点分析掌握的重点。本文着重介绍Android中的Gallery2应用以及该应用的框架设计。 概要：本文先对Gallery2中涉及的线程池ThreadPool，OpenGL ES的背景知识略作讲解。再以Gallery2应用从Launcher点击到查看图片的操作过程为线索， 将依次分析AlbumSetPage、AlbumPage、PhotoPage、PhotoView以及PhotoPage上的触屏操作代码流程。 背景知识 1.1 EGL介绍 EGL是OpenGL ES和底层Native平台视窗系统之间的接口。EGL是为OpenGL ES提供平台独立性而设计的。OpenGL ES本质上是一个图形渲染管线的状态机，而EGL则是用于监控这些状态以及维护FrameBuffer和其他渲染Surface的外部层。 EGL的数据类型： EGL Boolean ：EGL_TRUE = 1， EGL_FALSE = 0 EGL int : int 数据类型 EGLDisplay : 系统显示ID或句柄 EGLConfig : Surface的EGL配置 EGLSurface : 系统窗口或framebuffer句柄 EGLContext : OpenGL ES图形上下文 NativeDisplayType : Native系统显示类型 NativeWindowType : Native系统窗口缓存类型 NativePixmapType : Native系统framebuffer

OpenGL ES的初始化过程：

     Surface实际上是一个FrameBuffer， 通过EGLSurface eglCreateWindowSurface(…)创建一个可显示的Surface。系统通常支持另两种Surface：PixmapSurface和PBufferSurface。这两种都不是可显示的Surface。

PixmapSurface：系统内存中的位图 PBufferSurface：保存在显存中的帧 应用程序通过OpenGL API进行绘制，一帧完成后，调用eglSwapBuffers来显示。

1.2 GLSurfaceView GLSurfaceView是一个视图，继承至SurfaceView，它内嵌的surface专门负责OpenGL渲染。GLSurfaceView提供了下列特性： 1> 管理一个surface，这个surface就是一块特殊的内存，能直接排版到android的视图view上。 2> 管理一个EGL display，它能让opengl把内容渲染到上述的surface上。 3> 用户自定义渲染器(render)。 4> 让渲染器在独立的线程里运作，和UI线程分离。 5> 支持按需渲染(on-demand)和连续渲染(continuous)。 6> 一些可选工具，如调试。 使用GLSurfaceView 通常会继承GLSurfaceView，并重载一些和用户输入事件有关的方法。如果你不需要重载事件方法，GLSurfaceView也可以直接使用，你可以使用set方法来为该类提供自定义的行为。例如，GLSurfaceView的渲染被委托给渲染器在独立的渲染线程里进行，这一点和普通视图不一 样，setRenderer(Renderer)设置渲染器。 初始化GLSurfaceView 初始化过程其实仅需要你使用setRenderer(Renderer)设置一个渲染器(render)。当然，你也可以修改GLSurfaceView一些默认配置。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 * setDebugFlags(int)
* setEGLConfigChooser(boolean)
* setEGLConfigChooser(EGLConfigChooser)
* setEGLConfigChooser(int, int, int, int, int, int)
* setGLWrapper(GLWrapper)

getHolder().setFormat()的参数需要与setEGLConfigChooser的参数相匹配，否则就会失败。如果想设置surface背景为透明，代码参考如下： surfaceView.setZOrderOnTop(true); surfaceView.setEGLConfigChooser(8, 8, 8, 8, 16, 0); surfaceView.getHolder().setFormat(PixelFormat.TRANSLUCENT);

定制android.view.Surface GLSurfaceView默认会创建像素格式为PixelFormat.RGB_565的surface。如果需要透明效果，调用 getHolder().setFormat(PixelFormat.TRANSLUCENT)。透明(TRANSLUCENT)的surface的像 素格式都是32位，每个色彩单元都是8位深度，像素格式是设备相关的，这意味着它可能是ARGB、RGBA或其它。 选择EGL配置 Android设备往往支持多种EGL配置，可以使用不同数目的通道(channel)，也可以指定每个通道具有不同数目的位(bits)深度。因此，在 渲染器工作之前就应该指定EGL的配置。GLSurfaceView默认EGL配置的像素格式为RGB_656，16位的深度缓存(depth buffer)，默认不开启遮罩缓存(stencil buffer)。 如果你要选择不同的EGL配置，请使用setEGLConfigChooser方法中的一种。 调试行为 你可以调用调试方法setDebugFlags(int)或setGLWrapper(GLSurfaceView.GLWrapper)来自定义 GLSurfaceView一些行为。在setRenderer方法之前或之后都可以调用调试方法，不过最好是在之前调用，这样它们能立即生效。 设置渲染器 总之，你必须调用setRenderer(GLSurfaceView.Renderer)来注册一个GLSurfaceView.Renderer渲染器。渲染器负责真正的GL渲染工作。 渲染模式 渲染器设定之后，你可以使用setRenderMode(int)指定渲染模式是按需(on demand)还是连续(continuous)。默认是连续渲染。 Activity生命周期 Activity窗口暂停(pause)或恢复(resume)时，GLSurfaceView都会收到通知，此时它的onPause方法和 onResume方法应该被调用。这样做是为了让GLSurfaceView暂停或恢复它的渲染线程，以便它及时释放或重建OpenGL的资源。 事件处理 为了处理事件，一般都是继承GLSurfaceView类并重载它的事件方法。但是由于GLSurfaceView是多线程操作，所以需要一些特殊的处 理。由于渲染器在独立的渲染线程里，你应该使用Java的跨线程机制跟渲染器通讯。queueEvent(Runnable)方法就是一种相对简单的操 作，例如下面的例子。 [java] view plaincopy在CODE上查看代码片派生到我的代码片 class MyGLSurfaceView extends GLSurfaceView {

private MyRenderer mMyRenderer;

public void start() {
mMyRenderer = …;
setRenderer(mMyRenderer);
}

public boolean onKeyDown(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
queueEvent(new Runnable() {
// 这个方法会在渲染线程里被调用
public void run() {
mMyRenderer.handleDpadCenter();
}});
return true;
}
return super.onKeyDown(keyCode, event);
}
}
(注：如果在UI线程里调用渲染器的方法，很容易收到“call to OpenGL ES API with no current context”的警告，典型的误区就是在键盘或鼠标事件方法里直接调用opengl es的API，因为UI事件和渲染绘制在不同的线程里。更甚者，这种情况下调用glDeleteBuffers这种释放资源的方法，可能引起程序的崩溃， 因为UI线程想释放它，渲染线程却要使用它。)

欢迎转载和技术交流，转载请帮忙注明出处，http://blog.csdn.net/discovery_by_joseph%EF%BC%8C%E8%B0%A2%E8%B0%A2%EF%BC%81

Android:webview加载网页速度很慢的的究极解决方案

android:webview加载网页速度很慢的的究极解决方案 此博文包含图片 (2012-06-03 09:49:02)转载▼ 标签： 杂谈 分类： android编程 【转载请注明来源自http://hi.baidu.com/goldchocobo/%E3%80%91 Android客户端中混搭HTML页面，会出现虽然HTML内容载入完成，标题也正常显示，但是整个网页需要等到近5秒（甚至更多）时间才会显示出来。研究了很久，搜遍了国外很多网站，也看过PhoneGap的代码，一直无解。 一般人堆WebView的加速，都是建议先用webView.getSettings().setBlockNetworkImage(true); 将图片下载阻塞，然后在浏览器的OnPageFinished事件中设置webView.getSettings().setBlockNetworkImage(false); 通过图片的延迟载入，让网页能更快地显示。 但是，通过实际的日志发现，Android的OnPageFinished事件会在Javascript脚本执行完成之后才会触发。如果在页面中使用JQuery，会在处理完DOM对象，执行完$(document).ready(function() {});事件自会后才会渲染并显示页面。如下图 android:webview加载网页速度很慢的的究极解决方案 可以看到在载入完最后一个JS脚本之后，对DOM元素的渲染和处理就花了8秒，然后执行了AJAX方法载入外部页面又花了2、3秒，最后才会触发onPageFinished显示页面。再往后由于程序中设置了setBlockNetworkImage(false)，所以开始载入外部图片。（如果不控制这个参数，图片载入会在渲染期间下载。 综上，由于JS脚本的处理，造成了一张页面打开多花了10秒左右时间。而同样的页面在iPhone上却是载入相当的快，显示完页面才会触发脚本的执行。（提示：如果使用JQueryMobile，更会慢得离谱） 要解决这个问题，就是想办法让浏览器延迟加载JS脚本，但是Android的WebView控件没有这样的参数。无法单独阻塞JS脚本，另外有个setBlockNetworkLoads，用了之后也无法实现类似图片的异步载入的功能，页面成了光板，连CSS也阻塞了。 就是这个问题困扰了很久，直到在做HTML照片墙时，由于setBlockNetworkImage在OnPageFinished之后才会释放，导致在JS脚本载入图片过程中无法获取图片的高宽信息，最后巧妙地通过$(document).ready(function() {setTimeout(func,10)});，成功将函数在onPageFinished之后运行。那么延伸来想，是否可以将JS脚本也用同样的方式延迟载入呢？ 答案是肯定的，在http://wonko.com/post/painless_javascript_lazy_loading_with_lazyload%E5%8F%AF%E4%BB%A5%E6%89%BE%E5%88%B0JS%E8%84%9A%E6%9C%AC%E5%BB%B6%E8%BF%9F%E5%8A%A0%E8%BD%BD%E7%9A%84%E7%AC%AC%E4%B8%89%E6%96%B9%E7%BB%84%E4%BB%B6%E3%80%82 我改造了之前速度奇慢的界面，我所使用的核心JS代码如下：

    <script src="/css/j/lazyload-min.js" type="text/javascript"></script>
    <script type="text/javascript" charset="utf-8"> 
   loadComplete(){
      //instead of document.read()
   }
    function loadscript()
    {

LazyLoad.loadOnce([ ‘/css/j/jquery-1.6.2.min.js’, ‘/css/j/flow/jquery.flow.1.1.min.js’,
‘/css/j/min.js?v=2011100852’ ], loadComplete); } setTimeout(loadscript,10); 

    就是混搭setTimeout和layzload，让JS脚本可以真正在onPageFinish之后执行。
    最终执行的效果如图：

android:webview加载网页速度很慢的的究极解决方案 可以看到非常显著的改善，从onPageStarted到onPageFinished只用了2秒不到的时间，这个时间主要花在HTML和CSS渲染上。从界面上来看，就是一闪而过的网页载入进度条，立即显示CSS渲染过的页面效果，然后再载入并执行JS脚本，逐块显示需要通过AJAX获取的数据。 综上，解决Android载入WebView页面慢的问题，不是Android程序员的事情，而是Web前端工程师的问题。如果您使用基于WebView的Android第三方壳工具（例如PhoneGap，可以通过这种方式改善UI界面的响应时间）。 发布这个解决方案，希望基于Web的客户端解决方案能更上一层楼，让HTML和原生APP混搭或的纯WEBAPP实现效果可以更理想，功德无量……

转自: http://blog.sina.com.cn/s/blog_8ad7a176010132ew.html

转:webrtc学习笔记

WebRTC学习笔记 (2013-04-12 15:49:42)转载▼ 标签： webrtc html5 chrome android it 分类： 嵌入式软件技术 1. WebRTC学习 1.1 WebRTC现状 本人最早接触WebRTC是在2011年底，那时Google已经在Android源码中加入了webrtc源码，放在/external/webrtc/，但是Android并没有用到它，更没有被浏览器使用。当时试图在Android 2.3（Gingerbread）高通平台的手机上用H.264 硬件codec替换掉WebRTC缺省使用的VP8软codec，费了不少劲勉强换掉后效果很差只得放弃。

最近得知Google最新版的Chrome for Android已经支持WebRTC，应老板的要求搭一个手机浏览器上视频通信的demo，为此在网上搜集各种资料，发现经过一年多的发展，国内外研究和使用WebRTC的人明显多起来，可用的demo也很多。在此做一个笔记，留作日后参考。

目前基于WebRTC的开发其实有两个方向，一个是基于浏览器的WebRTC应用开发，编程语言主要是JavaScript、HTML等，这也是WebRTC作为HTML5标准的组成部分原本的目的；另一个是C层面的移植和开发，作为一款非常强大的开源软件，很多领域的软件项目都可以利用到WebRTC的音视频通信和处理能力，这些场合的应用程序可能是C语言写的，也不一定与浏览器有关。本文是属于前一种方向。

1.2 WebRTC基本概念学习 WebRTC的官方资料可以从其官网http://www.webrtc.org/%E5%92%8CW 3C网站http://www.w3.org/TR/webrtc/%E4%B8%8A%E7%9C%8B%E5%88%B0%E3%80%82

学习WebRTC基础知识比较好的网站是《Getting Started with WebRTC》，网址是http://www.html5rocks.com/en/tutorials/webrtc/basics/%EF%BC%8C%E8%BF%99%E4%B8%AA%E4%B9%9F%E6%98%AF%E5%AE%98%E7%BD%91%E4%B8%8A%E6%8E%A8%E8%8D%90%E7%9A%84%E3%80%82

对浏览器来说，WebRTC其实就是提供了3个API：

MediaStream (即getUserMedia)，用于获取媒体数据，例如来自摄像头和麦克风的视频流和音频流；

RTCPeerConnection，用于peer跟peer之间呼叫和建立连接以便传输音视频数据流；

RTCDataChannel，用于peer跟peer之间传输音视频之外的一般数据。

需要注意的是这几个API的名称在不同浏览器及同一浏览器的不同版本之间略有差异，比如PeerConnection在FireFox上叫做mozRTCPeerConnection，而在当前版本的Chrome上叫做webkitRTCPeerConnection，将来WebRTC标准化完成后会把这些前缀去掉使用统一的名称。

目前网上找到的WebRTC demo都只用到了getUserMedia和RTCPeerConnection这两个API，另一个API即RTCDataChannel似乎目前还不太成熟。

WebRTC是实现peer to peer的实时通信（可以两个或多个peer之间），在能够通信前peer跟peer之间必须建立连接，这是RTCPeerConnection的任务，为此需要借助一个信令服务器（signaling server）来进行，信令包括3种类型的信息：

Session control messages: 初始化和关闭通信，及报告错误；

Network configuration: 双方的IP地址和端口号（局域网内部IP地址需转换为外部的IP地址）；

Media capabilities: 双方的浏览器支持使用何种codecs以及多高的视频分辨率。

WebRTC并未规定使用何种信令机制和消息协议，象SIP、XMPP、XHR、WebSocket这些技术都可以用作WebRTC的信令通信。

除了信令服务器，peer跟peer建立连接还需要借助另一种服务器（称为STUN server）实现NAT/Firewall穿越，因为很多peer是处于私有局域网中，使用私有IP地址，必须转换为公有IP地址才能相互之间传输数据。这其中涉及到一些专业术语包括STUN、TURN、ICE等，具体的本人还有待学习。网上找到的WebRTC demo好象都用的是Google提供的STUN server。

peer跟peer之间一旦建立连接就可以直接传输音视频数据流，并不需要借助第三方服务器中转。

  1. WebRTC封装库 WebRTC的目的是为了简化基于浏览器的实时数据通信的开发工作量，但实际应用编程还是有点复杂，尤其调用RTCPeerConnection必须对如何建立连接、交换信令的流程和细节有较深入的理解。因此有高人为我们开发了WebRTC封装库，将WebRTC的调用细节封装起来，包装成更简单的API，使开发应用程序更简单。封装库的另一个目的是为了屏蔽不同浏览器之间的差异，例如上面说的API名称的差异。当然，这些库都是开源的，可以根据自己的需要重新修改。

目前网上找到的有两种WebRTC封装库，一个是webrtc.io，网址是https://github.com/webRTC/webRTC.io%EF%BC%8C%E4%B8%8A%E9%9D%A2%E6%9C%89%E8%AF%A6%E7%BB%86%E8%AF%B4%E6%98%8E%E5%92%8C%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95%EF%BC%8C%E6%9C%89%E5%BE%88%E5%A4%9Ademo%E4%BD%BF%E7%94%A8%E5%AE%83%EF%BC%9B%E5%8F%A6%E4%B8%80%E4%B8%AA%E6%98%AFSimpleWebRTC%EF%BC%8C%E7%BD%91%E5%9D%80%E6%98%AFhttps://github.com/HenrikJoreteg/SimpleWebRTC%EF%BC%8C%E8%B2%8C%E4%BC%BC%E6%AF%94webrtc.io%E7%94%A8%E8%B5%B7%E6%9D%A5%E6%9B%B4%E7%AE%80%E5%8D%95%E3%80%82

  1. WebRTC demo试用 网上可以找到一堆WebRTC demo，在code.google.com上也能找到不少WebRTC应用项目的源码。有些demo是直接调用WebRTC API开发的，但大多数是调用上述两种WebRTC封装库开发的。由于WebRTC API的名称在不同浏览器及同一浏览器的不同版本之间存在差异，所以不是所有demo都能运行在所有浏览器上。

为了找到一个可在公司局域网环境中跑在手机上的WebRTC demo，本人试用了不少demo，下面选几个有代表性的介绍，其中有两个经修改后已在本人公司的局域网环境中运行成功。

先说一下本人的测试环境：手机上的浏览器是Chrome for Android 26.0.1410.49，运行在Android 4.1.2上，这个Chrome版本本身是beta版，支持WebRTC但缺省是关闭WebRTC功能的，需要在chrome://flags中使能WebRTC并重启Chrome，或者在启动Chrome时增加命令行选项–enable-webrtc。本人在PC上运行WebRTC的浏览器是Chrome 26.0.1410.43，操作系统是Windows 7。

3.1 http://www.webrtc.org/demo%EF%BC%88https://apprtc.appspot.com/%EF%BC%89 这是官方的demo，功能很全，可惜不知为何https://apprtc.appspot.com/%E8%BF%99%E4%B8%AA%E7%BD%91%E5%9D%80%E5%B7%B2%E7%BB%8F%E8%BF%9E%E4%B8%8D%E4%B8%8A%E4%BA%86%EF%BC%8C%E4%B8%8D%E8%BF%87%E5%85%B6%E6%BA%90%E7%A0%81%E8%BF%98%E6%98%AF%E5%8F%AF%E4%BB%A5%E4%B8%8B%E8%BD%BD%E5%88%B0%E7%9A%84%EF%BC%8C%E5%9C%A8https://code.google.com/p/webrtc-samples/%E3%80%82%E6%AD%A4demo%E6%B2%A1%E6%9C%89%E7%94%A8%E4%BB%BB%E4%BD%95%E5%B0%81%E8%A3%85%E5%BA%93%E3%80%82

这个demo所使用的信令机制使用了XHR和Google App Engine Channel API ，具体我不懂。

在我的公司局域网环境里无法运行该demo。

3.2 爱立信实验室开发的WebRTC demo 据说是第一个基于浏览器的WebRTC视频通信demo，爱立信为此还开发了一个浏览器用于支持WebRTC，好象也是基于WebKit的，叫做Bowser browser（当时市场上可能还没有支持WebRTC的浏览器），该项目网址是https://labs.ericsson.com/apps/bowser%E3%80%82%E8%BF%99%E4%B8%AABowser browser好象只支持Ubuntu 11.04 and 11.10（见https://labs.ericsson.com/apis/web-real-time-communication/downloads%EF%BC%89%E3%80%82

该demo的网址是http://webrtc.labs.ericsson.net:8082%E3%80%82

在我的公司局域网环境里无法运行该demo。

3.3 人脸检测识别 利用WebRTC的getUserMedia从摄像头获取图像进行人脸识别的demo，例如这两个：

http://neave.com/webcam/html5/face/ http://www.raymondcamden.com/demos/2012/mar/29/test1.html

这两个demo在PC和手机上的Chrome上都可运行。

3.4 http://www.simpl.info 这个demo演示HTML, CSS and JavaScript的各种feature和使用方法，包括WebRTC的3个API：getUserMedia、RTCPeerConnection、RTCDataChannel的演示，但遗憾的是RTCPeerConnection的演示只是本地camera的画面传回给本地，并没有实现真正的设备之间音视频通信。

该项目的源码在https://github.com/samdutton/simpl%E3%80%82

3.5 Framegrabber 这是一个基于WebRTC实现屏幕共享（screensharing）的Chrome扩展，源码在https://github.com/samdutton/rtcshare%EF%BC%8C%E6%9C%89%E5%85%B3%E4%BB%8B%E7%BB%8D%E5%8F%AF%E5%8F%82%E8%80%83%E8%BF%99%E7%AF%87%E6%96%87%E7%AB%A0%EF%BC%9Ahttp://blog.sina.com.cn/s/blog_51396f890102es7k.html%E3%80%82

本人没有试用过。

3.6 http://webrtc.dennis.is 这个demo是基于库webrtc.io实现的，是webrtc.io官方的demo，使用WebSocket作为信令手段。

在我的公司局域网环境里无法运行该demo；在家里无线路由器环境下可成功运行，但只能单向传输视频。

3.7 http://v.kainy.cn 国内牛人做的，相当于是汉化版的http://webrtc.dennis.is%EF%BC%8C%E8%87%AA%E7%84%B6%E4%B9%9F%E6%98%AF%E5%9F%BA%E4%BA%8Ewebrtc.io%E5%AE%9E%E7%8E%B0%E7%9A%84%EF%BC%8C%E4%BD%86%E4%BD%BF%E7%94%A8%E7%9A%84webrtc.io%E7%89%88%E6%9C%AC%E8%BE%83%E8%80%81%EF%BC%8C%E4%B8%8D%E6%94%AF%E6%8C%81%E6%96%B0%E7%89%88%E6%9C%ACChrome%E6%89%80%E4%BD%BF%E7%94%A8%E7%9A%84API%E5%90%8D%E7%A7%B0webkitRTCPeerConnection%EF%BC%8C%E6%89%80%E4%BB%A5%E6%97%A0%E6%B3%95%E5%9C%A8%E6%96%B0%E7%89%88%E6%9C%ACChrome%E4%B8%8A%E8%BF%90%E8%A1%8C%E3%80%82%E5%85%B7%E4%BD%93%E4%BB%8B%E7%BB%8D%E5%9C%A8http://blog.kainy.cn/2013/01/webrtc%E5%AE%9E%E7%8E%B0%E7%9A%84%E8%A7%86%E9%A2%91%E8%81%8A%E5%A4%A9%E5%AE%A4%E5%BA%94%E7%94%A8/%E3%80%82

3.8 http://conversat.io 这个demo是基于库SimpleWebRTC实现的，是SimpleWebRTC官方的demo，使用WebSocket作为信令手段。

在我的公司局域网环境里无法运行该demo；在家里无线路由器环境下可成功运行，且可双向传视频，支持多个peer同时视频通信。

经修改后在本人公司局域网成功运行，试过两个手机和一个笔记本电脑同时视频通信OK。修改和运行步骤：

  1. 从http://www.nodejs.org/download/%E4%B8%8B%E8%BD%BDnodejs%E6%9C%80%E6%96%B0%E7%89%88%E5%B9%B6%E5%AE%89%E8%A3%85%EF%BC%8C%E6%88%91%E6%98%AF%E5%9C%A8Windows7 64位上安装的；

  2. 在命令行下依次运行如下命令（安装运行signaling server所需的模块）：

npm install express npm install yetify npm install getconfig npm install node-uuid npm install socket.io

  1. 从https://github.com/andyet/signalmaster%E4%B8%8B%E8%BD%BD%E4%BF%A1%E4%BB%A4%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%BA%90%E7%A0%81%EF%BC%8C%E8%AF%A5%E4%BF%A1%E4%BB%A4%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%98%AFSimpleWebRTC%E7%BC%BA%E7%9C%81%E4%BD%BF%E7%94%A8%E7%9A%84%EF%BC%8C%E8%A7%A3%E5%BC%80%E8%AF%A5%E6%BA%90%E7%A0%81%E5%90%8E%E8%BF%90%E8%A1%8Cnode server.js，该服务器监听8888端口，通过WebSocket与浏览器通信。

  2. 在同一台PC上运行apache server，将从http://conversat.io%E7%BD%91%E7%AB%99%E6%89%92%E4%B8%8B%E6%9D%A5%E7%9A%84%E6%96%87%E4%BB%B6%E6%94%BE%E5%88%B0%E8%AF%A5server%E4%B8%8A%EF%BC%88%E5%8F%AF%E5%9C%A8Chrome%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%AD%E6%89%93%E5%BC%80http://conversat.io%E7%84%B6%E5%90%8E%E9%BC%A0%E6%A0%87%E5%8F%B3%E9%94%AE%E5%8D%95%E5%87%BB%E5%9C%A8%E8%8F%9C%E5%8D%95%E4%B8%AD%E9%80%89%E2%80%9C%E5%8F%A6%E5%AD%98%E4%B8%BA%E2%80%9D%E3%80%81%E2%80%9C%E7%BD%91%E9%A1%B5%EF%BC%8C%E5%85%A8%E9%83%A8%E2%80%9D%E5%8D%B3%E5%8F%AF%EF%BC%89%EF%BC%8C%E4%BF%AE%E6%94%B9%E5%85%B6%E4%B8%AD%E7%9A%84 index.html 和 simplewebrtc.js，将其中 url 改为 ‘http://10.100.156.83:8888‘（其中IP地址是我的PC在公司局域网中的IP地址）。

  3. 在同一局域网中的其他设备上打开Chrome浏览器，地址栏输入http://10.100.156.83%EF%BC%8C%E8%BE%93%E5%85%A5%E7%9B%B8%E5%90%8C%E7%9A%84room%E5%90%8D%E7%A7%B0%EF%BC%88%E9%9A%8F%E4%BE%BF%E8%B5%B7%EF%BC%89%E5%8D%B3%E5%8F%AF%E5%BC%80%E5%A7%8B%E5%A4%9A%E6%96%B9%E8%A7%86%E9%A2%91%E9%80%9A%E4%BF%A1%EF%BC%8C%E4%B9%9F%E5%8F%AF%E4%BF%AE%E6%94%B9%E4%B8%8A%E8%BF%B0index.html%E4%B8%AD%E7%9A%84%E2%80%9Cvar room”一行，设定为固定的room名称，就不需要每次在每个设备上手工输入room名称了。

3.9 国内牛人开发的视频聊天室应用 这个demo是国内牛人赵书剑开发的视频聊天室，基于webrtc.io实现。

该项目源码和文档下载地址是http://ishare.iask.sina.com.cn/f/35083616.html%EF%BC%8C%E6%BA%90%E7%A0%81%E5%9C%A8https://github.com/zsj2145676%E3%80%82

经修改后在本人公司局域网成功运行，试过两个手机和一个笔记本电脑同时视频通信OK。修改和运行步骤：

  1. 从http://ishare.iask.sina.com.cn/f/35083616.html%E4%B8%8B%E8%BD%BDwebrtc.chatdemo.zip%EF%BC%8C%E8%A7%A3%E5%8E%8B%E7%BC%A9%EF%BC%8C%E4%BF%AE%E6%94%B9%E5%85%B6%E4%B8%ADpublic\javascripts\client.js%E4%B8%AD%E7%9A%84rtc.connect%E4%B8%80%E8%A1%8C%EF%BC%8C%E5%B0%86%E5%AE%9E%E9%99%85%E7%9A%84%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%9C%B0%E5%9D%80%E5%86%99%E8%BF%9B%E5%8E%BB%EF%BC%8C%E4%BE%8B%E5%A6%82%E6%94%B9%E4%B8%BA%EF%BC%9Artc.connect(“ws://10.100.156.83:8001”, room);

  2. 同上文3.8节步骤1、2安装nodejs

  3. 运行node app.js，注意该demo本身已包含http server，不需要其他的比如apache server

  4. 在同一局域网中的其他设备上打开Chrome浏览器，地址栏输入http://10.100.156.83:8000%EF%BC%8C%E8%BE%93%E5%85%A5%E7%9B%B8%E5%90%8C%E7%9A%84room%E5%90%8D%E7%A7%B0%EF%BC%88%E9%9A%8F%E4%BE%BF%E8%B5%B7%EF%BC%89%E5%8D%B3%E5%8F%AF%E5%BC%80%E5%A7%8B%E5%A4%9A%E6%96%B9%E8%A7%86%E9%A2%91%E9%80%9A%E4%BF%A1%E3%80%82

转自：http://blog.sina.com.cn/s/blog_69a04cf401016gz4.html

转:Android WebRTC 音视频开发总结（三）

Android WebRTC 音视频开发总结（三）

前面介绍了WebRTC的基本结构，本节主要介绍WebRTC音视频的实现，通过前面的例子我们知道运行WebRTCDemo即可看到P2P的效果，实际应用中我们不可能让用户自己去里面设置对方的IP和音视频端口，而且即使设置了对方的IP和端口也不一定能运行起来，因为P2P的双方如果不在同一个网段下还需穿透NAT，即打洞，下面介绍两种达到实用效果的方法，转载请说明出处（博客园RTC.Blacker）：

1、增加中转服务器：增加一台公网服务器，客户端先将RTP包发给公网服务器，然后再通过服务器转发给对方，这就不存在打洞的问题了，实际上很多视频会议都是这么实现的,在多人视频通讯的情况下如果都通过P2P来实现则会给客户端带来很大的压力,特别是手机端负载有限的情况下,这个方法的弊端尤为明显,但如果通过RelayServer,客户端压力可大大减轻。

2、搭建STUN服务器：打洞的原理理解了其实很简单，主要思路就是通过STUN服务器获取自己的ip,port及NAT信息，然后通过信令服务器交换这些信息,最后两客户端根据各自得到的ip,port,NAT信息进行相应的穿透，现在开源STUN代码很多，网上也有很多介绍这方面的问题，有兴趣的可以找相关资料看看.

补充:不过对NAT进步一研究你会发现内网下多重NAT穿透是个比较麻烦的事情，网上有一些专门研究多层NAT穿透的论文,有兴趣的可以去了解,正因为STUN方式不能完全解决P2P问题,所以后面出现了ICE,而libjingle就是ICE思想的具体实现,有兴趣请看后面的相关文章。

实际应用中可能得考虑上面两种方法结合使用，原因如下：

1、P2P方式性能明显优于服务器中转，毕竟手机上受到带宽和硬件性能的限制，效果肯定没有PC好，所以P2P方式更适合用户。

2、在打洞不成功的情况下必须使用中转模式。

WEBRTC里面其实已经提供了上面两种解决方案，所以使用AppRTCDemo进行一对一视频的时候，他会分别连接STUN和TURN，前者用来处理打洞，后者用来转发（对应TurnServer和RelayServer），两者相结合就是ICE了，有兴趣的可以看我后面介绍ICE的文章。

转自：http://www.cnblogs.com/lingyunhu/p/3621057.html

Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 中文版(六.增强传输可靠性)

21 5月 13 Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 中文版(六.增强传输可靠性） 原文：http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-06#section-6

  1. WebRTC如何使用RTP：提供传输可靠性

有许多工具可以防止包丢失来提高RTP流的可靠性并减少对媒体质量的影响。但是，对比

无可靠性(no-robust)流，他们都要添加额外的bit到包中。这些额外的bit需要认真考虑下，

而且合计的bit率必须可控。这样，提高可靠性可能需要使用一个比较低的编码质量，但是在

这样的质量可以换来更少的错误。在下面的几节中描述的机制可以用来增强对保丢失的忍耐

性。

6.1. 负面确认和RTP重传(Negative Acknowledgements and RTP Retransmission)

作为支持RTP/SAVPF profile的结果，WebRTC实现将会为RTP数据包[RFC4585]支持负面 确认NACK消息(negative acknowledgements)。这个反馈根据RTCP反馈通道的能力限制， 可以用来通知发送者特定的RTP包丢失。比如，一个发送者可以用这个信息调整媒体编码补偿从而 优化用户体验。 发送者必须理解一般的在Section 6.2.1 of [RFC4585]定义的NACK消息，但是可以选择 忽略这个反馈 (根据 Section 4.2 of [RFC4585]).接收者可以为丢失的RTP包发送NACKs; [RFC4585]提供了一些关于何时发送NACKs的指导。不能期望一个接受者会为每个丢失的RTP包 发送NACK消息，它需要考虑发送NACK反馈的成本，以及丢失包的重要性，从而决定是否值得告诉 发送者有包丢失了。 Perkins, et al. Expires August 29, 2013 [Page 15]

Internet-Draft RTP for WebRTC February 2013 RTP重发Payload格式 [RFC4588]提供了根据NACK反馈重复丢失包的能力。重发需要小心的在 实时交互应用程序中使用使用，来保证 重发的包按时到达且有用，但是能在相对低的RTT网络 环境下有效（一个RTP发送者可以使用RTCP SR和RR包中的信息估计到接受者的RTT)。重传的 使用也可以提高前转(forward)RTP带宽，如果丢包是因为网络拥堵造成的，也可能使问题恶化。 我们仍然要注明，重传一个重要的丢包来修复解码状态比重发一个完整的帧内帧(intraframe) 可以降低损耗。接收到NACK消息就轻率的重复RTP包并不合适。在重复之前需要丢失包的重要性 以及它们按时到达的可能性。 接受者必须实现RTP重传[RFC4588]。如果RTP重发payload格式已经在会话中协商过，而且 如果发送者根据NACK相信重发包是有用的，发送者可以发送RTP重传包。不能期望发送者会 重复每个回复了NACK的包。

6.2. 转发错误修正Forward Error Correction (FEC)

转发错误修正(FEC)的使用可以对一定程度上的包丢失提供保护，同时会消耗一定的带宽。

有很多FEC方案供RTP使用。有些方案是给特定RTP payload格式使用的，而其它的对RTP包的 操作可以用在任意payload 格式上。需要注意的是使用冗余的编码或者FEC会导致延时增加， 在选择冗余或者FEC格式以及它们对应的参数时需要考虑这一点。

如果在WebRTC会话中作为标准特性来使用的RTP payload格式 支持冗余传送或者FEC， 那么根据任何合适的信号，这个支持就可以用在WebRTC会话中。

有许多基于块(block-based)FEC方案，是设计成与RTP payload格式无关的。在写这 个文档时，在WebRTC上下文中使用这些FEC方案中的哪一个还没有共识。因此，这个备忘录 无法推荐基于块（block-based)FEC供WebRTC使用。 Perkins, et al. Expires August 29, 2013 [Page 16]

Internet-Draft RTP for WebRTC February 2013 原创文章，转载请注明： 转载自讨论关于webrtc html5 extjs nodejs等技术和产品

本文链接地址: Web Real-Time Communication (WebRTC): Media Transport and Use of RTP 中文版(六.增强传输可靠性）

WEBRTC书籍

转: 研究音频编解码要看什么书

前言。。。。。。

最近总是有人问研究音频编解码要看什么书

其实这是一个很难回答的问题，原因有很多。

首先，做工程首先一个问题就是和课本学习不同，不是看书能解决的。

其次，音频编解码技术在国内研究的人很少包括总体的音频技术国内相对国外都研究的不多。（从中国的潜艇噪声技术一直解决不好就能看出一二）。

第三，音频编解码技术是一种应用，而一般的书籍都是理论基础。

只看理论书籍和应用脱离太多，没有实用会忘记。

我当初看书也是从工程入手，就是在实际工作中和个人兴趣中看了大量的标准，然后对不懂的地方找论文，再找书籍补知识。可以说这是典型的逆向学习。

通常研究生是课本->看论文->做工程。

但是我还是总结 一下关于如何看书的问题，希望对入门者有帮助

概述。。。。。

首先，音频编解码技术是一种比较复杂的应用，而普通的书籍是一种理论书籍尤其是在中国。一会解释这句话。

其次，音频编解码技术和一般的音频技术不同，比如AEC，HRTF，后者分别是语音和音频的应用技术，应该说是一种具体的应用技术，相对来说查资料还是容易有的放矢。

分解。。。。。

其实音频编解码技术也是一种具体的应用技术，但是可能系统相对复杂，目的相对基础。它是信源编解码技术的一个分支，目的就是压缩数据。

那么音频编解码技术包括哪些方面呢？

既然他是一种信源编解码器技术（Source Coding Technology）那么信源编解码技术的书籍都可以看，做理论基础学习。

另外其实我把音频编解码技术分为5大技术，EQTPM，E，熵编码，Q，量化编码，T，变换编码，P，预测编码，M，音频建模（感知建模，BCC建模，正弦建模等）

这里包括4类书籍：

1.语音编解码书籍，因为国内讲宽带音频编解码的书籍很少，所以可以看些语音编解码的书籍，里面也有讲EQTP技术。

例如：《语音处理技术》，《语音编码》，《低码率音频编码》，《数字语音编码原理》，《变速率语音编码》《低速率语音编码》《数字语音编码》《数据压缩》

《JPEG2000 图像压缩基础》：我认为这本书讲的还是不错的,翻译的也不错，很多基本原理讲的比较透彻。

2.理论基础书籍,《信息论与编码》，《信号与系统》，高数这类我就不但列出来了，但是也要常番。

3.国外的宽音频编码书籍,例如我认为很经典的ANDREAS SPANIAS的《Audio Signal Processing and Coding 》。以及他的63页的论文，《Perceptual Coding of Digital Audio》。

其他可看的书籍包括：

MP3之父——K. Brandenburg的《Applications of Digital Signal Processing to Audio and Acoustics》

《A Digital Signal Processing Primer, with Applications to Digital Audio and Computer Music》

《Auditory Perception and the MPEG Audio Standard》

《Foundation and Evolution of Standardized Coders (Wiley,2003)(ISBN 0471373125)(578s)》

汉堡联邦国防军大学Udo Zolzer教授的《Digital Audio Signal Processing》

《High-Fidelity Multichannel Audio Coding》

《Speech Coding Algorithms》

我强烈推荐把SPANIAS的书读一下。至少把SPANIAS的那个论文仔细看一下。你会对音频编码的理解有很深的帮助。但是里面会将很多关于耳朵的生理词语，要拿着字典慢慢翻。这个论文我是烦烂了的。使我受益匪浅。

后面的书籍我还没有系统看过，但都有PDF版本，我也是偶尔翻一下。因为这些经典书籍你不花大时间理解，会造成假象是乍看起来都讲得类似，但实际理解起来发现是对不同细节的阐述。

4.其他类书籍

专门书籍，

如《自适应信号处理》，因为音频编码也好其他音频技术也好，自适应技术是经常使用的。例如无损编码的Wavpack，MPEG4 ALS，都使用了自适应技术。

滤波器设计的相关书籍。

《多抽样率数字信号处理理论及其应用》：讲解Transform技术。

HE-AAC和ATRAC3，使用的QMF，

MP3 使用的PQF

AAC，MP3使用的MDCT

AC3使用的TDAC（MDCT）

WMA和G。722.1的(MLT)

都是为什么，选择这些变换工具。有什么区别。

如果你能看看Vaidyananthan PP的书，会更有帮助。

最后。。。。。。。。。

除了这些书籍，建议大家多看看论文。

很多国外的大学都有专门的论文和PPT教学。

我把论文分3类。

1.会议论文（有的讲的很有点概况，有的有些对原理公式还是讲的比较清楚，还有一些强调系统性和介绍的）。

例如：伦敦学院的《A Survey of Packet Loss Recovery Techniques for Streaming Audio》 对PLC技术做了系统归纳

L Daudet的《A review on techniques for the extraction of transients in musical signals》对瞬态信号提取技术做了归纳。

2.毕业论文。往往讲的很详细。

这里我举2个例子，文章太多我就截屏解释吧。

3.经典PPT

例如很多大学和机构开放课程会有一些经典PPT。

例如：德国Fraunhofer的主页就有很多奖MPEG系列音频编码技术的PPT。非常好，非常推荐。

除了论文，我们还可以看一些一些常用的网址

我就给一个好了，超经典的

斯坦福大学

Julius Orion Smith III 教授的主页

https://ccrma.stanford.edu/~jos/

不说了，自己看吧，引用里面的介绍–(1GB of on-line publications, sound examples, and software )

结语。。。。。。。。

馒头要一口一口吃，耐心些，开始吧

from: http://www.cnblogs.com/gaozehua/archive/2012/04/28/2474488.html

欢迎访问 www.webrtccn.com

WEBRTC开发工具

AT&T发布WebRTC开发工具 作者 丛一 发布于 2015年1月11日 | 讨论 分享到： 微博 微信 Facebook Twitter 有道云笔记 邮件分享 稍后阅读我的阅读清单 为什么我们只能用电话打电话？尽管谷歌和苹果都为用户提供了在手机、平板电脑和便携电脑之间互通文本消息和即时消息的功能，但传统的电话呼叫还是只能受限于一个设备。现在AT&T公司正在试图利用WebRTC技术终结这种窘境，向前迈出一大步。WebRTC可以让你在智能手机上拨打电话，然后将通话转移到便携电脑的浏览器会话中，反之亦然。

AT&T在2015年AT&T开发者峰会上发布了一款增强版WebRTC技术的开发工具，无需插件就可以在浏览器之间进行音频或视频通话。并且声称他们是第一家利用AT&T的增强版WebRTC API为WebRTC提供商业化支持的美国电信运营商。尽管AT&T是第一家发布商用WebRTC API的美国运营商，WebRTC实际上是一种正逐渐被世界范围内的运营商广泛采纳的工业标准。Telefonica已经支持WebRTC有一段时间了，而其他的运营商的身影也频频出现在各种WebRTC的研讨会上，尽管目前还暂未见到有比较重要的公告发布。

AT&T的增强版WebRTC API目前已发布公开测试版本并且在WebRTC基础上做了一些功能改进。第一个改进是增强版WebRTC的通信可以扩展到固定电话和移动电话之间，而不仅是端对端的或浏览器会话间的。这对于开发者和用户来说都是相当有价值的并且因为消除了一个关键障碍，会大大刺激这种技术采用量的增长。第二个改进是利用终端用户的AT&T移动电话号码，开发者可以编程支持来自浏览器的WebRTC通信的来电显示。最后一个改进是开发者可以将从PC、MAC或平板电脑上发起的呼叫转移到智能手机上。

在开发者峰会的现场演示中，AT&T和Plantronics向参会者展示了一个工人如何利用增强版WebRTC API通过他的移动电话号码发起可视对话然后通过便携电脑完成了一次在线航班预定。然后又将预定确认信息和其他细节信息传输到其移动电话之中。

据AT&T的移动化首席营销官David Christopher在开发者峰会上介绍：“AT&T强大的增强版WebRTC API给广大开发者提供了一个重新想象以IP为中心的互联世界中的电话和视频通话体验的机会。WebRTC被分析师们看作是过去数年来最具破坏性的通讯技术之一，我们认为就其能够为企业和消费者所能带来的价值而言，标准的采用以及相关的创新发展将会有非常快速地增长。”

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

【QCon北京2015大会】把握趋势，邀请国内外顶级专家，设计涵盖大数据、云计算、移动开发、技术创业、前端和敏捷等热点领域的18个专题，IT领域的技术盛宴。了解详情。