[vlc-devel] Bug in libvlc for State Changes in Input Control & Media Instance

[Enrique Osuna]

I found 2 problems:

1) Functions libvlc_media_instance_play & libvlc_media_instance_pause
(src/control/media_instance.c) used input_Control( p_input_thread,
INPUT_CONTROL_SET_STATE, PLAYING_S or PAUSE_S ).  This caused the
video feed to be repositioned to the beginning (it kept forcing the
PositionCallback to be called).

I figured that input_ChangeState( p_input_thread, PLAYING_S or PAUSE_S
) was a better option.

2) Function input_ChangeState (src/input/input_internal.h) was setting
the p_input's state without letting the Control (src/input/input.c) to
catch the changes.  Every time you call input_ChangeState it would
automatically change the input's state to whatever the new state was,
this didn't allow for the rest of the library to react to the new
state.  By the time the appropriate functions were called to act on
the new state, it appeared as if it wasn't a new state -- it appeared
as an existing state.

3) Function StateCallback (src/input/var.c) only pushed PAUSE_S and
PLAYING_S states to the control stack.  So the new state never got
updated on the p_input state.  Two options:

a. Send all state updates to the control stack and let the Control
function act on the PAUSE_S and PLAYING_S states and just update the
p_input state with all other new states.

b. Send only PAUSE_S and PLAYING_S states to the control stack (as it
currently does) and manually update p_input state with all other
states.

I didn't know which way was the best way to go to follow standard VLC
conventions, so I went with option b.

4) Function Control (src/input/input.c) only acted on PLAYING_S and
PAUSE_S states when the previous state was already identified as
PAUSE_S and PLAYING_S (respectively).  What about the other states
like the initial OPENING_S or BUFFERING_S states?  So I added an if
statement that if this condition was met, the p_input state would be
updated and nothing else would be done, because this previous state is
mostly likely there because the video instance was just created and
will start shortly.  This PLAYING_S message is just more of an FYI
then anything else.

Also to clean up the operations, I added a statement that checked the
old and new states were the same.  If so, go ahead and skip the rest
of the code.  Lastly, I added a debug statement in cases were a new
valid state was provided but it didn't do anything with it.

Feedback is very welcomed.

Thanks,

Enrique
-------------- next part --------------
A non-text attachment was scrubbed...
Name: state-change-update.patch
Type: application/octet-stream
Size: 4316 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20070930/09f28300/attachment.obj>