[vlc-devel] [PATCH 2/2] libvlc: add event libvlc_MediaPlayerESChanged
Edward Wang
edward.c.wang at compdigitec.com
Wed Jul 16 16:41:04 CEST 2014
On Wed, Jul 16, 2014 at 8:46 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
>> This way we immediately know which list we have to fetch again. But
>> this is open to discussion.
>
> But you need to keep track of the list, which not all library users do. And
> then you need to compare the old and the new version of the adequate list
> everytime - which is inconvenient and error-prone.
>
> With the unique ID, you need to fetch each list and look them up. That is
> "slow", but still faster than comparing lists, and much easier to write.
As I understand it (and please correct me if I am mistaken), IDs are
unique in the following manner, for instance:
Audio tracks: 101, 102, 103
Video tracks: 201, 202, 203
Subtitle tracks: 301, 302
----
As for the issue at hand: if only the ID is provided, then it does not
indicate whether the ID was added or removed.
Since that information is not provided, we have to pull the new
versions of all 3 lists to compare and find the ID in question to find
out.
By providing the ES type instead, we would only need to pull the one
relevant list instead of all 3 lists. The UI/backend of the
application would probably have to update for the user/service/etc
differently.
Alternatively: provide the ID and whether it was added/removed. Then
it becomes simple to search through local lists and no pulling is
needed at all. Then API users who don't keep local list copies are
happy as well.
> Most importantly, the user does not have to replicate the track lists in its
> private state.
Would it be possible to clarify this statement?
When getting the tracklists with functions like
libvlc_audio_get_track_description() and friends, what are the
"private states" involved?
Regards,
Edward Wang
More information about the vlc-devel
mailing list