[vlc-devel] [PATCH 1/5] core: move input.c to input_internal.c
remi at remlab.net
Tue Jul 10 18:24:26 CEST 2018
Le tiistaina 10. heinäkuuta 2018, 16.43.05 EEST Thomas Guillem a écrit :
> Leave input.c for the future "input manager", that will be called
Jokes aside, I don't think the input thread parent can be described as an
input, really. In LibVLC side, the corresponding object type is called media
player, not input - and it manages both inputs and outputs.
So while I agree that manager is not a very inspired word for a name, I would
argue that input is even less inspired. The best I can come up with is
vlc_player_t, vlc_media_player_t or vlc_media_handler_t but there are probably
AFAICT, the closest things to an "input" that we have are the input thread,
the input source or the access.
By the way, the thread word in input_thread_t is wrong. Sure, there is a
thread inside right now, but that is an internal implementation detail and is
likely to change. In fact, there has already been plans to remove the input
thread and create one thread per demuxer instead. So what are we going to call
the input when it's not a thread anymore?
> All current input_thread_t functions should be hidden in the future, the new
> vlc_input_t will be the only way to control an input.
Many functions should be hidden. I'm not exactly confident that literally all
functions would end up that way though.
At least, there are probably requests that apply to the current input *only*
rather than the current input and all subsequent inputs. For instance seeking
or forced fire-and-forget track selection.
More information about the vlc-devel