从 GStreamer 1.8.2 开始（可能更旧，但 1.8.2 或更高版本会让您的生活更轻松），这一切都可以使用 GStreamer 本身来完成。你应该忽略 ffmpeg 和 libav（同样的东西——项目有一个分裂）交叉插件。
您将需要 gstreamer、gst-plugins-base、gst-plugins-good 和 gst-plugins-bad 的源代码，仅此而已。不要使用 gst-plugins-ffmpeg、libav 等，此时所有这些建议都已过时。 （对于 h.264/h.265，您可能仍然需要它，但那又是一团糟。）您还应该获取 libvpx 的源代码，最好是 1.6.0 版。熟悉并熟悉从 automake 构建这些项目。 GStreamer 尤其具有非常干净的配置脚本；学习如何有效地使用它们。
重要的是不要混用 0.10 系列和 1.8.2 系列代码，因为 VP8 的 RFC 在此期间已获得批准（就像 Opus 一样，如果您将其用于音频，我推荐的），并且一些在 SDP 文件中使用的魔术字符串已经改变。
但是，您应该注意，仍然存在一些松散的结局。
特别是，如果您使用 SDP 文件来驱动所有这些东西，请注意使用“sdpdemux”自动生成图形仍然有一些限制。一方面，库存 sdpdemux 没有“等级”，因此不会自动处理类型“application/sdp”。您应该期望构建一个自定义应用程序来构建您的图表 - 这个过程有一些学习曲线。
您应该对插件的分支副本和调整它们持开放态度，因为这通常会增加很多灵活性而无需付出太多努力，但请注意，复制的插件需要大量更改令牌名称以避免冲突与现有插件一起使用，并且必须小心操作以确保插件仍然有效。
我建议您彻底熟悉以下 GStreamer 组件：
vp8dec
vp8enc
vp8parse（注意：见下文）
matroskamux
matroskademux
队列
rtpbin
rtpjitterbuffer
sdpdemux
udpsink
udpsrc
视频转换
...以及至少一种现代音频编解码器的匹配材料（我推荐 Opus，因此，“opusdec”和“opusenc”）。
请注意上面的“vp8parse”。这可从“kotaku”项目中获得，您可能需要也可能不需要它。如果您想在粒度级别处理 vp8 视频——在没有实际解码的情况下跳过它，等等——你可能需要它。某些类型的非线性编辑应用程序肯定需要这个。从 GST 1.8.2 开始，它尚未合并到主线 GStreamer 代码库中。
作为保持理智的一个特殊点，不要在不了解您要进入的内容的情况下通过 RTP 使用 VORBIS 进行音频流式传输。 Vorbis 和 Theora 使用“动态码本”——依赖于内容的压缩字典，这些字典随被压缩的材料而变化。这意味着解码器神奇地需要知道编码器想出什么作为码本，但是您没有文件头，因为您正在流式传输。有一些方法可以解决这个问题，但它们并不令人愉快。如果您尝试将其塞入 SDP 文件以便在远程端恢复，我建议您确定一种您可以在数量上容忍的低成本苏格兰威士忌。
还有一些其他问题需要警惕。
如果您希望在硬件加速的嵌入式系统上进行解码，请不要使用任何“花哨的”压缩设置，除非您拥有非常完整的 QA 资源供您使用。并非所有技术上有效的流都会在所有硬件加速解码器中解码。特别是，“弹性”选项非常诱人且非常有效，但会破坏 IMX6 目标的加速解码。
如果没有非常重大的妥协，VP8 编码就无法实时进行。可能需要一些时间来了解这些是什么以及它们是如何工作的。进入这个问题超出了这个问题的范围，除了当你实际上只是没有足够快地将数据发送到你的 udpsink 时你很容易认为你的发射器坏了的问题。别担心，它可以做到，但你需要做你的研究。首先查看 libvpx 的“截止日期”选项。
最后，我强烈建议您查看 RTP 中的 VP8、RTP、VP8 有效负载的 RFC，特别是 SDP 中的 RTCP（R-T-C-P，不是 RTP，不是 TCP）、SDP、VP8 流。这些特定问题中的每一个都有几个 RFC。请确保您查看的是当前版本，而不是草稿！发生了一些非常重大的变化。
当您熟悉您的规格和工具时，您会意识到我现在将为您总结的三点：
您不能使用 gst-launch 完成所有操作，但如果可以，它可以节省大量时间。
您可以使用自定义应用程序做任何事情，但学习曲线很长，开发时间也很长。
许多编写官方 RFC 的人只测试了他们所写材料的非常狭窄的用例，尤其是多媒体。
祝你好运！