我正在尝试在Android设备上显示H.264编码的rtsp视频。该流来自Raspberry Pi，使用vlc编码/dev/video1，这是一个＆＃34; Pi NoIR相机板＆＃34;。
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();
并获得＆＃34;准备失败：状态= 0x1＆＃34; 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来源，似乎表示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 {{1属性。因此我的问题是：
framesize电话中的问题是？ （stagefright实际上只支持H.263流媒体吗？） ASessionDescription::getDimensions文档说-1010是MEDIA_ERROR_UNSUPPORTED：＆＃34;比特流符合相关的编码标准或文件规范，但媒体框架不支持该功能。＆＃34 ;这让我想知道问题是否是“标准”。渐进式下载问题。也就是说，Supported Media Formats说
对于通过HTTP或RTSP [在] MPEG-4 [容器]中流式传输的视频内容，
MediaPlayer原子必须位于任何moov个原子之前，但必须接替mdat个原子
虽然大多数流都将ftyp原子放在最后。
但我完全不确定如何验证这一点！
moov或moov个原子。 （我告诉 vlc只是流媒体，这里;实际的H264内容来自相机驱动程序。）ftyp或moov个原子。 （不过我可能只是为了错误的事情而努力。）ftyp之前获得一个moov的mp4文件，但当然vlc可以在这里进行一些转码。GPAC "Osmo4" player可以在Android 4.3平板电脑上显示流。非常糟糕（比笔记本电脑上的VLC更滞后，并且容易出现锁定）但可以显示它。
当我尝试再次点击VLC源时（不区分大小写且没有字向，这一次）我确实找到了定义mdat中moov和ftyp个原子的FOURCC宏，这很快导致了modules/mux/mp4.c（和--sout-mp4-faststart）开关......这些开关没有任何区别。
因此，它看起来可能实际上不是原子排序问题。很高兴知道，如果它关闭了整个类别的死胡同，但它确实让我的头靠在墙上（这似乎总是对我的头部造成更大的伤害而不是对墙壁的伤害）线索。
我为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，--no-sout-mp4-faststart也不会在我的表面上显示视频，无论哪个我的平板电脑上的三个H264编解码器传递给MediaCodec.createByCodecName()，当我查看RTP有效载荷时，我并不感到惊讶：我在任何地方都看不到NAL sync pattern任何数据包。
相反，他们所有以MediaCodec（通常）或偶尔21 9A __ 22 FF开头，其中__似乎总是一个偶数，每个数据包增加2 。我不认识这种模式 - 你呢？
事实证明，H264数据包不必以NAL同步模式开始 - 只有在NAL单元可以嵌入较大数据流的情况下才是必需的。我的RTP数据包格式为RFC 6184。
答案 0 :(得分：3)
在经历了惊人数量的死胡同后，我可以在Android SurfaceView上显示H264 RTSP流。这个答案只是那种的答案，因为我仍然无法解决我原来的三个问题，但即使充满了bug和快捷方式，我的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.）queueInputBuffer()。特别是，不要试图将它们放在附加到MediaFormat的“csd-0”缓冲区中！codec.flush()！只需跳过部分帧，不要将缓冲区排到下一个完整帧之前。