From: Marco B. <gib...@gm...> - 2010-11-22 21:58:46
|
Hi, On Tue, Nov 16, 2010 at 5:19 PM, 4ernov <4e...@gm...> wrote: > Hello, > > I continue working at some complex pipeline which I wrote about > previously ("Problems with video, tee and queues"). Solution proposed > by Marco works just fine for the pipeline I noticed there: > > queue -- xvimagesink > / > playbin -- tee > \ > queue -- fakesink > > converted dynamically to: > > queue -- xvimagesink > / > playbin -- tee > \ > queue -- xvimagesink > > But the final destination of my experiments is the following case: > > > queue -- xvimagesink > / > playbin -- tee > \ > queue -- fakesink > > converted dynamically to: > > queue -- xvimagesink > / > playbin -- tee > \ > queue -- gdppay -- filesink > > with remote end like this: > > filesrc -- gdpdepay -- decodebin -- ffmpegcolorspace -- xvimagesink > > And for this case it doesn't work. > > Well, what is the result for now: > 1. Everything works fine if the final pipeline is hardcoded from the > beginning (i.e. we have gdppay right from start). > 2. Everything works fine without gdppay (with xvimagesink or smth. instead). > > But when I start the desired configuration I have the following: > 1. Xv window of the remote end appears and stalls the playing but > start to refresh slowly (several frames are shown rapidly in intervals > of 4-5 secs) Are you transferring this somehow over a network? Using gdppay and filesink/filesource for this is not really an optimal setup. Maybe you could have better luck with (de)payloaders and udp elements + jitter buffer. > 2. Xv window of the main pipeline stops to play properly, too, and > behaves just the same way like the remote one. > 3. The main pipeline prints the following warnings to console: > > 0:00:07.134552825 19490 0x95be9c8 WARN gdppay > gstgdppay.c:594:gst_gdp_pay_chain:<gdppay0> did not receive > new-segment before first buffer > 0:00:14.095700940 19490 0x948d2b0 WARN ffmpeg > gstffmpegdec.c:2002:gst_ffmpegdec_video_frame:<ffdec_h2640> Dropping > non-keyframe (seek/init) > 0:00:14.691007420 19490 0x95b4978 WARN basesink > gstbasesink.c:2686:gst_base_sink_is_too_late:<xvimagesink0> warning: A > lot of buffers are being dropped. > 0:00:14.691055331 19490 0x95b4978 WARN basesink > gstbasesink.c:2686:gst_base_sink_is_too_late:<xvimagesink0> warning: > There may be a timestamping problem, or this computer is too slow. This message is pretty self-explanatory: xvimagesink is not rendering anything because buffers are too late. Just to try, what's the effect if you set sync=false on that element? What if you set the max-lateness property to something like e.g. a few seconds? Regards > > Here's the source code of the main app: > > #include <gst/gst.h> > #include <glib.h> > > GstElement *_pipeline, *_fakesink, *_remotesink, *_valve, *_mpoint, > *_videobin, *_pipe; > > void create_pipeline_bin() > { > GstElement *tee, *queue1, *queue2, *xvimagesink; > > _pipeline = gst_element_factory_make("playbin", NULL); > > tee = gst_element_factory_make("tee", NULL); > xvimagesink = gst_element_factory_make("xvimagesink", NULL); > > GstPad* pad; > > _videobin = gst_bin_new("videobin"); > queue1 = gst_element_factory_make("queue", NULL); > queue2 = gst_element_factory_make("queue", NULL); > _valve = gst_element_factory_make("valve", NULL); > > _fakesink = gst_element_factory_make("fakesink", NULL); > > gst_object_ref(_fakesink); > > _mpoint = _valve; > > gst_bin_add_many(GST_BIN(_videobin), tee, queue1, queue2, _valve, > xvimagesink, _fakesink, NULL); > > gst_element_link_many(tee, queue1, xvimagesink, NULL); > gst_element_link_many(tee, queue2, _valve, _fakesink, NULL); > pad = gst_element_get_static_pad (tee, "sink"); > gst_element_add_pad (_videobin, gst_ghost_pad_new ("sink", pad)); > gst_object_unref (GST_OBJECT (pad)); > > g_object_set(G_OBJECT (_pipeline), "uri", "file:///home/alex/test.mkv", NULL); > g_object_set(G_OBJECT (_pipeline), "video-sink", _videobin, NULL); > g_object_set(G_OBJECT (_pipeline), "audio-sink", NULL, NULL); > > gst_element_set_state (_pipeline, GST_STATE_PLAYING); > } > > void create_remote_bin() > { > GstElement *gdppay; > GstPad* pad; > > gdppay = gst_element_factory_make("gdppay", NULL); > _pipe = gst_element_factory_make("filesink", NULL); > > g_object_set(G_OBJECT (_pipe), "location", > "/home/alex/work/playground/test.gdp", NULL); > > _remotesink = gst_bin_new("gdpbin"); > gst_bin_add_many(GST_BIN(_remotesink), gdppay, _pipe, NULL); > gst_element_link_many(gdppay, _pipe, NULL); > > pad = gst_element_get_static_pad (gdppay, "sink"); > gst_element_add_pad (_remotesink, gst_ghost_pad_new ("sink", pad)); > gst_object_unref (GST_OBJECT (pad)); > } > > void connect_remote_client() > { > if (_remotesink && _mpoint && _videobin) > { > g_object_set(G_OBJECT (_valve), "drop", TRUE, NULL); > > gst_element_unlink(_mpoint, _fakesink); > gst_bin_remove(GST_BIN(_videobin), _fakesink); > gst_element_set_state (_fakesink, GST_STATE_NULL); > > gst_bin_add(GST_BIN(_videobin), _remotesink); > gst_element_link(_mpoint, _remotesink); > > gst_element_sync_state_with_parent(_remotesink); > > gst_element_set_state (_pipeline, GST_STATE_PLAYING); > g_object_set(G_OBJECT (_valve), "drop", FALSE, NULL); > } > } > > gboolean connect_callback(gpointer) > { > connect_remote_client(); > return FALSE; > } > > int main(int argc, char *argv[]) > { > gst_init(&argc, &argv); > > gst_debug_set_active(true); > gst_debug_set_default_threshold(GST_LEVEL_WARNING); > > create_remote_bin(); > create_pipeline_bin(); > > g_timeout_add(7000, connect_callback, NULL); > > GMainLoop *loop; > > loop = g_main_loop_new (NULL, FALSE); > > g_print ("Running...\n"); > g_main_loop_run (loop); > > return 0; > } > > End on the remote end there's gst-launch command: > > gst-launch -v filesrc location=/home/alex/work/playground/test.gdp ! > gdpdepay ! decodebin ! ffmpegcolorspace ! xvimagesink > > What is the essential problem? Is it possible to keep the "main" > branch (i.e. with xvimagesink in main pipeline) playing while the > second establishes connection via GDP protocol and then keep them > synced? I hoped on valve element very much and it works perfectly for > a couple xvimagesink but with GDP element it doesn't work, everything > is almost stalled. > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > gstreamer-devel mailing list > gst...@li... > https://lists.sourceforge.net/lists/listinfo/gstreamer-devel > |