[vlc-devel] [PATCH 02/10] Add secondary property to decoder

[Roland Bewick]

On Tue, 7 May 2019 at 8:24 PM, Devin Heitmueller <
dheitmueller at kernellabs.com> wrote:

> On Tue, May 7, 2019 at 3:11 AM Jean-Baptiste Kempf <jb at videolan.org>
> wrote:
> >
> > On Tue, 7 May 2019, at 09:09, Roland Bewick wrote:
> > > Yes, but do you feel like this is going to be something that many
> people
> > > will actually use? or just introduce more complexity than is required?
> >
> > Absolutely not. I've seen many dual-spu requests, never tri-spu requests.
>
> I'm wondering though if this basic feature could help in another case
> - where subtitle streams are created by the demux in indeterminate
> order.  If this were actually a "priority" field, then we could ensure
> that the list of subtitles was properly ordered in the GUI.  Right now
> we have issues with closed captions where CC3/CC4 get created before
> CC1/CC2, and having a discrete priority field would address that
> without having to move around the spu-indexes for the entries in the
> list.
>
> On the other hand, the priority in which subtitles from a given stream
> get rendered in the GUI may be different than the order in which the
> streams are listed.  That said, it's not like we're proposing that the
> GUI let the user decide which subtitle streams are the primary versus
> secondary, right?
>
> Devin
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com


My current implementation is: The first subtitle track selected will be
primary and the second subtitle will be secondary. To swap that, the
primary subtitle would be deselected (promoting the secondary sub track to
primary) and then re-selecting the deselected sub track as secondary. I
think letting the user decide is important because you can apply settings
individually.

I have a feeling this is unrelated to CC ordering in the GUI. I don’t have
much knowledge in this area though so hopefully someone else can provide
some insight.

Roland



>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190507/d6b1ce87/attachment.html>