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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from Thibault Saunier <tsaunier at gnome.org> ---
Thanks Arun for the review!

(In reply to Arun Raghavan from comment #12)
> Took a quick look -- thanks, I think this is API we need.
> 
> 1. We have gst_transcoder_run() and gst_transcoder_run_async(), and it seems
> to me like users of the API might desire more control. Would it make sense
> to either:
> 
>   a. Add a cancellable to the async API
>
>   b. Rethink the API in terms of start/pause/cancel, and have it always be
> async

It is the API I have in mind but kept it very simple, will add .pause() and
.cancel().

The run () API is really a very high level helper for user writing scripts etc
so you can just do Gst.Transcoder(input, output, format).run(), the goal is to
be very high level and simple to use thus this API, I have the feeling it is
nice to have.

>    I have a preference for the latter as it is a bit closer to how pipelines
> work, anyway, and it's trivial for application to build sync mechanisms on
> top of it if they need it.

Right, this is what we have/want indeed.

> 2. If the async mechanism is what we go with, then the position update at
> whatever intervals can probably just go, and we can leave that to clients too

No, I want to have an API very similar to GstPlayer which is why I have that,
and if you look at the rest of the API, it is very very similar.

> 3. Shouldn't avoid re-encoding be on by default?

Well, I did what encodebin does, not sure, we can bikeshed on IRC about that :)

> 4. (Bikeshed) 'dest', where it occur in the API, should be 'destination' --
> I think it's better to not shorten these unless it really blows up the name
> length

Hrm, no idea, please others tell me what you prefer :)

> 5. (Bikeshed) Why do you have gst-libs/gst/transcoding/transcoder? Do you
> expect other work to turn up under the transcoding directory?

Yes, the whole API has the goal of enabling a client/server distributed
encoding/transcoding capabilities, and this is the first part which is
basically the basis of a client.

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