changing souphttpsrc location property on android
Locked
 
|
Hi everyone,
I am trying to change the location uri for the souphttpsrc on android and this is the code I have written (based on tutorial5 for android): /* Set playbin2's URI */ void gst_native_set_uri (JNIEnv* env, jobject thiz, jstring uri) { CustomData *data = GET_CUSTOM_DATA (env, thiz, custom_data_field_id); if (!data || !data->pipeline) return; const jbyte *char_uri = (*env)->GetStringUTFChars (env, uri, NULL); GstElement *http_src;//mod gchar *location;//mod gchar *next_location = g_strdup(char_uri); http_src = gst_bin_get_by_name (GST_BIN(data->pipeline), "http_src");//mod if(!http_src)//mod GST_DEBUG("GstElement http_src ERROR!");//mod else//mod GST_DEBUG("GstElement http_src OK");//mod GST_DEBUG ("Setting URI to %s", char_uri); /*This the modified part of the function*/ data->target_state = GST_STATE_READY;//mod gst_element_set_state(data->pipeline, GST_STATE_READY);//mod GST_DEBUG("Pipeline state: READY");//mod g_object_get(G_OBJECT(http_src), "location", &location, NULL);//mod g_print("Current http-src location: %s", location);//mod g_object_set(G_OBJECT(http_src), "location", char_uri, NULL);//mod g_object_get(G_OBJECT(http_src), "location", &location, NULL);//mod g_print("Current http-src location: %s", location);//mod data->target_state = GST_STATE_PLAYING;//mod gst_element_set_state(data->pipeline, GST_STATE_PLAYING);//mod GST_DEBUG("Pipeline state: PLAYING");//mod gst_object_unref (http_src);//mod /*End of modified code*/ (*env)->ReleaseStringUTFChars (env, uri, char_uri); data->duration = GST_CLOCK_TIME_NONE; data->is_live = (gst_element_set_state (data->pipeline, data->target_state) == GST_STATE_CHANGE_NO_PREROLL); } So as this function is called, when it used to be a playbin, just by adding the GST_STATE_READY and the g_object_set() for the uri worked fine. Now I have a working pipeline with a checked .ts and it initially works, but not when this function is called. The debug logs for the location property gets changed but what happens is that the app gets paused (no crash at all) with the outdated video. The initially working pipeline -using gst_parse_launch()- is:
The related log is: 05-17 11:04:54.500 19858-19924/com.sample.app W/GStreamer+basesrc: 0:00:11.130733339 0x9e012490 gstbasesrc.c:2943:gst_base_src_loop:<http_src> error: Internal data flow error.Can anyone give a clue for what I am missing? Thanks in advance, Dani _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Di, 2016-05-17 at 11:12 +0200, Dani wrote:
> > So as this function is called, when it used to be a playbin, just by > adding the GST_STATE_READY and the g_object_set() for the uri worked > fine. Now I have a working pipeline with a checked .ts and it > initially works, but not when this function is called. The debug logs > for the location property gets changed but what happens is that the > app gets paused (no crash at all) with the outdated video. The > initially working pipeline -using gst_parse_launch()- is: > > souphttpsrc name=http_src location=http://192.168.0.32/videos/sintel. > ts ! queue ! tsdemux name=demux > demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! glimagesink > name=video_sink > demux. ! queue ! aacparse ! faad ! audioconvert ! autoaudiosink > name=audio_sink > > > The related log is: > [...] pipelines (that is, going back to READY/NULL and starting them again) is generally not working well. It's better to recreate the whole pipeline. If you want to re-use pipelines, you better build them manually instead and handle the linking of pads in your code. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (968 bytes) |
|
Thanks for your suggestion,
you are right so what I have done is writing the pipeline, making, adding and linking elements one by one. What happens to me now is that, when dynamically adding audio and video pads from tsdemux to their own queues before the parsers, they are refused and there is no playout. The function for dynamically adding pads is (I know the conditional instructions are not implemented in an efficient way as I wrote them just to check where it failed): So the log prints the "Video link refused!" sentence and after that one:static void dynamic_addpad(GstElement *src, GstPad *new_pad, CustomData *data) { char* pad_name = gst_pad_get_name(new_pad); g_print(" In dynamic ADDING PAD %s\n", pad_name); if (g_str_has_prefix(pad_name,"audio")) { GstElement *q_audio; q_audio = gst_bin_get_by_name (GST_BIN(data->pipeline), "queue_audio"); GstPad *audiodemuxsink = gst_element_get_static_pad(q_audio,"sink"); if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_OK) g_print("Audio successfully linked!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_WRONG_HIERARCHY) g_print("Audio link wrong hierarchy!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_WAS_LINKED) g_print("Audio already linked!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_WRONG_DIRECTION) g_print("Audio link wrong direction!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_NOFORMAT) g_print("Audio link noformat!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_NOSCHED) g_print("Audio link nosched!\n"); else if(gst_pad_link(new_pad,audiodemuxsink) == GST_PAD_LINK_REFUSED) g_print("Audio link refused!\n"); g_print ("Sink pad link: '%s'\n", pad_name); gst_object_unref(q_audio); } else if (g_str_has_prefix(pad_name,"video")) { GstElement *q_video; q_video = gst_bin_get_by_name(GST_BIN(data->pipeline), "queue_video"); GstPad *videodemuxsink = gst_element_get_static_pad(q_video,"sink"); if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_OK) g_print("Video successfully linked!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_WRONG_HIERARCHY) g_print("Video link wrong hierarchy!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_WAS_LINKED) g_print("Video link already linked!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_WRONG_DIRECTION) g_print("Video link wrong direction!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_NOFORMAT) g_print("Video link noformat!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_NOSCHED) g_print("Video link nosched!\n"); else if(gst_pad_link(new_pad,videodemuxsink) == GST_PAD_LINK_REFUSED) g_print("Video link refused!\n"); g_print ("Sink pad link: '%s'\n", pad_name); gst_object_unref(q_video); } } 05-23 12:38:58.675 8461-8526/com.sample.app W/GStreamer+mpegtspacketizer: 0:00:01.503897667 0x9e11a260 mpegtspacketizer.c:2509:mpegts_packetizer_pts_to_ts Not enough information to calculate proper timestampWhich is understandable as there is no linking and therefore it has no info. There the log stops and the app does not crash but keeps a black video surface. Anyway I know where the problem is (dynamic linking) but I would appreciate any suggestions to solve it, I don't know why there is a link refusement for both audio and video streams, with the gst-launch way it was working correctly at this point. And the pc-equivalent code works fine exactly as shown on this post. The modifications implemented for the main method in android c source are as seen here: Thanks for your time,static void *app_function (void *userdata) { [...] GST_DEBUG ("Creating pipeline in CustomData at %p", data); /* Create our own GLib Main Context and make it the default one */ data->context = g_main_context_new (); g_main_context_push_thread_default(data->context); /* Build pipeline */ data->pipeline = gst_pipeline_new ("pipeline"); data->httpsrc = gst_element_factory_make ("souphttpsrc", "http_src"); data->tsdemux = gst_element_factory_make ("tsdemux", "demux"); data->queue_video = gst_element_factory_make("queue2", "queue_video"); data->h264parse = gst_element_factory_make ("h264parse", "h264_parse"); data->h264dec = gst_element_factory_make ("avdec_h264", "h264dec"); data->video_convert = gst_element_factory_make("videoconvert","video_convert"); data->videosink = gst_element_factory_make ("glimagesink", "video_sink"); data->queue_audio = gst_element_factory_make ("queue2", "queue_audio"); data->aacparse = gst_element_factory_make ("aacparse", "aacparse"); data->faad = gst_element_factory_make ("faad", "faad"); data->audio_convert = gst_element_factory_make("audioconvert", "audio_convert"); data->audiosink = gst_element_factory_make ("autoaudiosink", "audio_sink"); g_signal_connect (data->tsdemux, "pad-added", G_CALLBACK (dynamic_addpad), &data); gst_bin_add_many(GST_BIN(data->pipeline), data->httpsrc, data->tsdemux, data->queue_video, data->h264parse, data->h264dec, data->video_convert, data->videosink, data->queue_audio, data->aacparse, data->faad, data->audio_convert, data->audiosink, NULL); gst_element_link(data->httpsrc, data->tsdemux); gst_element_link_many(data->queue_video, data->h264parse, data->h264dec, data->video_convert, data->videosink, NULL); gst_element_link_many(data->queue_audio, data->aacparse, data->faad, data->audio_convert, data->audiosink, NULL); if (error) { gchar *message = g_strdup_printf("Unable to build pipeline: %s", error->message); g_clear_error (&error); set_ui_message(message, data); g_free (message); return NULL; } [...] } Dani El 18/05/16 a las 14:31, Sebastian
Dröge escribió:
On Di, 2016-05-17 at 11:12 +0200, Dani wrote:So as this function is called, when it used to be a playbin, just by adding the GST_STATE_READY and the g_object_set() for the uri worked fine. Now I have a working pipeline with a checked .ts and it initially works, but not when this function is called. The debug logs for the location property gets changed but what happens is that the app gets paused (no crash at all) with the outdated video. The initially working pipeline -using gst_parse_launch()- is: souphttpsrc name=http_src location=http://192.168.0.32/videos/sintel. ts ! queue ! tsdemux name=demux demux. ! queue ! h264parse ! avdec_h264 ! videoconvert ! glimagesink name=video_sink demux. ! queue ! aacparse ! faad ! audioconvert ! autoaudiosink name=audio_sink The related log is: [...]Can you get a full log? But in general, re-using gst_parse_launch() pipelines (that is, going back to READY/NULL and starting them again) is generally not working well. It's better to recreate the whole pipeline. If you want to re-use pipelines, you better build them manually instead and handle the linking of pads in your code. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Mo, 2016-05-23 at 13:07 +0200, Dani wrote:
> > Anyway I know where the problem is (dynamic linking) but I would > appreciate any suggestions to solve it, I don't know why there is a > link refusement for both audio and video streams, with the gst-launch > way it was working correctly at this point. And the pc-equivalent > code works fine exactly as shown on this post. Which of the link failure cases happens? The best way to debug this in any case is to enable debug logs and to see what happens right before the linking fails. That will tell you in great detail about the problem. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Sebastian Dröge-3
The link failure which happens from the tsdemux source to both audio
and video queue's sink is GST_PAD_LINK_REFUSED and the debug log is
not showing anything else related than what I wrote here on the
first posts:
05-27 12:27:41.355 7565-7565/com.sample.app I/Choreographer: Skipped 50 frames! The application may be doing too much work on its main thread. What I have tried is to run the same pipeline but changing the tsdemux element for a qtdemux just to give it a try with an mp4 file. It happens the same failure so I am a bit confused as I think I am following the right steps to run this pipeline but with no success. Thanks for your time, Dani _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Fr, 2016-05-27 at 12:43 +0200, Dani wrote:
> The link failure which happens from the tsdemux source to both audio > and video queue's sink is GST_PAD_LINK_REFUSED and the debug log is > not showing anything else related than what I wrote here on the first > posts: > [...] See my mail from Wednesday, we need more information like a full debug log of what is happening there. Basically more information is needed to know why exactly the linking is failing. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Thanks, I was working on how to get the full debug, after coding
inside the function JNI_OnLoad these instructions:
This is the debug log I get (I think I have copied the full log related to this issue):setenv("GST_DEBUG", "*:5", 1); setenv("GST_DEBUG_NO_COLOR", "1", 1); 05-30 10:07:54.905 9128-9246/? D/GStreamer+mpegts: 0:00:04.591262585 0x9e12ea60 gstmpegtssection.c:657:_parse_pmt Parsing 100 Program Map TableThanks for your time, Dani El 30/05/16 a las 07:50, Sebastian
Dröge escribió:
On Fr, 2016-05-27 at 12:43 +0200, Dani wrote:The link failure which happens from the tsdemux source to both audio and video queue's sink is GST_PAD_LINK_REFUSED and the debug log is not showing anything else related than what I wrote here on the first posts: [...]See my mail from Wednesday, we need more information like a full debug log of what is happening there. Basically more information is needed to know why exactly the linking is failing. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Mo, 2016-05-30 at 10:22 +0200, Dani wrote:
> Thanks, I was working on how to get the full debug, after coding inside the function JNI_OnLoad these instructions: > > setenv("GST_DEBUG", "*:5", 1); > setenv("GST_DEBUG_NO_COLOR", "1", 1); > This is the debug log I get (I think I have copied the full log related to this issue): > [...] Thanks, can you get the same with debug level 6? This one here does not contain many lines that should be there about the pad linking process, but a few of those should already be there with 5. In any case it's failing to link the pad not for one of the common reasons, but for the "fallback" error case GST_PAD_LINK_REFUSED -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
First of all thanks for your fast reply, here's the debug log with
level 6:
D/GStreamer+mpegts(16393): 0:00:05.820160711 0x9e236660 gstmpegtssection.c:657:_parse_pmt Parsing 100 Program Map Table The full debug (gstreamer related) is on this link, as it weighs ~20MB: https://www.dropbox.com/s/gied1nqdov3uitu/android_debug_full_log.txt?dl=0 Thanks for your time, Dani El 31/05/16 a las 08:20, Sebastian
Dröge escribió:
On Mo, 2016-05-30 at 10:22 +0200, Dani wrote: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Di, 2016-05-31 at 10:30 +0200, Dani wrote:
> > I/GLib+stdout(16393): In dynamic ADDING PAD audio_0066 > I/GLib+stdout(16393): //////////-6////////// > I/GLib+stdout(16393): Audio link refused! > I/GLib+stdout(16393): Sink pad link: 'audio_0066' > D/GStreamer+tsdemux(16393): 0:00:05.832146503 0x9e236660 > tsdemux.c:1599:activate_pad_for_stream:<demux:audio_0066> done adding > pad That's still not very useful unfortunately. Can you show your code, and if it's still like last time please only try linking the pads once and then just print the return value of gst_pad_link(). Feel free to print it as an integer too instead of having all the if-else cases there. However your code should really print a lot of debug output because of the 7 links it should be doing before printing the "link refused" message. Also unrelated to all this, use queue and not queue2 in your pipeline. queue2 is mostly for network buffering, not thread decoupling :) -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Thanks for your answer, these are the changes I have done to the
code:
static void dynamic_addpad(GstElement *src, GstPad *new_pad, CustomData *data) { char* pad_name = gst_pad_get_name(new_pad); g_print(" In dynamic ADDING PAD %s\n", pad_name); if (g_str_has_prefix(pad_name,"audio")) { GstElement *q_audio;// = (GstElement *)data->queue_audio; q_audio = gst_bin_get_by_name (GST_BIN(data->pipeline), "queue_audio"); GstPad *audiodemuxsink = gst_element_get_static_pad(q_audio,"sink"); GstPadLinkReturn ret = gst_pad_link(new_pad, audiodemuxsink); g_print("'%s' dynamic link returns: %d\n", pad_name, (int) ret); gst_object_unref(q_audio); } else if (g_str_has_prefix(pad_name,"video")) { GstElement *q_video;// = (GstElement *) data->queue_video; q_video = gst_bin_get_by_name(GST_BIN(data->pipeline), "queue_video"); GstPad *videodemuxsink = gst_element_get_static_pad(q_video,"sink"); GstPadLinkReturn ret = gst_pad_link(new_pad,videodemuxsink); g_print("'%s' dynamic link returns: %d\n", pad_name, (int) ret); gst_object_unref(q_video); } } The full debug has been uploaded to this link: https://www.dropbox.com/s/bujeg6sc4381dtr/logcat060620160943.txt?dl=0 If it may have to do something with this issue, I am using ubuntu 14.04 64b, Android Studio 1.5.1 (December 1st 2015 built) and ndk r10e-rc4 (64-bit). The gradle version is 2.8 and the android plugin version is 1.5.0. Thanks for your time, Dani El 03/06/16 a las 07:47, Sebastian Dröge escribió:
On Di, 2016-05-31 at 10:30 +0200, Dani wrote:I/GLib+stdout(16393): In dynamic ADDING PAD audio_0066 I/GLib+stdout(16393): //////////-6////////// I/GLib+stdout(16393): Audio link refused! I/GLib+stdout(16393): Sink pad link: 'audio_0066' D/GStreamer+tsdemux(16393): 0:00:05.832146503 0x9e236660 tsdemux.c:1599:activate_pad_for_stream:<demux:audio_0066> done adding padThat's still not very useful unfortunately. Can you show your code, and if it's still like last time please only try linking the pads once and then just print the return value of gst_pad_link(). Feel free to print it as an integer too instead of having all the if-else cases there. However your code should really print a lot of debug output because of the 7 links it should be doing before printing the "link refused" message. Also unrelated to all this, use queue and not queue2 in your pipeline. queue2 is mostly for network buffering, not thread decoupling :)_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: changing souphttpsrc location property on android
|
|
On Mo, 2016-06-06 at 10:06 +0200, Dani wrote:
> Thanks for your answer, these are the changes I have done to the > code: > [...] > The full debug has been uploaded to this link: > https://www.dropbox.com/s/bujeg6sc4381dtr/logcat060620160943.txt?dl=0 > If it may have to do something with this issue, I am using ubuntu > 14.04 64b, Android Studio 1.5.1 (December 1st 2015 built) and ndk > r10e-rc4 (64-bit). The gradle version is 2.8 and the android plugin > version is 1.5.0. Thanks for your time, Dani Try using a stable GStreamer version, 1.6.x or 1.8.x for example. The log still does not contain anything meaningful, but the only way how this can fail like this if either one of the two pads is NULL or the first is not a source pad, or the second is not a sink pad. Please check if you have two valid pad pointers there. If that all does not help, please try to write a minimal testcase for this problem so someone can reproduce it. Ideally a command line application that also runs outside Android. -- Sebastian Dröge, Centricular Ltd · http://www.centricular.com _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Dani MR
I have been able to solve this problem by changing this instruction:
For this one, slightly different (no &):g_signal_connect (data->demux, "pad-added", G_CALLBACK (dynamic_addpad), &data); This way the manual pipeline works perfectly!g_signal_connect (data->demux, "pad-added", G_CALLBACK (dynamic_addpad), data); Regards, Dani El 06/06/16 a las 10:06, Dani escribió:
Thanks for your answer, these are the changes I have done to the code: _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |