[Bug 667352] [0.11] misc core API/bug comments/nitpicks

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=667352
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #11 from Wim Taymans <wim.taymans at gmail.com> 2012-03-28 08:37:38 UTC ---
(In reply to comment #9)
> 
> If by "accepting crop metadata", this means that downstream should be peeking
> into allocation query flying by, examining it for allocation meta apis and then
> chucking out the ones it does not like/know about, then that seems a bit
> orthogonal to the supposed extensibility of such apis (as in; future ones
> currently unknown).

That is how it should be done if you proxy the allocation query but need to
deal with the data in the buffers somehow. You remove all the metadata that you
don't know or that becomes invalid based on the transform you do (using the
tags).

> 
> That being as it may, it seems in practice all a typical element/code would
> care about is that it can still/always rely upon the outcome of
> gst_video_frame_map and all the GST_VIDEO_FRAME_WIDTH etc stuff.  In
> particular, one would expect this to correspond to caps specs (or not?) (so
> specified/documented currently?).  And it does not look like e.g. crop metadata
> would have this working out well unless there is then at least also video meta
> to arrange for that.

The crop metadata needs to be handled separately, the video frame API will not
automatically crop (and it can't accurately).  

> 
> So if the ground rule for all the meta apis is "video frame mapping must work
> out properly", then fine by me, though (as said) this requires quite some
> implementation caution.  And some ambiguity arises, e.g. if upstream decoder
> decides to use crop api but "forgets" to enable the video meta buffer pool
> option, how will that work out ...  Or should it also know never to use crop
> api if video meta is not supported etc

If you use the crop metadata on raw video, you also need to have the video
metadata enabled because else you can't specify the dimensions of the bigger
uncropped image. 

The reason that the crop metadata is there is because we might want to add it
to non-raw formats.

> 
> --
> 
> On an unrelated topic, it looks like e.g. gst_buffer_join does not "simply"
> provide a buffer that has all the GstMemory's of the original buffers but has
> performed (unless in rare cases) a memcpy of all involved.  This is not what
> one would expect/hope from something so named (with all the GstMemory these
> days).  Naming aside, a (helper) function doing such seems pretty
> useful/needed, particularly since "regular buffers" (and the memory blocks)
> should be able to function as old-style buffer_list (group), as indicated in
> porting docs.

Indeed, I'll look at this.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.