[vlc-devel] [PATCH 1/5] core: move input.c to input_internal.c

Rémi Denis-Courmont 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
> vlc_input_t.

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


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.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/





More information about the vlc-devel mailing list