GNOME Bugzilla – Bug 759126
appsrc: issues with duration query handling
Last modified: 2015-12-08 10:47:38 UTC
So I think roughtly this pipeline appsrc ! qtdemux ! appsink. Wen playing a fragmented file, qtdemux is able to parse a duration value from the mehd box but a duration query to the qtdemux src pad will first be forwarded to appsrc (and basesrc) which will handle it: 0:00:02.407216510 1923 0x904bc0 DEBUG query gstquery.c:674:gst_query_new_custom: creating new query 0xbfb980 duration 0:00:02.407282603 1923 0x904bc0 DEBUG GST_ELEMENT_PADS gstelement.c:1679:gst_element_query: send query on element qtdemux0 0:00:02.407327603 1923 0x904bc0 DEBUG GST_ELEMENT_PADS gstelement.c:1465:gst_element_get_random_pad: getting a random pad 0:00:02.407317603 1923 0xb44180 DEBUG basesink gstbasesink.c:2535:gst_base_sink_do_sync:<appsink0> reset rc_time to time 0:00:00.041666666 0:00:02.407365051 1923 0x904bc0 DEBUG GST_ELEMENT_PADS gstelement.c:1484:gst_element_get_random_pad: checking pad qtdemux0:video_0 0:00:02.407433020 1923 0x904bc0 DEBUG GST_ELEMENT_PADS gstelement.c:1496:gst_element_get_random_pad: found pad qtdemux0:video_0 0:00:02.407410416 1923 0xb44180 DEBUG basesink gstbasesink.c:2547:gst_base_sink_do_sync:<appsink0> possibly waiting for clock to reach 0:00:00.041666666, adjusted 0:00:00.041666666 0:00:02.407489218 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3880:gst_pad_query:<qtdemux0:video_0> doing query 0xbfb980 (duration) 0:00:02.407532031 1923 0xb44180 DEBUG basesink gstbasesink.c:2175:gst_base_sink_wait_clock:<appsink0> sync disabled 0:00:02.407572135 1923 0x904bc0 LOG qtdemux qtdemux.c:873:gst_qtdemux_handle_src_query:<qtdemux0:video_0> duration query 0:00:02.407599010 1923 0xb44180 DEBUG basesink gstbasesink.c:2554:gst_base_sink_do_sync:<appsink0> clock returned 4, jitter 0:00:00.000000000 0:00:02.407622291 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3337:gst_pad_query_default:<qtdemux0:video_0> forwarding 0xbfb980 (duration) query 0:00:02.407665676 1923 0xb44180 DEBUG basesink gstbasesink.c:3520:gst_base_sink_chain_unlocked:<appsink0> rendering object 0x6e91f228 0:00:02.407713801 1923 0xb44180 DEBUG basesink gstbasesink.c:946:gst_base_sink_set_last_buffer_unlocked:<appsink0> setting last buffer to 0x6e91f228 0:00:02.407725468 1923 0x904bc0 DEBUG GST_PADS gstpad.c:2801:gst_pad_iterate_internal_links_default:<qtdemux0:video_0> Making iterator 0:00:02.407766770 1923 0xb44180 DEBUG appsink gstappsink.c:734:gst_app_sink_render:<appsink0> pushing render buffer 0x6e91f228 on queue (0) 0:00:02.407808020 1923 0x904bc0 DEBUG GST_PADS gstpad.c:4007:gst_pad_peer_query:<qtdemux0:sink> peer query 0xbfb980 (duration) 0:00:02.407841510 1923 0xb44180 DEBUG appsink gstappsink.c:1207:gst_app_sink_pull_sample:<appsink0> trying to grab a buffer 0:00:02.407862291 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3880:gst_pad_query:<typefindelement0:src> doing query 0xbfb980 (duration) 0:00:02.407885781 1923 0xb44180 DEBUG appsink gstappsink.c:680:dequeue_buffer:<appsink0> dequeued buffer 0x6e91f228 0:00:02.407914478 1923 0x904bc0 DEBUG typefind gsttypefindelement.c:365:gst_type_find_handle_src_query:<typefindelement0> Handling src query duration 0:00:02.407968072 1923 0xb44180 DEBUG appsink gstappsink.c:1222:gst_app_sink_pull_sample:<appsink0> we have a buffer 0x6e91f228 0:00:02.408026770 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3337:gst_pad_query_default:<typefindelement0:src> forwarding 0xbfb980 (duration) query 0:00:02.408084114 1923 0x904bc0 DEBUG GST_PADS gstpad.c:2801:gst_pad_iterate_internal_links_default:<typefindelement0:src> Making iterator 0:00:02.408130520 1923 0x904bc0 DEBUG GST_PADS gstpad.c:4007:gst_pad_peer_query:<typefindelement0:sink> peer query 0xbfb980 (duration) 0:00:02.408181249 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3880:gst_pad_query:<appsrc0:src> doing query 0xbfb980 (duration) 0:00:02.408284791 1923 0x904bc0 DEBUG basesrc gstbasesrc.c:1054:gst_base_src_default_query:<appsrc0> duration query in format time 0:00:02.408335468 1923 0x904bc0 DEBUG basesrc gstbasesrc.c:2350:gst_base_src_update_length:<appsrc0> reading offset 0, length 0, size -1, segment.stop -1, maxsize -1 0:00:02.408439531 1923 0x904bc0 DEBUG basesrc gstbasesrc.c:1291:gst_base_src_default_query:<appsrc0> query duration returns 1 0:00:02.408492499 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3903:gst_pad_query:<appsrc0:src> sent query 0xbfb980 (duration), result 1 0:00:02.408550260 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3903:gst_pad_query:<typefindelement0:src> sent query 0xbfb980 (duration), result 1 0:00:02.408604895 1923 0x904bc0 DEBUG GST_PADS gstpad.c:3903:gst_pad_query:<qtdemux0:video_0> sent query 0xbfb980 (duration), result 1 But basesrc returns GST_CLOCK_TIME_NONE. And qtdemux ends up using this as well even though it parsed the duration already.
Created attachment 316885 [details] [review] patch
Comment on attachment 316885 [details] [review] patch The correct fix would be in appsrc. It should not report a useless duration :)
appsrc doesn't have any specific duration query handling, should I add that there? Also, basesrc deliberately returns TRUE if the duration is unknown: http://cgit.freedesktop.org/gstreamer/gstreamer/tree/libs/gst/base/gstbasesrc.c#n1088
appsrc should probably implement handling of the DURATION query then, yes. Basically the same handling that filesrc implements, based on the size property.
Created attachment 316920 [details] [review] appsrc patch
Review of attachment 316920 [details] [review]: ::: gst-libs/gst/app/gstappsrc.c @@ +932,3 @@ + gst_query_parse_duration (query, &format, NULL); + if (format == priv->format) { + gst_query_set_duration (query, format, priv->size); size is always in bytes, there is no API currently to provide a duration in a different format unfortunately.
Oh right, I need more coffee :)
Created attachment 316921 [details] [review] updated appsrc patch
commit 872f40d7d961c8799ca9ff2529c37ec9cb76d65a Author: Philippe Normand <philn@igalia.com> Date: Tue Dec 8 11:15:34 2015 +0100 appsrc: duration query support based on the size property https://bugzilla.gnome.org/show_bug.cgi?id=759126
Thanks!