[vlc-devel] RE : RE : RE : [LONG] Some thoughts and questions aboutvout

[brezhoneg1]

-----Message d'origine-----
De : vlc-devel-bounces at videolan.org
[mailto:vlc-devel-bounces at videolan.org] De la part de Rémi
Denis-Courmont
Envoyé : jeudi 13 novembre 2008 21:58
À : vlc-devel at videolan.org
Objet : Re: [vlc-devel] RE : RE : [LONG] Some thoughts and questions
aboutvout

Le jeudi 13 novembre 2008 22:40:49 brezhoneg1, vous avez écrit :
> ------ if we need to distinguish origin (playlist, VLM or libvlc API),
> this should not be a problem.

I am not saying this is a fundamental problem. But this is a problem
with your 
proposed API.

>     Through genealogy of calling object (p_obj->p_parent->p_parent...
> till Null), we know how to differentiate them. So we can keep this
> information in the recycling structure, and reattribute objects to
their
> original family.

I would really rather we forget about the object genealogy thing. As far
as I 
can tell, it is meant for configuration inheritance (and debug).
Children 
should really _never_ need to know about their parents. I much prefer
the way 
it's done with sout already now - the parent can just take its 
grand(^n)children out of the input if it wants to keep it.

I am pretty sure Pierre d'H. will make the same point. And Laurent's not

unlikely to either. If the authority argument is not enough:

Looking for parent objects always often triggers weird problem when
extending 
and changing things in unpexted ways, and sometimes causes deadlocks. 
Try --sout-keep --sout '#display' and see for yourself. In the same
vain, I 
wonder how many ways we can screw things up today with slave inputs with
all 
those vlc_object_find(INPUT, PARENT) all over.


Answer:
-------
   I have a slightly different opinion about vlc_object_find :

- vlc_object_find( .., .., FIND_PARENT)) is usually clean and
predictable (albeit maybe input-slave, not so sure). The good point is
that pointer to an object can easily be retrieved without passing too
many parameters to functions.

- vlc_object_find( .., .., FIND_CHILD))may be more of a problem (for
example, an input can have several vout (vout for display, vout for
audio-visual, vout inside a sout chain, even multiple vout for some
video-effects). There is no easy way to know which one it is.  (e.g OSD
issue !)

- vlc_object_find( .., .., FIND_ANYWHERE)) should be BANNED. VLC has
evolved in such a way that searching for something anywhere inside an
instance is pure gambling.

I think rewriting FIND_ANYWHERE to FIND_PARENT/FIND_CHILD when possible
could solve many problems for the short term. (especially for libvlc api
for which I feel like advocating)

As for recycling, should I forget about it ?