当前位置：文江博客话题详情

保存 H.264 RTP 流而不重新编码？

发布于 2024-09-28 05:13:29 字数 239 浏览 8 评论 0原文

我的 C++ 应用程序接收 H.264 RTP 视频流。

现在它对流进行解码，将其保存到 YUV 文件中，稍后我使用 ffmpeg 将文件重新编码为适合在 Windows PC 上观看的内容（例如 Mpeg4 AVI）。

是否应该可以将 H.264 流保存到 AVI（或类似）容器中而无需对其进行解码和重新编码？这需要在 PC 上安装 H.264 解码器才能观看，但效率应该要高得多。

这怎么可能呢？有任何库支持吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

べ繥欢鉨o。 2024-10-05 05:13:29

使用 ffmpeg 是正确的，但到目前为止发布的答案对我来说看起来不正确。

正确的开关应该是：

-vcodec copy

using ffmpeg is correct but the answers posted so far dont look right to me.

the correct switch should be:

-vcodec copy

回复收藏 0 原文

隔纱相望 2024-10-05 05:13:29

您的程序可以通过 ffmpeg 传输 rtp 本身 - 甚至使用 < 调用它代码>popen3()。

看来您需要使用中间 SDP 文件 - 我推测您可以将创建的文件指定为命名管道或使用 tmpfile() 您的应用程序写入的内容 - 使用文件作为中介。

命令行将类似于：

int p[3];
const char* const out_fmt = "avi";
const char* cmd[] = {"ffmpeg","-f",,"-i",temp_sdp_filename,"-vcodec","copy","-f",out_fmt,"-",NULL};
if(-1 == popen3(p,cmd)) ...
// write the rtp that you receive to p[STDIN_FILENO]
// read the avi from p[STDOUT_FILENO]
// read any messages and error text from p[STDERR_FILENO]

我相信在这种情况下 ffmpeg 足够聪明，可以重新打包容器（rtp 流与 AVI），而无需对视频和音频进行转码（这是 - vcodec复制开关）；因此，您不会有任何质量损失，而且速度会非常快。

Your program could pipe the rtp itself through ffmpeg - even invoking it using popen3().

It seems that you need to use an intermediate SDP file - I speculate that you can specify a file you created as a named pipe or with tmpfile() which your application writes to - using the file as an intermediary.

The command-line would be something like:

int p[3];
const char* const out_fmt = "avi";
const char* cmd[] = {"ffmpeg","-f",,"-i",temp_sdp_filename,"-vcodec","copy","-f",out_fmt,"-",NULL};
if(-1 == popen3(p,cmd)) ...
// write the rtp that you receive to p[STDIN_FILENO]
// read the avi from p[STDOUT_FILENO]
// read any messages and error text from p[STDERR_FILENO]

I believe that in this circumstance ffmpeg is clever enough to repackage the container (rtp stream vs AVI) without transcoding the video and audio (this is the -vcodec copy switch); therefore, you'd have no loss of quality and it'd be blazingly fast.

回复收藏 0 原文

~没有更多了~