2
votes

Android will play both the audio and video (AAC,h263) that I server it from my rtp server, but when I serve an AAC/H264 stream, I only get the audio and no video.

In the working scenario, Android issues a SETUP command for both track ids, but the H264, android never issues the SETUP command for the second Video track.

Is my SDP file correct? The profile-id and sprops I believe are correct as are copied directly from the sps and pps NALs from the H264 encoder. The video is [email protected]

Is Android failing to repsond or recognise the second track?

If I stream the video file by itself with live555 it works fine, and I have compared the SDP file it produces with my own one.

Any ideas? Thanks

H264/AAC SDP file:

v=0
o=xxx IN IP4 192.168.13.43
s=live.3gp
u=http:///
e=admin@
c=IN IP4 0.0.0.0
b=AS:187
t=0 0
a=control:rtsp://192.168.13.43:555/live.3gp
a=isma-compliance:1,1.0,1
a=range:npt=0-  2630.336000
m=audio 0 RTP/AVP 97
a=rtpmap:97 MP4A-LATM/44100/2
a=control:rtsp://192.168.13.43:555/live.3gp/trackID=1
a=fmtp:97 profile-level-id=41; cpresent=0; config=400024203fc0
m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=control:rtsp://192.168.13.43:555/live.3gp/trackID=2
a=cliprect:0,0,256,432
a=framesize:96 432-256
a=fmtp:96 packetization-mode=1; profile-level-id=42C015;sprop-parameter-   sets=Njc0MkMwMTVGNDBEODQzNjAyMjAwMDAwMDMwMDIwMDAwMDAzMDNDMUUzMDY1NA==,NjhDRTA0NzI=

SDP file produced by live555 for the same video file which does display on Android:

v=0
o=- 1303401850159891 1 IN IP4 192.168.13.58
s=H.264 Video, streamed by the LIVE555 Media Server
i=live.3g
t=0 0
a=tool:LIVE555 Streaming Media v2011.01.19
a=type:broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:H.264 Video, streamed by the LIVE555 Media Server
a=x-qt-text-inf:baseCasterCap.264
m=video 0 RTP/AVP 96
c=IN IP4 0.0.0.0
b=AS:500
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=42C015;sprop-parameter-sets=Z0LAFfQNhDYCIAAAAwAgAAADA8HjBlQ=,aM4Ecg==
a=control:track1
2

2 Answers

1
votes

sprop-parameter-sets shouldn't have a tab or space in it (may be a copy/paste bug).

Android (or the player being used there) may not support packetization-mode 1. 0 is required; 1 is optional.

a=framesize and a=cliprect - those aren't standard H.264, but may not be a problem.

I assume the port 0 is normal for your usage (since audio works)? In offer-answer, port 0 would be a rejected stream (in an answer; in an offer it means a disabled stream).

I've seen implementations (I'm looking at YOU, Grandstream!) that insist on spaces after semi-colons for H264 fmtp (they're wrong) - you have a mixture.

Is the "C0" in the profile-level-id correct? that adds constraints; try it without the constraints and see what the response is. (You can still send a more-constrained stream than the SDP indicated.)

1
votes

Thanks for your help Jesup, it was very much appreciated.

The problem was the sprop parameters, I noticed when I copy and pasted the second SDP file for you.

The encoder I used to do the base64 calculation for my testing was for character data, not binary data. So 65 was being interpreted as the character 6, and the character 5, and encoded, rather than the single number (A in ascii I guess). Does that make sense? Silly mistake on my part. Thanks again Ian