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 _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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) 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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? _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 <[hidden email]> 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) > 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) > 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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 <[hidden email]> > 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 >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > 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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Sounds like a job for wireshark.
On Thu, Aug 16, 2012 at 1:29 PM, Loren Rogers <[hidden email]> wrote: If the log is from the Android device, what it looks like is that the _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Loren Rogers
Hmmm, ok. (Yes they're from the android device). Would that be a
problem with the pipeline on the server side, or something on the client that I need to define the caps explicitly? Sorry, I'm a n00b. Thanks for your help. -John On 08/16/2012 01:29 PM, Loren Rogers 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 <[hidden email]> 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) >> 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) >> 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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 <[hidden email]> >> 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 >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
In reply to this post by Chuck Crisler-2
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 <[hidden email]> wrote: > Sounds like a job for wireshark. > > > On Thu, Aug 16, 2012 at 1:29 PM, Loren Rogers <[hidden email]> > 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 <[hidden email]> >> 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) >> > 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) >> > 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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 <[hidden email]> >> > 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 >> >> [hidden email] >> >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> > >> > >> > >> > >> > _______________________________________________ >> > gstreamer-devel mailing list >> > [hidden email] >> > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> > >> > >> > >> > _______________________________________________ >> > gstreamer-devel mailing list >> > [hidden email] >> > 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 >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel > > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > 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 [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 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"; @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 <[hidden email]> wrote: >> Sounds like a job for wireshark. >> >> >> On Thu, Aug 16, 2012 at 1:29 PM, Loren Rogers <[hidden email]> >> 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 <[hidden email]> >>> 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) >>>> 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) >>>> 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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 <[hidden email]> >>>> 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 >>>>> [hidden email] >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> gstreamer-devel mailing list >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>> >>>> >>>> >>>> _______________________________________________ >>>> gstreamer-devel mailing list >>>> [hidden email] >>>> 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 >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> >> >> _______________________________________________ >> gstreamer-devel mailing list >> [hidden email] >> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >> > > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel tcpdump.pcap (18K) Download Attachment |
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 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"; > > @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 >> <[hidden email]> wrote: >>> Sounds like a job for wireshark. >>> >>> >>> On Thu, Aug 16, 2012 at 1:29 PM, Loren Rogers <[hidden email]> >>> 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 <[hidden email]> >>>> 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) >>>>> 08-16 13:12:45.905: E/MediaPlayer(30783): Error (1,-2147483648) >>>>> 08-16 13:12:45.905: D/VideoView(30783): Error: 1,-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 >>>>> <[hidden email]> >>>>> 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 >>>>>> [hidden email] >>>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gstreamer-devel mailing list >>>>> [hidden email] >>>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gstreamer-devel mailing list >>>>> [hidden email] >>>>> 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 >>>> [hidden email] >>>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>> >>> >>> _______________________________________________ >>> gstreamer-devel mailing list >>> [hidden email] >>> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel >>> >> >> > _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 to see what it means.
On Thu, Aug 16, 2012 at 3:05 PM, John Ruemker <[hidden email]> 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. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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=<a class="moz-txt-link-freetext" href="rtsp://:8554/test">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 to see what it means. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 <[hidden email]> wrote:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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. _______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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:
_______________________________________________ gstreamer-devel mailing list [hidden email] http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |