[Bug 757684] Implement an high level transcoding API (similar to GstPlayer but for transcoding)

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Fri Mar 23 14:56:27 UTC 2018


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

--- Comment #27 from Thibault Saunier <tsaunier at gnome.org> ---
(In reply to Olivier CrĂȘte from comment #26)
> The .new() method should probably be failable or do you fail on .run() if
> the profile is invalid (or not deserializable?).

The _new() will return NULL, it is indeed not ideal and not binding friendly,
should I make it a GInitable? Optionally I can make it fail in run() instead?

> I must say I quite like the
> simplicity of the current API. One extra feature I'd like is some API to add
> filters for simple operations, things like cropping, scaling, boxing, etc.
> Also some API to change start/end/duration of the result, for very basic
> editing. But I think those could be added to the current base.

There is already APIs for that using the `transcodebin::video_filter` and
`transcodebin::audio_filter` properties (in Pitivi we use that to generate
thumbnail cache while transcoding proxy assets), adding higher level APIs for
that in `GstTranscoder` itself is definitely doable too.

> transcodebin also missed a subtitles filter (for compleness).

Indeed, that is not handled yet, nothing refraining us to add it.

> Also not convinced about the whole dispatcher thing, feels very complicated..

My goal was to be exactly symmetric with the GstPlayer API (which is nice to
use as end users FMPOV). Now, as stated by Tim, I should make sure to follow
GstPlayer API changes this cycle.

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


More information about the gstreamer-bugs mailing list