[gst-devel] [gst-cvs] mnauw gst-plugins-base: gst-plugins-base/ gst-plugins-base/gst-libs/gst/video/

Mark Nauwelaerts manauw at skynet.be
Tue Jul 15 11:12:13 CEST 2008



David Schleef wrote:
> On Mon, Jul 14, 2008 at 10:06:40AM -0700, mnauw at kemper.freedesktop.org wrote:
>> CVS Root:       /cvs/gstreamer
>> Module:         gst-plugins-base
>> Changes by:     mnauw
>> Date:           Mon Jul 14 2008  17:06:40 UTC
>>
>> Log message:
>> * gst-libs/gst/video/video.c: (gst_video_format_parse_caps):
>> Video format can also be conveniently determined from (many)
>> non-fixed caps.
> 
> This change is wrong.  Please revert it.  The GstVideoFormat code
> is meant to deal with fully described video formats only.

It may be meant to deal with fully described formats only,
nevertheless the same code can perfectly determine a GstVideoFormat based on 
caps' fourcc code, rgb masks etc without having a fixed width and height
(and the fact that one could pass NULL width and height output parameters if one 
is not interested in it was already the case; I just happened to document that 
it was so).

> 
> Also, it changes ABI.

It might change API in that it would now return TRUE for a non-fixed caps.
However, typical use now calls it with non-NULL width and height anyway, so it 
might be changed to still return FALSE in that case while allowing non-fixed 
caps if passed with NULL width and height output parameters.

If not finding that a solution, what would then be an acceptable way to re-use 
exactly the same code to determine format for a non-fixed width, height etc 
(which is irrelevant in the format determination) ?  Add some other API function 
(_full/_non_fixed ?) that internally calls upon the same (slightly re-factored) 
code.  After all, it's nice code, so let's use it as much as possible :)

Mark.





More information about the gstreamer-devel mailing list