[vlc-devel] Re: Question about video filters - svg rendering
oaubert at bat710.univ-lyon1.fr
Tue Jan 25 14:55:50 CET 2005
> I just saw this question was still unanswered, and since i personally
> like SVG a bit, i though i'd answer it anyway and ask if you have made
> some progress.
Thanks for the answer. I did not progress on the SVG side for the
moment, waiting for some feedback. I think that I will commit the
current state of my updates to vlc-trunk, as I seem to be the only one
using it anyway, so it will not break existing stuff. At least it will
get some exposure.
> Why is this stored in a GdkPixBuf?
> seems kinda unnecessary to me. only makes it depend on GDK. can't it be
> copied directly into a picture_t ?
Because the librsvg library that I use for rendering only produces
GdkPixbuf data. I can store it in a new picture_t anyway, after the
> Our core can only handle YUVP or YUVA blending. so your model needs to
> output a picture in this format. these chroma formats are really quite simple,
> they just have an alpha plane next to the YUV planes.
Yes, in the 0.7 (working) version of the SVG plugin, I did the
conversion myself, so the code is here. But it is in no way optimized.
Aren't there any optimized conversion routines that could be reused (and
how can I use them) ?
> > - Is there any way for the filter_t* object to access the associated
> > video_output_t properties ? I need the width and height of the
> > video_output, as parameters for SVG rendering (and having matching
> > dimensions should speed the merging process).
> It's not easily posible i think, but gibalou/Gildas probably knows.
It would be really great to have the whole pipeline
(access/demux/video_filter/video_output) exposed and accessible, so that
we can get this kind of information.
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
More information about the vlc-devel