为什么我会收到“不支持的格式”错误，用安卓MediaPlayer读取H.264编码的rtsp流？

Question

我试图在Android设备上显示H.264编码的rtsp视频。流来自一个树莓Pi，使用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();

并得到一个“准备失败。：status=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)

来自一个系统进程。对这些消息的缓冲指向libstagefright/rtsp源，这似乎意味着APacketSource::APacketSource构造函数中的ASessionDescription::getDimensions调用失败了。这似乎不应该发生，因为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正在寻找(看起来格式良好的) DESCRIBE结果中的framesize属性。

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属性。因此，我提出以下问题：

1. 我读到消息来源了吗？ASessionDescription::getDimensions调用中有问题吗？( stagefright实际上只支持H.263流媒体吗？)
2. 或者Pi端代码在某种程度上是错误的？
3. 还是我只是在客户端代码中遗漏了一两个关键步骤？

最新情况，20140606：

MediaPlayer文档说-1010是无支撑："Bitstream符合相关的编码标准或文件规范，但是媒体框架不支持这个特性。“这让我想知道问题是否是“标准”的渐进下载问题。也就是说，支持的媒体格式说

对于在MPEG-4容器中通过HTTP或RTSP流的视频内容，moov原子必须位于任何mdat原子之前，但必须继承ftyp原子。

而大多数流将moov原子放在最后。

不过，我一点也不确定如何验证这一点！

• 我在vlc源中没有看到moov或ftyp原子。(我被告知，vlc只是流的，在这里；实际的H264内容是从相机驱动程序中出来的。)
• 我在moov linux或userland分支中没有看到ftyp或https://github.com/raspberrypi原子。(也许我只是在为错误的事情喝彩。)
• 当我保存vlc流时，我会在mp4之前使用moov获得一个mdat文件，但是当然，vlc可以在这里进行一些代码转换。

最新情况，20140610：

GPAC "Osmo4“播放器可以在Android4.3平板电脑上显示流。严重(比笔记本电脑上的VLC滞后，而且容易被锁定)，但可以显示它。

最新情况，20140616：

当我再次尝试对VLC源(不区分大小写和不面向字)时，我确实找到了FOURCC宏定义了moov和ftyp原子在modules/mux/mp4.c中，这很快导致了--sout-mp4-faststart (和--no-sout-mp4-faststart)开关.这没什么区别。

所以，它看起来可能并不是原子有序的问题。这很好，如果它关闭了一整类死胡同，但它确实让我的头撞墙(这似乎总是对我的头部造成更多的伤害，而不是对墙)毫无线索。

最新情况，20140702：

我为Android编译了VLC，它可以在pi上显示VLC生成的流。它把图片放在屏幕的左上角；我试着为他们的.so写我自己的皮肤，却找不到任何可以让我放大到表面或其他东西的“旋钮”。(加上.apk达到了大约12米！)

因此，我找到了相关的RFCs并编写了我自己的RTSP客户端。或者尝试:我可以解析SDP并生成足够有效的RTSP来获取RTP和RTCP数据报，并且可以解析RTP和RTCP头。尽管SDP声称提供了m=video 0 RTP/AVP 96和a=rtpmap:96 H 264/90000，但MediaCodec不会在我的平板电脑上显示视频，无论我把平板电脑上的三种H264编解码器传递给MediaCodec.createByCodecName()，当我查看RTP有效载荷时，我并不感到太惊讶:我在任何数据包中都看不到NAL同步模式。

相反，它们都是以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或osmo4播放器的Vlc要好得多:它有亚秒延迟(至少当发送方和接收方在同一个wifi路由器上时！)并填充SurfaceView。

一些外卖，帮助任何试图做类似事情的人：

• 传递给MediaCodec.queueInputBuffer()的所有输入缓冲区必须从0001 同步模式开始。
• 您可以立即对编解码器进行configure()和start()，但是在看到SPS (NALU代码7)和PPS (NALU代码8)数据包之前，不要对任何“正常”输入缓冲区进行排队。(这些可能不是0x67和0x68 - "nal_ref_idc“位应该是非零，但不一定是11。Fwiw，vlc似乎总是给我01。)
• 传递SPS/PPS数据包几乎通常--将配置标志传递给queueInputBuffer()。特别是，不要试图将它们放在附加到MediaFormat的“CSC-0”缓冲区中！
• 当您看到(a)丢失的帧(即，您看到RTP序列号的跳转)时，不要调用codec.flush()(http://developer.android.com/reference/android/media/MediaCodec.html#flush(%29)!只跳过部分帧，直到下一个完整帧才排队)。