GNOME Bugzilla – Bug 757642
compositor: some documentation is obsolete
Last modified: 2016-05-22 17:41:04 UTC
gstaggregator.c - the following seems to be not true anymore (3 start modes are now supported): * When data is queued on all pads, tha aggregate vmethod is called. gstvideoaggregator.c - the following depends on what the derived classes do : * VideoAggregator can accept AYUV, ARGB and BGRA video streams. For each of the requested * sink pads it will compare the incoming geometry and framerate to define the * output parameters. Indeed output video frames will have the geometry of the * biggest incoming video stream and the framerate of the fastest incoming one. compositor.c - more formats are handled : * Compositor can accept AYUV, ARGB and BGRA video streams. For each of the requested * sink pads it will compare the incoming geometry and framerate to define the * output parameters. Indeed output video frames will have the geometry of the * biggest incoming video stream and the framerate of the fastest incoming one.
> gstaggregator.c - the following seems to be not true anymore (3 start modes > are now supported): > > * When data is queued on all pads, tha aggregate vmethod is called. I believe the 'start modes' don't influence when the aggregate vmethod is called, just the timestamping of the output data. The doc comment is not entirely true though because it will also be called when there is not data on all pads, if timeout-based operation is in use in live mode (but this only happens if the subclass does other things too).
Philippe, could you make a patch for the docs as you think they should be?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!