RTSP stream for android devices
John Ruemker
john.ruemker at gmail.com
Sat Aug 25 05:45:14 PDT 2012
Looks like the fact that its not setting profile-level-id on the outcaps
of rtph264enc is intentional:
https://bugzilla.gnome.org/show_bug.cgi?id=607353
http://cgit.freedesktop.org/gstreamer/gst-plugins-good/commit/?id=c4fa559f1594ab4f8505da78196c5a871b833c0a
So would it be a bug in android that it requires it to be set, or is it
possible the decision in the above bugzilla would need to be reconsidered?
Thanks,
John
On 08/25/2012 08:35 AM, John Ruemker wrote:
> I've finally gotten some more time to mess around with this, and your
> suggestion to compare vlc vs gstreamer in wireshark lead me to what
> seems to be the key difference. I was seeing in the vlc SDP
> information that it was passing fmtp profile-level-id=64001f, so I
> decided to try and get gstreamer to set this.
>
> gst-inspect on rtph264pay shows that it has this property (albeit
> deprecated), yet for some reason setting it does not result in this
> property ending up in the sdp info.
>
> gst_rtsp_media_factory_set_launch(factory, "( "
> "filesrc location=/home/jruemker/Download/star.mkv ! "
> "decodebin name=dec dec. ! ffmpegcolorspace ! videoscale ! "
> "x264enc profile=1 ! rtph264pay profile-level-id=64001f name=pay0
> pt=96 "
> "dec. ! queue ! audioresample ! audioconvert ! "
> "alawenc ! rtppcmapay name=pay1 pt=97 "
> ")");
>
> After trying all the different ways I could think of, I eventually
> just forced it with some hackery in gstreamer-rtsp:
>
> diff -up
> gst-rtsp-0.10.8/gst/rtsp-server/rtsp-sdp.c.add-sdp-control-uri
> gst-rtsp-0.10.8/gst/rtsp-server/rtsp-sdp.c
> --- gst-rtsp-0.10.8/gst/rtsp-server/rtsp-sdp.c.add-sdp-control-uri
> 2010-12-28 12:04:26.000000000 -0500
> +++ gst-rtsp-0.10.8/gst/rtsp-server/rtsp-sdp.c 2012-08-25
> 07:23:47.502199604 -0400
> @@ -143,6 +147,8 @@ gst_rtsp_sdp_from_media (GstSDPMessage *
> first = FALSE;
> }
> }
> + g_string_append_printf (fmtp, "%s%s=%s", ";", "profile-level-id",
> "64001f");
> +
> if (!first) {
> tmp = g_string_free (fmtp, FALSE);
> gst_sdp_media_add_attribute (smedia, "fmtp", tmp);
>
>
> With this change, android plays the above stream perfectly.
>
> So, the only question left is: how can I configure my pipeline so that
> it properly sets the profile-level-id=64001f property in the sdp
> information?
>
> Thanks
>
>
> On 08/17/2012 10:07 AM, Chuck Crisler wrote:
>> OK, I am way beyond knowledge and into guessing here.
>> Does the RTSP need the RTP payloader? Try substituting UPD instead.
>> The RTP payloader is taking the RTSP packets and wrapping them in an
>> RTP header, which probably won't work. (I didn't think about that
>> earlier.) Did you get a wireshark trace of the VLC stream? If not, do
>> so. Then you can compare the packets and tell the difference, like
>> does VLC wrap the packets in RTP. You can decode a RTP stream in
>> Wireshark by clicking on a packet and selecting something like decode
>> as... RTP. Wireshark will then translate all of the packets in that
>> conversation (pretty cool, actually). Hmmm, I don't know but you
>> might also be able to decode a RTSP stream the same way. Wireshark is
>> a great tool to play with.
>>
>> On Thu, Aug 16, 2012 at 5:30 PM, John Ruemker <john.ruemker at gmail.com
>> <mailto:john.ruemker at gmail.com>> wrote:
>>
>> Ok, made a little bit of progress. I'm able to play an rtsp
>> video stream generated by vlc. This at least confirms that the
>> test app is capable of playing an rtsp, which is good because I
>> was starting to doubt that.
>>
>> I used the vlc wizard to set it up and the generated output
>> string is as follows:
>>
>> :sout=#transcode{vcodec=h264,vb=500,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=8000}:rtp{sdp=rtsp://:8554/test}
>> :sout-keep
>>
>>
>> For some reason the audio doesn't work, but I know its at least
>> detecting the audio stream because if I set the codec in VLC to
>> anything other than MPEG 4 Audio (AAC), MPEG Audio, or Vorbis,
>> android refuses to play it at all. With one of those 3, it plays
>> the video but not the audio. I'm not terribly concerned with the
>> audio part right now; I can play with that later if I at least
>> get video working from gstreamer.
>>
>> Does the VLC output stream that I discovered to work differ in
>> any significant ways from the gstreamer pipeline I was trying
>> earlier? Are there any gstreamer element options that would be
>> needed in order to match the vlc version?
>>
>> Thanks
>>
>>
>> On 08/16/2012 03:42 PM, Chuck Crisler wrote:
>>> Sorry, but I don't see anything. You might try setting up a
>>> different RTSP server (VLC?) and test that for comparison.
>>> Capture a wireshark trace to see the detail difference. Also,
>>> look up the Android error code -2147483648 <tel:2147483648> to
>>> see what it means.
>>>
>>> On Thu, Aug 16, 2012 at 3:05 PM, John Ruemker
>>> <john.ruemker at gmail.com <mailto:john.ruemker at gmail.com>> wrote:
>>>
>>> I've switched to baseline profile and 500Kbps bitrate on
>>> x264enc, and scaled the resolution and framerate on
>>> videoscale to match the parameters specified in the android
>>> requirements, with no change in behavior on the client.
>>>
>>> gst_rtsp_media_factory_set_launch(factory, "( "
>>> "filesrc location=/home/jruemker/Download/star.mkv ! "
>>> " decodebin name=dec dec. ! queue ! videoscale !
>>> video/x-raw-yuv,width=480,height=360,framerate=(fraction)30/1 !
>>> "
>>> " x264enc profile=1 bitrate=500 ! "
>>> "rtph264pay name=pay0 pt=96 "
>>> ")");
>>>
>>>
>>>
>>> On 08/16/2012 02:01 PM, John Ruemker wrote:
>>>
>>> Here's the entire communication between client & server
>>> (148 is client, 9 is server):
>>>
>>> 30 7.108768 192.168.2.148 -> 192.168.2.9 TCP 74
>>> 49571 > rtsp-alt [SYN] Seq=0 Win=14600 Len=0 MSS=1460
>>> SACK_PERM=1 TSval=37853209 TSecr=0 WS=2
>>> 36 7.312196 192.168.2.9 -> 192.168.2.148 TCP 74
>>> rtsp-alt > 49571 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0
>>> MSS=1460 SACK_PERM=1 TSval=391976951 TSecr=37853209 WS=128
>>> 38 7.327221 192.168.2.148 -> 192.168.2.9 TCP 66
>>> 49571 > rtsp-alt [ACK] Seq=1 Ack=1 Win=14600 Len=0
>>> TSval=37853257 TSecr=391976951
>>> 39 7.336107 192.168.2.148 -> 192.168.2.9 RTSP 201
>>> DESCRIBE rtsp://192.168.2.9:8554/test
>>> <http://192.168.2.9:8554/test> RTSP/1.0
>>> 40 7.336199 192.168.2.9 -> 192.168.2.148 TCP 66
>>> rtsp-alt > 49571 [ACK] Seq=1 Ack=136 Win=15616 Len=0
>>> TSval=391977178 TSecr=37853258
>>> 47 8.287674 192.168.2.9 -> 192.168.2.148 RTSP/SDP
>>> 619 Reply: RTSP/1.0 200 OK, with session description
>>> 49 8.349307 192.168.2.148 -> 192.168.2.9 TCP 66
>>> 49571 > rtsp-alt [ACK] Seq=136 Ack=554 Win=15706 Len=0
>>> TSval=37853462 TSecr=391978130
>>> 51 8.391433 192.168.2.148 -> 192.168.2.9 TCP 66
>>> 49571 > rtsp-alt [FIN, ACK] Seq=136 Ack=554 Win=15706
>>> Len=0 TSval=37853469 TSecr=391978130
>>> 52 8.391511 192.168.2.9 -> 192.168.2.148 TCP 66
>>> rtsp-alt > 49571 [FIN, ACK] Seq=554 Ack=137 Win=15616
>>> Len=0 TSval=391978234 TSecr=37853469
>>> 54 8.394598 192.168.2.148 -> 192.168.2.9 TCP 66
>>> 49571 > rtsp-alt [ACK] Seq=137 Ack=555 Win=15706 Len=0
>>> TSval=37853471 TSecr=391978234
>>>
>>>
>>> Packet 47 (the reply RTSP/1.0 200 OK) contains the
>>> following info in the SDP portion:
>>>
>>> Session Description Protocol Version (v): 0
>>> Owner/Creator, Session Id (o): - 1188340656180883 1 IN
>>> IP4 192.168.2.9
>>> Session Information (i): rtsp-server
>>> Session Attribute (a): type:broadcast
>>> Session Attribute (a): control:*
>>> Session Attribute (a): range:npt=0.000000-60.767000
>>> Media Description, name and address (m): video 0 RTP/AVP 96
>>> Connection Information (c): IN IP4 192.168.2.9
>>> Media Attribute (a): rtpmap:96 H264/90000
>>> Media Attribute (a): control:stream=0
>>> Media Attribute (a): fmtp:96
>>> sprop-parameter-sets=Z0LAH9kAUARbARAAAAMAF3NZQADxgySAAA==,aMuMsg==
>>>
>>> Full tcpdump is attached if it helps.
>>>
>>> Regarding the app on the android side, I'm using a
>>> VideoView element to play. Supposedly you can just hand
>>> off the RTSP URI to a VideoView and call the play
>>> function and it works. The test I'm using is pretty basic:
>>>
>>> package org.ruemker.play_rtsp;
>>>
>>> import android.app.Activity;
>>> import android.net.Uri;
>>> import android.os.Bundle;
>>> import android.widget.MediaController;
>>> import android.widget.VideoView;
>>>
>>> public class MainActivity extends Activity {
>>>
>>> String SrcPath = "rtsp://192.168.2.9:8554/test
>>> <http://192.168.2.9:8554/test>";
>>>
>>> @Override
>>> public void onCreate(Bundle savedInstanceState) {
>>> super.onCreate(savedInstanceState);
>>> setContentView(R.layout.activity_main);
>>> VideoView myVideoView =
>>> (VideoView)findViewById(R.id.myvideoview);
>>> myVideoView.setVideoURI(Uri.parse(SrcPath));
>>> myVideoView.setMediaController(new
>>> MediaController(this));
>>> myVideoView.requestFocus();
>>> myVideoView.start();
>>> }
>>>
>>> }
>>>
>>>
>>> On 08/16/2012 01:44 PM, Loren Rogers wrote:
>>>
>>> Wireshark would help, and you can show "handshaking"
>>> RTSP negotiation.
>>> What happens in RTSP is a client sends a request
>>> which if you look @
>>> the RTSP packets it looks like a URI with a specific
>>> format. You'll
>>> want to make sure that that URI looks correct and
>>> that the android
>>> video rendering mechanism is configured to receive
>>> that specific media
>>> and it's properties. Also I'm not sure about what
>>> application you are
>>> using on the Android side to request a RTSP session
>>> and render the
>>> media. But if you are using an app from Google play
>>> I'd read up on
>>> the help if they have it. Also have a read of RTSP
>>> RFC couldn't hurt
>>> either.
>>> /Loren
>>>
>>> On Thu, Aug 16, 2012 at 1:37 PM, Chuck Crisler
>>> <ccrisler at mutualink.net
>>> <mailto:ccrisler at mutualink.net>> wrote:
>>>
>>> Sounds like a job for wireshark.
>>>
>>>
>>> On Thu, Aug 16, 2012 at 1:29 PM, Loren Rogers
>>> <loren.rogers at gmail.com
>>> <mailto:loren.rogers at gmail.com>>
>>> wrote:
>>>
>>> If the log is from the Android device, what
>>> it looks like is that the
>>> Android device is missing the caps
>>> negotiation (probably SDP) that's
>>> sent from the RTSP server. OR the Android
>>> device is trying to open a
>>> file with poorly formed stream information.
>>>
>>> On Thu, Aug 16, 2012 at 1:15 PM, John
>>> Ruemker <john.ruemker at gmail.com
>>> <mailto:john.ruemker at gmail.com>>
>>> wrote:
>>>
>>> I was wondering if the alawenc audio
>>> encoder is the problem, considering
>>> the
>>> android doc states you should use
>>> AAC-LC. However if I try to switch to
>>> ffenc_aac I can't get a stream that even
>>> vlc will play. I'm not really
>>> sure
>>> with rtp payloader goes with ffenc_aac.
>>> So ultimately, I decided to
>>> just
>>> remove the audio stream for now and see
>>> if I could get video working.
>>> VLC
>>> plays it fine, but android still won't,
>>> so the issue is likely somewhere
>>> in
>>> the x264enc part.
>>>
>>> The logs from the android MediaPlayer
>>> and VideoView classes are not very
>>> specific.
>>>
>>>
>>> 08-16 13:12:39.320:
>>> D/OpenGLRenderer(30587): Flushing caches
>>> (mode 0)
>>> 08-16 13:12:39.350:
>>> D/OpenGLRenderer(30587): Flushing caches
>>> (mode 1)
>>> 08-16 13:12:45.555: D/libEGL(30783): loaded
>>> /system/lib/egl/libEGL_mali.so
>>> 08-16 13:12:45.555: D/libEGL(30783): loaded
>>> /system/lib/egl/libGLESv1_CM_mali.so
>>> 08-16 13:12:45.560: D/libEGL(30783): loaded
>>> /system/lib/egl/libGLESv2_mali.so
>>> 08-16 13:12:45.635:
>>> D/OpenGLRenderer(30783): Enabling debug
>>> mode 0
>>> 08-16 13:12:45.645:
>>> D/MediaPlayer(30783): Couldn't open file
>>> on client
>>> side,
>>> trying server side
>>> 08-16 13:12:45.800:
>>> D/MediaPlayer(30783): getMetadata
>>> 08-16 13:12:45.905:
>>> E/MediaPlayer(30783): error (1,
>>> -2147483648 <tel:2147483648>)
>>> 08-16 13:12:45.905:
>>> E/MediaPlayer(30783): Error
>>> (1,-2147483648 <tel:2147483648>)
>>> 08-16 13:12:45.905: D/VideoView(30783):
>>> Error: 1,-2147483648 <tel:2147483648>
>>>
>>> I guess I'll have to try and play around
>>> with the resolution, bitrates,
>>> etc
>>> as you pointed out and see if I can make
>>> any progress there.
>>>
>>>
>>> Thanks for your help.
>>>
>>> -John
>>>
>>>
>>> On 08/16/2012 12:35 PM, Chuck Crisler wrote:
>>>
>>> I am not sure about the default x264enc
>>> parameters, but you need to
>>> insure
>>> that it is using baseline,
>>> width/height/frame/bit rates all as
>>> specified
>>> by
>>> the android. I suspect that the defaults
>>> are not what the Android wants
>>> and
>>> probably if any is wrong the Android
>>> would reject it but VLC will deal
>>> with
>>> it. Can you get a log from the Android
>>> to see what it doesn't like?
>>>
>>> On Thu, Aug 16, 2012 at 11:51 AM, John
>>> Ruemker <john.ruemker at gmail.com
>>> <mailto:john.ruemker at gmail.com>>
>>> wrote:
>>>
>>> On 08/15/2012 12:00 PM, John Ruemker
>>> wrote:
>>>
>>> Hello,
>>> I am trying to figure out a way
>>> to take a local video which may
>>> be in
>>> one
>>> of a few different formats (mkv,
>>> mp4, avi) and create an rtsp stream
>>> that
>>> can be viewed by android
>>> devices. I've been playing
>>> around with
>>> gstreamer-rtsp-server, and using
>>> the test-readme.c example can create
>>> a
>>> stream from an mkv that is
>>> watchable in vlc, but android cannot
>>> process it:
>>>
>>> gst_rtsp_media_factory_set_launch(factory,
>>> "( "
>>> "filesrc
>>> location=/home/user/project/spider.mkv
>>> ! "
>>> "decodebin name=dec dec. !
>>> queue ! x264enc ! "
>>> "rtph264pay name=pay0 pt=96
>>> dec. ! queue ! audioresample !
>>> audioconvert
>>> ! "
>>> "alawenc ! rtppcmapay
>>> name=pay1 pt=97 "
>>> ")");
>>>
>>> I'm guessing the way its encoded
>>> is not supported by android:
>>>
>>>
>>>
>>> http://developer.android.com/guide/appendix/media-formats.html#recommendations
>>>
>>>
>>> While I have done a good bit of
>>> reading through the gstreamer
>>> docs and
>>> understand pipelines and such,
>>> I'll admit I don't know much about
>>> formats
>>> and codecs. What sort of
>>> pipeline should I use to encode
>>> the video
>>> and
>>> audiostreams such that an
>>> android device would be able to
>>> play it
>>> back, per
>>> the requirements listed in the
>>> above link?
>>>
>>> Thanks for your help.
>>>
>>> -John
>>>
>>>
>>> Hi,
>>> Anyone have any ideas on the above?
>>> I'm just not sure how to go about
>>> encoding to meet the requirements
>>> that are laid out in the Android
>>> development guide. Any assistance
>>> would be greatly appreciated.
>>>
>>> Thanks
>>>
>>> -John
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>> --
>>> "Some men see things as they are and say
>>> why. I dream things that
>>> never were and say why not?" - GBS
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org
>>> <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> gstreamer-devel at lists.freedesktop.org <mailto:gstreamer-devel at lists.freedesktop.org>
>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> <mailto:gstreamer-devel at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>
>>
>>
>>
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120825/bcf017d4/attachment-0001.html>
More information about the gstreamer-devel
mailing list