Felix Paul Kühne authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This correctly deploys custom values set through mobile apps

Zhao Zhili authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

The first pass select track A, then the second pass select track B,
FragDemuxTrack(B) return EOF, the loop continue forever.

Attempt public key authentication using user specified path.
Or, if user specified key file path unset.
Attempt public key authentication by trying common default file paths:
 ~/.ssh/id_rsa
 ~/.ssh/id_ed25519
 ~/.ssh/id_dsa
 ~/.ssh/id_ecdsa

In both cases fall back to password autentication if key authetication
fails.

Pierre Lamot authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

home tab is designed to be displayed in no-medialibrary mode.
fix regression from 88f9ab3f

Fatih Uzunoğlu authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This reverts commit 4e8133f4.

Fatih Uzunoğlu authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This reverts commit 7a0719ce.

Fatih Uzunoğlu authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This reverts commit 22268499.

Fatih Uzunoğlu authored 3 years ago and Jean-Baptiste Kempf committed 3 years ago

This reverts commit ddb5082e.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

 - fixes the possibility of cat and subcat nodes sometimes being created
   when not needed.
 - more efficiently skips things when cat is hidden or unknown.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

as done with cat/subcat/plugin objects.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

whilst most plugin descriptors make only a single `set_subcategory()` call
(indicating relevant location in the preferences tree for their options),
some make multiple calls, generating multiple 'subcat' entries within their
option sets.

it should be noted that the qt prefs tree construction code (currently)
handles this by essentially ignoring all but the first one; whether or not
this is the best design, vs. breaking up such option sets across the tree,
is a subject that is tackled in a piece of work to be submitted for review
later.

in any case, the macos prefs tree construction code here looked highly
suspect to me with regards to how it handles such situations. (i'm basing
this on reading code only, i have no Apple device available).

the loop processing each plugin:

 1. creates a `PluginBranch` item. this holds the copy of the config set
    returned by the `module_config_get()` call, which its destructor will
    `free()`.
 2. as the plugin's config set is iterated over, cat and subcat nodes are
    created as necessary (if nodes for them have not already been created)
    in direct response to any subcat entries (to ensure the existence of
    the parent nodes that the plugin node will be attached to in the tree).
 3. for other item types in the set (i.e. actual options along with
    'section' items), they are 'attached' to the `PluginBranch` item (added
    to it's `options` array). additionally the `PluginBranch` item itself
    is 'attached' to the relevant cat/subcat node (added to that node's
    `children` array) if it is not already present there.

so when it comes to plugin option sets that contain multiple subcat items,
this logic means that the `PluginBranch` object will get 'attached' once to
each and every unique subcat in the set (well, those that are directly
followed by at least one non-subcat item).

this fact alone is a problem, since we surely don't want copies of a
plugin's entire option set appearing in multiple places in the tree. it
could be a source of confusion, and creates a potential problem (which i've
not properly examined) when it comes to saving changes.

however it is worse than just an organisational problem - this duplication
of `PluginBranch` instances within the tree actually creates multi-free
issues when it comes to the matter of object destruction. when 'attaching'
`PluginBranch` objects to a cat/subcat we are adding its pointer to an
`NSMutableArray`, which apparently automatically calls `release` (the obj-C
equivalent of C++'s `delete`) on the items it contains when it itself is
destroyed. effectively, by placing the pointer of an allocated object into
such an array, we hand over ownership. the problem is that we are assigning
ownership of the same object to multiple arrays in these multi-subcat
cases. this means that these objects get released multiple times, and
furthermore via their destructors free their config sets multiple times.
ouch!

this commit fixes the problem very simply by keeping track of whether or
not we have already attached the plugin node somewhere, and only attaches
it to a cat/subcat if not. this prevents the issues described here, and
brings the handling of such multi-subcat option sets more into line with
the current qt handling.

an issue remains of potentially unnecessary cat/subcat node creation, which
will be tackled in a later commit.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

as explained in the previous commit, plugins that reference 'general'
subcategories in their option sets are mishandled when it comes to creating
nodes in the plugin tree. the previous commit laid the groundwork for a
solution to this, and now here we actually fix the problem.

to summarise, if the target subcat is a general one, the plugin node is
supposed to be attached to the cat node, i.e. placed on the 2nd tier
alongside subcategory nodes for that category. instead it was mistakenly
attached to the previous `subCategoryItem`.

in fact if the first or only subcat specified in the plugin's option set is
a general one, `subCategoryItem` would be null, and thus the plugin node
object would just never be attached at all.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

nodes for plugins are created in the preferences tree depending upon use of
'subcategory' entries within plugin option sets. while most plugins specify
'non-general' subcategories, and thus will appear on the 3rd tier of the
tree (cat -> subcat -> plugin), some specify 'general' subcategories (which
represent option sets shown when category nodes are selected), and in this
case the plugin node must appear on the 2nd tier alongside subcategory
nodes.

the existing code here did not support this however, with such nodes
instead mistakenly being attached to the previous non-general subcat node,
if available, which is completely wrong.

unfortunately implementation of a simple fix for this is blocked because
different object types are used to represent each of the three different
node types (category; subcategory; plugin) and everything is naively
designed upon the false expectation that the three tiers of the tree can
map purely to each of these respective object types, incompatible with
allowing for a mix of subcat and plugin nodes on the 2nd tier.

a significant overhaul of the node design is thus first required before we
can fix the actual misplacement issue. here i have taken the obvious
approach of unifying the three branch types into one, with an enum based
property identifying subtypes. yes, this requires a little extra memory,
but it's simple and gives us the needed flexibility.

the misplacement issue itself will be fixed in the next commit.

note, a few additional lines where changed in taking the opportunity to
rename `subCategoryItem` to `subcategoryItem`.

Lyndon Brown authored 5 years ago and Hugo Beauzée-Luyssen committed 3 years ago

when processing the core option set, if the subcat is a 'general' one and
we have a category node to attach the current option to, we attached it.
the alternate path was intended for otherwise attaching options of
non-general subcats to the relevant subcat node (when we have a node for
that subcat).

the problem with the implementation of this is what happens if the subcat
is considered a 'general' one, but should we not have a cat node. in this
case it would go down the incorrect path of trying to attach the option to
the last created subcat node, rather than performing the correct action of
ignoring it.

Fixes #18762

Refs #18762

Ancillaries can be attached to any vlc_frame_t or picture_t (in next
commits).

Ancillaries can be created from:
 - packetized demuxer modules
 - packetizer modules
 - decoder modules

It can't be created from a non packetized demuxer module since the
attachement to the vlc_frame will be lost by the packetizer module that
will be automatically inserted.

Ancillaries are automatically forwarded from a vlc_frame_t to an other
vlc_frame_t and from a picture_t to an other picture_t. This allow to keep
ancillaries untouched when audio filters or video filters are used (these
filters don't have to know about the ancillary).

Ancillary readers can be either:
 - A decoder module
 - An audio output
 - A video output
 - Any filters

Refs #18762

Will be needed by the next commit.
No functional changes.

Refs #18762