[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 #9 from Mark Nauwelaerts <mnauw at users.sourceforge.net> 2012-03-27 17:09:46 UTC ---
(In reply to comment #8)
> (In reply to comment #6)
> > * crop metadata vs caps:
> > it looks like the caps width/height should reflect the image's total
> > width/height, and not the cropped width/height (presumably so an element not
> > having such crop meta support can carry on as usual).  If indeed so, maybe
> > having this specified/documented somewhere?
> 
> The caps should reflect what the user visible region is, so _after_ cropping.
> The idea is that a capsfilter still affects the visual result. An element can
> only send a crop metadata if downstream understands, that means all the
> downstream elements should understand (and explicitly enable) the crop
> metadata. If downstream does not accept the crop metadata, the upstream element
> should do
> software cropping (which might not be very accurate).

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 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.

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

--

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.

-- 
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.