[Bug 759192] start gstreamer-vaapi "upstream-ization"

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759192

--- Comment #21 from Víctor Manuel Jáquez Leal <vjaquez at igalia.com> ---
In an act of boldness I decide to move this commit to the new gstreamer-vaapi
component in GStreamer o/ 

(In reply to Tim-Philipp Müller from comment #17)
> > I'm emerging from the autotool's dungeons, and I would like to
> > think that I came out victorious (that's my name ;))
> 
> :D (You may have won the battle, but will you win the war? ;))

We're all doomed!! XD

> Ok, let me know when it's ok to push.

Yeah, just realized that is broken with gst1.6, because there's no vp9 parser.
I just need to bring back the vp9 parser check in configure.ac.

> Just on a side note, re. the commit message, the reason we have our own
> gtk-doc thingy is not because gtk-doc is no longer maintained, but because
> we need to do some very GStreamer-specific things there (gtk-doc is made for
> stuff that has public API, which our plugins don't have).

Yes, I know that, but I guess I failed at my wording in the commit message.
I'll fix that.

> > In the gtk-doc generation I found an issue: because the encoders name have
> > the pattern vaapiencode_{codec} the documentation of the vaapi plugin can
> > link those pages because it assumes that the _ is changed to -
> > 
> > Anyway, it is a minor issue which we could track later. Perhaps we should
> > rename the encoders to follow the common pattern in gstreamer.
> 
> I think the common pattern would be something like vaapih264dec /
> vaapih264enc or vah264dec / vah264enc or such?

I'd vote for vaapi{codec}enc

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.