Andy Lo A Foe
Wed, 3 Apr 2002 17:47:36 +0200
(CC to alsaplayer-devel)
On Wed, Apr 03, 2002 at 04:13:26PM +0200, Werner John wrote:
> I'm looking at "input_plugin.h". types etc are all ok. input_object has
> void *local_data which is for my own use, I assume. The object_mutex shall
> be locked while accessing the object and unlocked afterwards. Right?
Yes, you can use the local_data pointer to allocate extra memory you
might require for each instance of your plugin. This data is "owned" by
the plugin instance, which might be a bit confusing since the input_object is
owned by the CorePlayer instance. I will look at changing this.
> stream_info has to be filled in by the pulugin. The information may be
> accessed by an interface using CorePlayer::GetStreamInfo(). I assume that
> the input plugin is allowed to free stream_info in the input_close_type
> function. Right?
the stream_info call takes a valid pointer to a stream_info struct, so
the plugin should never free this. Only the local_data part should be
freed by the close() call along with any other memory it allocates
> Could you give me a short idea which of the functions is called from
> what part of the player core and, maybe even more important, in what
> sequence? E.g.,
> is init() called before or after open() ?
init() is called before every other function in the plugin. This
function should be used to setup the plugin, dlopen needed libs, etc.
etc. If the init() function fails none of the other functions will ever
> is init() or open() called before can_handle() ?
init() is called before can_handle().
open() is typically called after the file passes the can_handle() test.
Note that can_handle() does not need to by followed by an open() at all.
> cleanup() before or after close() ?
This naming is confusing yes, I already changed it in the scope plugin.
cleanup() will be renamed to shutdown(), which is called just before
the plugin is unloaded. So shutdown() (cleanup) is the counterpart of init().
> well, I set it to 0 for the meantime, but what are they fore?
> typedef int input_flags_type; /* capability flags for this plugin */
If your input plugin is able to seek inside the data stream the flag
should be set to:
This is currently the only flag that in in use right now. I will
probably introduce some other flags shortly (P_SEEK_SAMPLE_ACCURATE,
> The ones about framerate, channels, etc are quite straight foreward and I
> have no questions about these, at the moment ;)
Ok, hope all else is clear now... If not, let me know...