android - 为什么我在使用 Android MediaPlayer 读取 H.264 编码的 rtsp 流时收到 "Unsupported format"错误？

Question

我正在尝试在 Android 设备上显示 H.264 编码的 rtsp 视频。流来自树莓派，使用 vlc 编码 /dev/video1这是一个“Pi NoIR 相机板”。

vlc-wrapper -vvv v4l2:///dev/video1 --v4l2-width $WIDTH --v4l2-height $HEIGHT --v4l2-fps ${FPS}.0 --v4l2-chroma h264 --no-audio --no-osd --sout "#rtp{sdp=rtsp://:8000/pi.sdp}" :demux=h264 > /tmp/vlc-wrapper.log 2>&1

我现在使用的 Android 代码非常少:

final MediaPlayer mediaPlayer = new MediaPlayer();
mediaPlayer.setDisplay(holder);
try {
  mediaPlayer.setDataSource(url);
  mediaPlayer.prepare();

并收到“准备失败。:状态 = 0x1” IOException .当我查看日志时，我看到类似的行

06-02 16:28:05.566 W/APacketSource(  316): Format:video 0 RTP/AVP 96  / MIME-Type:H264/90000
06-02 16:28:05.566 W/MyHandler(  316): Unsupported format. Ignoring track #1.
06-02 16:28:05.566 I/MyHandler(  316): SETUP(1) completed with result -1010 (Unknown error 1010)

来自系统进程。这些消息的 Grepping 指向 libstagefright/rtsp来源，似乎意味着 ASessionDescription::getDimensions调用 APacketSource::APacketSource构造函数失败。这似乎不应该发生，因为 VLC 当然知道要输出什么尺寸:

[0x1c993a8] v4l2 demux debug: trying specified size 800x600
[0x1c993a8] v4l2 demux debug: Driver requires at most 262144 bytes to store a complete image
[0x1c993a8] v4l2 demux debug: Interlacing setting: progressive
[0x1c993a8] v4l2 demux debug: added new video es h264 800x600

似乎正在发生的是 ASessionDescription::getDimensions正在寻找 framesize中的属性(看似格式良好) DESCRIBE结果

06-02 16:28:05.566 I/MyHandler(  316): DESCRIBE completed with result 0 (Success)
06-02 16:28:05.566 I/ASessionDescription(  316): v=0
06-02 16:28:05.566 I/ASessionDescription(  316): o=- 15508012299902503225 15508012299902503225 IN IP4 pimple
06-02 16:28:05.566 I/ASessionDescription(  316): s=Unnamed
06-02 16:28:05.566 I/ASessionDescription(  316): i=N/A
06-02 16:28:05.566 I/ASessionDescription(  316): c=IN IP4 0.0.0.0
06-02 16:28:05.566 I/ASessionDescription(  316): t=0 0
06-02 16:28:05.566 I/ASessionDescription(  316): a=tool:vlc 2.0.3
06-02 16:28:05.566 I/ASessionDescription(  316): a=recvonly
06-02 16:28:05.566 I/ASessionDescription(  316): a=type:broadcast
06-02 16:28:05.566 I/ASessionDescription(  316): a=charset:UTF-8
06-02 16:28:05.566 I/ASessionDescription(  316): a=control:rtsp://192.168.1.35:8000/pi.sdp
06-02 16:28:05.566 I/ASessionDescription(  316): m=video 0 RTP/AVP 96
06-02 16:28:05.566 I/ASessionDescription(  316): b=RR:0
06-02 16:28:05.566 I/ASessionDescription(  316): a=rtpmap:96 H264/90000

这看起来可能是一个 Stagefright 错误:它知道(或应该知道)它有一个 H.264 编码流，但它似乎期待一个 H.263 framesize属性。因此我的问题:

我阅读的来源正确吗？问题出在ASessionDescription::getDimensions称呼？ (stagefright 真的只支持 H.263 流媒体吗？)

或者 Pi 端代码在某种程度上是错误的？

或者我只是在客户端代码中遗漏了一两个关键步骤？

更新，20140606:
MediaPlayer文档说 -1010 是 MEDIA_ERROR_UNSUPPORTED :“比特流符合相关编码标准或文件规范，但媒体框架不支持该功能。”这让我想知道问题是否是“标准”渐进式下载问题。即， Supported Media Formats说

For video content that is streamed over HTTP or RTSP [in a] MPEG-4 [container] the moov atom must precede any mdat atoms, but must succeed the ftyp atom

而大多数流都放置了 moov原子最后。

不过，我完全不确定如何验证这一点!

我看没有moov或 ftyp vlc 源中的原子。 (我被告知 vlc 只是在这里进行流式传输；实际的 H264 内容来自相机驱动程序。)

我看没有moov或 ftyp https://github.com/raspberrypi 中的原子linux 或 userland 分支。 (不过，也许我只是在寻找错误的东西。)

当我用 vlc 保存流时，我会得到一个带有 moov 的 mp4 文件之前 mdat ，但当然 vlc 可以在这里进行一些转码。

更新，20140610:

GPAC "Osmo4" player可以在 Android 4.3 平板电脑上显示流。很糟糕(在笔记本电脑上比 VLC 更滞后，并且容易死机)但它 可以 显示它。

更新，20140616:

当我再次尝试搜索 VLC 源代码时(这次不区分大小写且没有单词方向)，我确实找到了定义 moov 的 FOURCC 宏。和 ftyp modules/mux/mp4.c 中的原子，这很快导致了 --sout-mp4-faststart (和 --no-sout-mp4-faststart )开关......没有任何区别。

因此，看起来它实际上可能不是原子排序问题。很高兴知道，如果它关闭了一整类死胡同，但它确实让我在没有任何线索的情况下将头撞在墙上(这似乎总是对我的头部造成的伤害比对墙壁造成的伤害更大)。

更新，20140702:

我为Android编译了VLC，它可以在pi上显示VLC生成的流。它将图像放在屏幕的左上角；我尝试为他们的 .so 编写自己的皮肤，但找不到任何可以让我缩放到表面或其他任何东西的“旋钮”。 (加上 .apk 大约有 1200 万!)

因此，我找到了相关的 RFC 并编写了自己的 RTSP 客户端。或者尝试:我可以解析 SDP并生成足够的有效 RTSP获取 RTP和 RTCP 数据报，我可以解析 RTP 和 RTCP header 。但即使 SDP 声称提供 m=video 0 RTP/ AVP 96 和 a=rtpmap:96 H264/90000， MediaCodec无论我传递给 MediaCodec.createByCodecName() 平板电脑上的三个 H264 编解码器中的哪一个，都不会在我的表面上显示视频，当我查看 RTP 负载时，我并不太惊讶:我没有看到 NAL sync pattern任何数据包中的任何位置。

相反，它们都以 21 9A __ 22 FF 开头。 (通常)或偶尔 3C 81 9A __ 22 FF ，其中 __ 似乎总是一个偶数，每个数据包增加 2。我不认识这种模式 - 是吗？

更新，20140711:

事实证明，H264 数据包不必以 NAL 同步模式开始 - 只有在 NAL 单元可能嵌入到更大的数据流中时才需要。我的 RTP 数据包在 RFC 6184格式。

Answer 1

经过大量的死胡同后，我可以在 Android SurfaceView 上显示 H264 RTSP 流.这个答案只是一种答案，因为我仍然无法解决我原来的三个问题，但即使充满了错误和快捷方式，我的 75K apk 还是比 Android 的 Vlc 或 osmo4 播放器好得多:它有子- 秒延迟(至少当发送方和接收方在同一个 wifi 路由器上时!)并填充 SurfaceView .

一些要点，以帮助任何尝试做类似事情的人:

您传递给 MediaCodec.queueInputBuffer() 的所有输入缓冲区必须以 00 00 01 sync pattern 开头.

您可以 configure() 和 start() 立即编解码器 - 但在您看到 SPS(NALU 代码 7)和 PPS(NALU 代码 8)数据包之前，不要将任何“正常”输入缓冲区排队。 (这些可能不是 0x67 和 0x68 - “nal_ref_idc”位应该是非零的，但不一定是 11。Fwiw，vlc 似乎总是给我 01。)

几乎正常通过 SPS/PPS 数据包 - 通过 BUFFER_FLAG_CODEC_CONFIG标志到 queueInputBuffer() .特别是，不要尝试将它们放在附加到 MediaFormat 的“csd-0”缓冲区中。 !

当您看到 (a) 丢失帧时(即您看到 RTP 序列号跳跃)不要调用 codec.flush() !只需跳过部分帧，并且在下一个完整帧之前不要排队缓冲区。