[gstreamer-bugs] [Bug 627476] New profile library and encoding plugin

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #24 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-12-11 13:34:39 UTC ---
> >  [GstMiniObject vs. GObject]
> 
>   Seems a bit overkill for such dumb structures that don't *do* anything. They
> are just containers of information. Having the refcounting is the nice bonus
> (which gstminiobject gives), but having 'heavy' GProperties for them seems a
> bit overkill, no ?

Maybe. Both work for me. Just thought full objects would give us floating refs
in addition, and make things easier for bindings (basically constructors =
g_object_newv()). No strong opinion either way.


> >  - what's the reason multipass is a property on the
> >     encoding profile and not just on video stream
> >     profile?
> 
>   To make it faster to figure out if the profile requires a multipass setup (in
> encodebin).

Couldn't that also (better?) be done with additional API like

  gst_encoding_profile_is_multipass (profile)

? Which could iterate the streams and check if multipass flag is set on any of
them. Again, no strong opinion, just wondering.

>  [pass/vfr/etc. option args]
>
>   I'm not that thrilled about making them all flags though.
> 
>   What I could do is the following:
>   * make gst_video_encoding_profile_new not take the extra args.
>     Those pass/vfr/multipass args would have sane defaults.
>   * add getters/setters to get/set those properties.
> 
>   Like that you end up in most of the cases not caring about those extra args,
> and if you need it's trivial.

That sounds like a good idea to me. Means you can't do something like

  gst_encoding_profile_add_stream (profile, gst_video_encoding_profile_new
(..));

any more for those cases, but that's not really a big loss.


> >  - why is 'pass' part of the video encoding profile? (...)
> 
>   Because you need to set different properties (and ergo presets) depending on
> whether it's the first or second pass.

Ah right, forgot we only standardised the "multipass-cache-file" property, but
not the other properties.


> >  - do we really need the profile type enum? Isn't the GType
> >    good enough? It's not like this is performance-critical?
> 
>   That would require creating other types for the subpicture and image formats.
> There's no performance critical issue with that :)

I think I'd create dedicated GTypes for all stream types anyway, and if it's
just for consistency (whether we keep the enum or not). 

Are you/is anyone using the image/subtitle types yet btw? (rygel?)


> >    (maybe the profile should have different API for, and keep
> >    separate GLists for the different types?)
> 
>   I don't understand what you mean.

This was in connection with the profile enum type question. I meant that if the
profile kept audio/video/xyz streams in separate lists in the profile, then
it'd be easier to get all streams for a certain type (you just hardcode that
via the API then instead of passing an enum), if that was the goal. (=
nevermind)


> >  - is an audio equivalent of variableframerate needed?
> 
>   It's done unconditionally if encoding is needed. I don't see the usage for
> not having it always enabled.

Agreed.


> > where do those files come from in future?
> 
>   They can either (in the future) come from the locations mentionned above, but
> you could also have app-private profile files.

I meant: is there a plan to have a dedicated profiles repository/module where
targets are collected? What package will install them in these locations? (This
just out of curiosity, not really related to the code).


> >  - would it make sense to also have some kind of
> >    _is_available() for a profile? (we would then check
> >    the registry for suitable elements and check if the
> >    required preset is available for one of them)
> 
>   _is_available() in the sense "do I have the GstElement(s) required ? Yah, I
> could make that code available (it's already used in encodebin and could be
> refactored easily).

I was wondering what happens if you have a suitable encoder for a stream
profile, but the required/specified preset isn't available. So two checks seem
necessary to me: (a) encoder element, (b) profile availability. (This is also
not directly related to this patch of course.)

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