为什么我会收到"不支持的格式"错误,使用Android MediaPlayer读取H.264编码的rtsp流？

Question

我想在Android设备上显示H.264编码的rtsp视频.该流来自Raspberry 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();

并获得"准备失败:状态= 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属性.因此我的问题:

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

更新,20140606:

该MediaPlayer文档说-1010被MEDIA_ERROR_UNSUPPORTED:"档案是符合相关的编码标准或文件规范,但媒体框架不支持该功能." 这让我想知道问题是否是"标准"渐进式下载问题.也就是说,支持媒体格式说

对于通过HTTP或RTSP [在] MPEG-4 [容器]中流式传输的视频内容,moov原子必须在任何mdat原子之前,但必须接替ftyp原子

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

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

• 我在vlc源中看不到moov或ftyp原子.(我被告知 vlc只是流媒体,这里;实际的H264内容来自相机驱动程序.)
• 我在https://github.com/raspberrypi linux或userland分支中看不到moov或ftyp原子.(也许我只是在为错误的事情着想.)
• 当我VLC保存流,我得到一个MP4文件,moov之前mdat,但当然VLC可以做一些转换,在这里.

更新,20140610:

所述GPAC"Osmo4"玩家可以在Android 4.3平板显示流.很糟糕(比笔记本电脑上的VLC更滞后,并且容易发生锁定)但它可以显示它.

更新,20140616:

当我尝试再次点击VLC源时(不区分大小写且没有字向,这一次)我确实找到了定义moov和ftyp原子的FOURCC宏modules/mux/mp4.c,这很快导致了--sout-mp4-faststart(和--no-sout-mp4-faststart)开关......这些都没有任何差异.

因此,它看起来可能实际上不是原子排序问题.很高兴知道,如果它关闭了一整类死胡同,但它确实让我头撞在墙上(这似乎总是对我的头部造成更大的伤害而不是对墙壁造成伤害).

更新,20140702:

我为Android编译了VLC,它可以在pi上显示VLC生成的流.它将图像放在屏幕的左上角; 我尝试为自己的.so编写自己的皮肤,并且找不到任何可以让我缩放到表面或其他任何东西的"旋钮".(加上.apk大约12M!)

所以,我找到了相关的RFC,并编写了自己的RTSP客户端.或者尝试:我可以解析SDP并生成足够的有效RTSP来获取RTP和RTCP数据报,并且我可以解析RTP和RTCP报头.但即使SDP声称提供m =视频0 RTP/AVP 96和a = rtpmap:96 H264/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 上显示 H264 RTSP 流SurfaceView。这个答案只是一种答案，因为我仍然无法解决我原来的三个问题，但即使充满了错误和快捷方式，我的 75K apk 还是比 Android 的 Vlc 或 osmo4 播放器好得多：它有子- 秒延迟（至少当发送方和接收方在同一个 wifi 路由器上时！）并填充SurfaceView.

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

• 您传递到的所有输入缓冲区都MediaCodec.queueInputBuffer()必须以 00 00 01同步模式开始。
• 你可以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!
• 当您看到 (a) 丢失的帧（即您看到 RTP 序列号跳转）时，请不要调用codec.flush()！只需跳过部分帧，并且在下一个完整帧之前不要排队缓冲区。