[vlc-devel] [PATCH 2/7] objects: add vlc_object_set_module

[Rémi Denis-Courmont]

Hi,

I don't know what you are on about. We already have a structure to pass per item and per ES meta-infos.

And while ideally we should distinguish between media-intrinsic meta and extrinsic meta, in practice we don't do that distinction yet. Some meta are neither purely intrinsic nor strictly extrinsic already

Le 28 mai 2019 14:58:14 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>
>On Tue, May 28, 2019, at 12:54, Rémi Denis-Courmont wrote:
>> Hi,
>> 
>> Stating the obvious here but the etymology of debug literally means
>to remove bugs, not add them.
>> 
>> In any case, I can't comment on a version of a patch series that has
>not been posted. But I'm pretty sure it's worse than putting the
>packetizer, decoder, hw context and output module names in the ES meta,
>and the input objects' module names in the input meta.
>
>That seems a viable solution. Do you agree that we would need:
>
>- A new data structure returned by the vlc player that wil contain a
>description of all inputs (and slave)
>- Each input description will contains the demuxer/packetizer module
>name and the list of all stream filters name
>- For each ES track exposed by the player, we would need the name of
>the decoder/packetizer/hw modules + the vout / window modules + the gl
>interop module name (if any).
>
>
>> 
>> Because O(n*n) vs O(1), no serialisation of all object creation and
>destruction, and most importantly, works in LibVLC and all UIs, not
>just Qt.
>> 
>> Le 28 mai 2019 13:13:57 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a
>écrit :
>>> 
>>> On Tue, May 28, 2019, at 11:57, Rémi Denis-Courmont wrote:
>>>> I don't think racy is okay for debugging, no. Debugging code should
>not add bugs.
>>> 
>>> A lot of people seems to disagree with you (cf. previous discussions
>and trac). I'm not talking about adding new "bugs", but about restoring
>our good old "bugs" back to get a feature that was used a lot. There is
>a huge difference. Specially, since we didn't had the chance to review
>this removal.
>>> 
>>> Having said that, I don't see bugs in my branch. There is no race
>anymore when you could get dead object returned by vlc_list_children.
>There is a just a race between object and object module name.
>>> 
>>>> 
>>>> Besides, I don't see how you can have an object whose type and
>lifecycle is unknown so the problem is moot.
>>>> 
>>>> Le 28 mai 2019 11:56:25 GMT+03:00, Thomas Guillem <thomas at gllm.fr>
>a écrit :
>>>>> 
>>>>> On Tue, May 28, 2019, at 10:48, Rémi Denis-Courmont wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> To get the name of a loaded module call module_get_name() on the
>module pointer. To get the name of your own module, use MODULE_STRING.
>To get the name of a module used by somebody else's object, use
>vlc_object_get_name() but that's intrinsically racy and unreliable.
>>>>> 
>>>>> As already said, racy and unreliable is ok for debugging purpose.
>>>>> As already said, cf. PATCH 7/7: vlc_object_get_name() doesn't work
>when module are loaded with vlc_module_load().
>>>>> 
>>>>>> 
>>>>>> Le 28 mai 2019 11:24:11 GMT+03:00, Thomas Guillem
><thomas at gllm.fr> a écrit :
>>>>>>> 
>>>>>>> On Tue, May 28, 2019, at 10:03, Rémi Denis-Courmont wrote:
>>>>>>>> The "feature"(s) of getting the name of a module and getting
>the module 
>>>>>>>> of an object are still there. No news here.
>>>>>>> 
>>>>>>> How do you get the module of an object ? Did you see 7/7 ?
>>>>>>> 
>>>>>>> > 
>>>>>>>> This patchset is removing one of the two ways to get there
>though.
>>>>>>>> 
>>>>>>>> Le 28 mai 2019 09:39:22 GMT+03:00, Thomas Guillem
><thomas at gllm.fr> a écrit :
>>>>>>>>> On Mon, May 27, 2019, at 18:41, Rémi Denis-Courmont wrote:
>>>>>>>>>> Le maanantaina 27. toukokuuta 2019, 19.15.56 EEST Thomas
>Guillem a
>>>>>>>>> écrit :
>>>>>>>>>>> I mean I can store the module name instead of the module.
>>>>>>>>>> We already store the module name in the object.
>>>>>>>>>> 
>>>>>>>>>> Leaving aside that it's a racy ugly hack, it's already there
>without
>>>>>>>>> needing 
>>>>>>>>>> any changes.
>>>>>>>>> It's just a hack that I try to put back in order to restore a
>feature.
>>>>>>>>> No news here.
>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>> 雷米‧德尼-库尔蒙
>>>>>>>>>> http://www.remlab.net/vlc-devel mailing list
>>>>>>>>>> To unsubscribe or modify your subscription options:
>>>>>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>>>>>> vlc-devel mailing list
>>>>>>>>> To unsubscribe or modify your subscription options:
>>>>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>>>>> -- 
>>>>>>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser 
>>>>>>>> ma brièveté.vlc-devel mailing list
>>>>>>>> To unsubscribe or modify your subscription options:
>>>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>>>> vlc-devel mailing list
>>>>>>> To unsubscribe or modify your subscription options:
>>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>>> 
>>>>>> -- 
>>>>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser ma brièveté. 
>>>>>> _______________________________________________
>>>>>> vlc-devel mailing list
>>>>>> To unsubscribe or modify your subscription options:
>>>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>>>> 
>>>> 
>>>> -- 
>>>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser ma brièveté. 
>>>> _______________________________________________
>>>> vlc-devel mailing list
>>>> To unsubscribe or modify your subscription options:
>>>> https://mailman.videolan.org/listinfo/vlc-devel
>>> 
>> 
>> -- 
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>excuser ma brièveté. 
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190528/bf350046/attachment.html>