GNOME Bugzilla – Bug 739581
basetransform: First query downstream before answering the query position
Last modified: 2014-11-06 11:20:01 UTC
Currently basetransform gives its current position right away. When upstream elements query position, by default it should let the sink answer the current position, and if there is a problem doing that, answer the query itself.
Created attachment 289922 [details] [review] basetransform: First query downstream before answering the query position
Review of attachment 289922 [details] [review]: Not sure this is correct, the upstream/downstream position might be different to the position inside basesink. ::: libs/gst/base/gstbasetransform.c @@ +1497,3 @@ gst_query_parse_position (query, &format, NULL); + ret = gst_pad_peer_query (otherpad, query); + if (ret == FALSE && format == GST_FORMAT_TIME Don't compare booleans by equality. if (!ret && ...)
(In reply to comment #2) > Review of attachment 289922 [details] [review]: > > Not sure this is correct, the upstream/downstream position might be different > to the position inside basesink. FMPOV when an upstream element send a downstream POSITION query what should be return is the position at the end of the pipeline by default, not the position of some random element is. That is what that patch is about. > ::: libs/gst/base/gstbasetransform.c > @@ +1497,3 @@ > gst_query_parse_position (query, &format, NULL); > + ret = gst_pad_peer_query (otherpad, query); > + if (ret == FALSE && format == GST_FORMAT_TIME > > Don't compare booleans by equality. if (!ret && ...) FALSE being #define FALSE 0 that is the exact same thing, anyway, doing that.
Created attachment 289972 [details] [review] basetransform: First query downstream before answering the query position Currently basetransform gives its current position right away. When upstream elements query position, by default it should let the sink answer the current position, and if there is a problem doing that, answer the query itself.
Should this become RESOLVED/NOTABUG according to our discussion on IRC?
Yes, closing it, the current behaviour is the expected one.