[vlc-devel] [PATCH] Add methods to libvlc to enable and query recording of current media:

Mark Lee mark.lee at capricasoftware.co.uk
Sun Jul 29 19:51:46 CEST 2012


OK, I am working on a new replacement patch.

This time I implemented a callback to track the state of the "can-record"
variable. Each time the "can-record" variable value changes, the callback
is executed and causes a new "recordable changed" event to be emitted by
the media player event manager.

This works in the same way as the existing seekable and pausable
implementation that has been in libvlc for some time.

There is some non-ideal behaviour: if the media player is stopped, or the
playback finishes normally, then the recordable state change event does
*not* get emitted. Nevertheless, this is the same behaviour as can be
observed now with the current "seekable changed" and "pausable changed"
implementation.

What this means now is that you can play your media and as soon as you get
the recordable changed event you can start recording. You can then track
the state by handling the recordable changed, stopped and finished events.

This is tested and working in my own libvlc bindings.

This should address the previous review comments regarding 1) how the
caller knows when to invoke the new is_recordable() method, and 2) how the
caller knows when the recordable state has changed.

I also added some more explanation (including what I have described above)
to the method declarations in the header file - presumably this is what you
mean when you mention the Doxygen documentation?

Patch to follow...

On 29 July 2012 15:40, Rémi Denis-Courmont <remi at remlab.net> wrote:

> Le dimanche 29 juillet 2012 17:19:03 Mark Lee, vous avez écrit :
> > Hello...
> >
> > On 29 July 2012 14:49, Rémi Denis-Courmont <remi at remlab.net> wrote:
> > > Le dimanche 29 juillet 2012 16:30:15 Mark Lee, vous avez écrit :
> > > > +/**
> > > > + * Can the media player record the current media?
> > > > + *
> > > > + * Media must be playing or buffering before it can be recorded.
> > > > + *
> > > > + * \param p_mi media player
> > > > + * \return non-zero if the media player can record, zero if it can
> not
> > > > + * \version LibVLC 2.1.0 or later
> > > > + */
> > > > +LIBVLC_API int libvlc_media_player_can_record( libvlc_media_player_t
> > >
> > > *p_mi
> > >
> > > > );
> > >
> > > I don't see how that's supposed to work. How does the caller know when
> to
> > > call
> > > the function? How does the caller know that the state has not changed
> > > since it
> > > checked the result of the function? This function seems intrinsically
> > > broken
> > > by design.
> >
> > As to when: the caller could query this on receipt of a buffering or
> > playing event. Similarly if an event like stopped or media changed is
> > received then the caller would know the old state was no longer valid. Is
> > that approach not acceptable?
>
> I don't know. But whatever the method, it needs to be specified in the
> Doxygen
> documentation.
>
> > As to the state changing: I did not expect that the state of this
> variable
> > would change whilst the media was playing, but I suppose I don't know
> > enough about vlc to be sure.
> >
> > Anyway, do you think it is simply useless to include this function or
> > should it be fixed somehow?
>
> I don't know. But without proper documentation it is useless.
>
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120729/249b0565/attachment.html>


More information about the vlc-devel mailing list