[gstreamer-bugs] [Bug 631574] Add GstFilters library to gst-plugins-base

Tue Dec 21 15:56:00 PST 2010

https://bugzilla.gnome.org/show_bug.cgi?id=631574
  GStreamer | gst-plugins-base | git

--- Comment #12 from Youness Alaoui <youness.alaoui at collabora.co.uk> 2010-12-21 23:55:56 UTC ---
(In reply to comment #10)
> > > - GstResolutionFilter should also have something to specify the PAR/DAR or to
> > > force keeping the DAR and things like that. And the name could be improved I
> > > guess... but I don't know a good name
> > That's a good point, The aspect ratio should be configurable, I'm not sure if
> > it needs to be anything fancy, maybe just 'stretch/keep_aspect_ratio' is
> > enough.
> 
> Maybe just expose the add-black-borders property of videoscale and maybe four
> ints to give a PAR range
Humm... I tried the add-borders property, it doesn't work when using v4l2src
because it seems the pixel-aspect-ratio is set to 1/2147483647 from the output
of v4l2src :
DEBUG             videoscale
gstvideoscale.c:437:gst_video_scale_set_caps:<videoscale0> from=1280x960
(par=1/2147483647 dar=-1/-1), size 2457600 -> to=270x821 (par=1/1 dar=270/821
borders=0:0), size 443340

I made it work by adding a capsfilter before the videoscale forcing the
pixel-aspect-ratio to 3/4 but I don't think I should hardcode the aspect ratio
in the filter.
Any suggestions? Maybe videoscale should fallback to an aspect ratio of
height/width when it can't compute the DAR ?

> 
> > About the name, I don't know, maybe GstVideoSizeFilter ?
> 
> Sounds better :)
ok cool, I'll change it to VideoSizeFilter then :)

> 
> > > - GstFilter::handle_message(): please add to the documentation *which* messages
> > > will be passed to this. Is this only for gst_filter_manager_handle_message()?
> > > If it is, what exactly is the use case for this? An example in the
> > > documentation would help I guess :)
> > 
> > Well, the documentation says "Try to handle a message originally received on
> > the GstBus to the filter." and really, it's *ANY* and *ALL* messages that goes
> > through the bus.. the filter will return TRUE/FALSE depending on whether or not
> > it recognizes the message. Most filters don't need it and will always return
> > FALSE, others will look for a specific message (like the 'level' filter that
> > takes 'level' messages and transforms them into gobject signals) but you can't
> > [...]
> >
> > Does that answer your question or did I misunderstand it ?
> 
> No, makes sense. But maybe multiple filters want to get a single message?
Usually filters will only handle messages coming from the elements they added
themselves, so I don't think two filters would want to handle the same
message.. if a filter handles a message it doesn't "own", then it shouldn't
return TRUE, since the return value isn't whether or not it handled it, it's
whether or not it should be dropped.

> 
> > (In reply to comment #8)
> > 
> > Humm, the whole timing/synchronization/segment/latency/QoS stuff in gstreamer
> > is my weak point, I'm having a bit of a hard time getting my mind around it.
> > I'm a bit clueless as to why this is needed, or how to do it properly, could
> > you enlighten me?
> > If you have a solution that I can just apply, I can fix it, but figuring out
> > what needs to be done is giving me a headache...
> 
> Essentially you need to install buffer and event probes on sinkpad, catch
> newsegment events and buffer timestamps/durations. And then you'll be able to
> calculate the current running time when changing elements during playback. And
> to tell a new element about the old running time you have to send a newsegment
> event to it before anything else happens (and important: drop it on the other
> side of the element).

ok, so keep track of the new segments with the running time, then inject it
when applying new filters, then drop it at the src side of the filter. I'll try
to do that.

(In reply to comment #11)
> (In reply to comment #10)
> > 
> > Unfortunately I don't know a better name, sorry :) Someone else?
> 
> why not just gst_filter_add_element () or gst_filter_add_element_default ().
> Imho describing the difference in the API docs is enough.
> 
gst_filter_add_element_default makes more sense, but somehow, I don't feel like
it's good enough.. 
Maybe I could change the way we do it, and do the invert... make
add_element_by_name use "src"/"sink" and have a add_element_by_name_custom_pads
(or whatever better name) for the one where you specify the pad names?

> It would be nice to have a small example in the section docs for the helpers.
> The purpose of the _revert_ functions is not totally clear to me (or the naming
> is a bit unlucky).

yes, the gtk-doc definitely needs a more 'gstreamer documentation quality' to
it, as in, more text, a long descriptive/narrative documentation with examples.
The "revert" is the opposite of 'apply', it reverts the filter application from
a bin+pad. I think Olivier and I spent some time trying to find the right name
for this, and revert was the best we could find.

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