[gst-devel] The 1.0 plan

[wally_bkg]

Wim Taymans wrote:
> 
> 
> One of the big missing items on this list is improving the documentation. 
> 
> 

Understatement of the year!

The replies to this message alone are proof that information about the
"proper" way to do things is sorely lacking.


IMHO one of the worst parts of gstreamer is the v4l2src stuff, particularly
selecting the proper video norms (seems about half the world will have video
cards that default on power up to the wrong standard) and selecting the
proper input.  Is there even a way to do it via gst-launch?


I also think the best documentation is a working sample code, with decent
comments.  The only way I could figure out how to interpret video data
pixels in a buffer (either as a plugin or appsink) was to stumble around the
source code for gstgamma and gstvideoscale.  

Of course the data you get in a buffer depends on the caps, but am I the
only one who thinks there has to be a better way than:

    GstStructure *structure;
    gint width,height;

    // this seems rather ridiculous as a way to get info about interpreting
the buffer, 
    // but after inspecting gstvudeoscale.c appears to be what the gst
designers intended :(
    data = GST_BUFFER_DATA (buf);
    size = GST_BUFFER_SIZE (buf);
    structure = gst_caps_get_structure (gst_buffer_get_caps(buf), 0);
    gst_structure_get_int (structure, "width", &width);
    gst_structure_get_int (structure, "height", &height);

So I guess this comment just degenerates into another vote for having
metadata in the buffers.  OTOH I'd not be surprised if there is a better way
that is undocumented and buried somewhere in the source tree I've not
stumbled on to.





-- 
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/The-1-0-plan-tp3033660p3071403.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.