[vlc-devel] [PATCH 00/20] MR: Finishing vout life cycle work

[Thomas Guillem]

New proposal here: https://code.videolan.org/tguillem/vlc/commits/vout-life/7

Here is what changed:

 - Reworked the following commits to work without the merge of the input_resource locks:

resource: move input_resource_PutVout up
resource: respect vout order
resource: remove unused HasVout
vout: add vout_Pause
es_out: terminate free vout in more places
input: fix vout recycling

 - Changed the way to have a vout that is always valid (that can be used for configuration):
vout: split vout_IntfInit
vout: add vout_CreateDummy
resource: add input_resource_HoldDummyVout
player: always return a valid vout

Since there is no way to create a valid vout_thread_t from the GUI, I decided to create a dummy one when creating the input_resource. You can only change variables on this dummy vout. It will alows UI to pre-configure the vout before playback.

Like before, there is a TOCTU issue if the dummy vout is configured while a decoder is creating one. One possible fix could be to wait for the dummy vout release before creating the true one.

On Thu, May 9, 2019, at 15:38, Thomas Guillem wrote:
> 
> On Thu, May 9, 2019, at 13:36, Rémi Denis-Courmont wrote:
>> Creation/deleting from user point of view. Meaning enable/disable at the vout window.
>> 
>> Furthermore, it seems rather nasty to forbid UIs from going to their mainloop when creating/destroying the (disabled) window.
> 
> Yes, you are right. I need to rework my whole branch then.
> 
>> 
>> Le 9 mai 2019 14:24:54 GMT+03:00, "Rémi Denis-Courmont" <remi at remlab.net> a écrit :
>>> It will still deadlock because vout_Request() and aout_DecNew() still need to be interlocked, for the same reason as Laurent put the lock in the first place. Without it, we cannot sequence outputs creation/deletion as expected.
>>> 
>>> Well probably it could be separate for aout and vout. But it's still needed.
>>> 
>>> Le 9 mai 2019 14:10:33 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>>>> I backported my "merge both locks" commit into 3.0 to reproduce the deadlock.
>>>> 
>>>> Indeed, it protected a deadlock when the following happened:
>>>> 
>>>> The GUI (Qt here) hold vouts while a vout is created from an other thread.
>>>> cf. https://code.videolan.org/tguillem/vlc/snippets/955/raw for the backtrace
>>>> 
>>>> 1/ A decoder thread request a vout, LOCK the input_resource mutex, and create a vout
>>>> 2/ The GUI is on its mainloop and WAIT the input_resource mutex.
>>>> 3/ From the decoder thread, The vout_Request() load a "vout window" plugin, that will emit and wait for the getVideoSlot() that need to be executed in the GUI thread
>>>> 
>>>> => Deadlock
>>>> 
>>>> But this won't happen on VLC 4.0 (I tested it to made sure) since vout_Request() is called unlocked. Only the vout_Create() is locked, but this call only load the "vout window" plugin without enabling it.
>>>> 
>>>> I updated my vout-life/6 branch to fix some issues: https://code.videolan.org/tguillem/vlc/commits/vout-life/6
>>>> 
>>>> Mainly related to the "es_out: terminate free vout in more places" commit. The window was not disabled when I was disabled video tracks from the UI.
>>>> 
>>>> Also, this branch do revert a commit from Rémi: "resource: atomically return vout on failure (fixes #22284)" only to fix the issue in a diffrent way from the "resource: respect vout order" commit.
>>>> 
>>>> On Thu, May 9, 2019, at 12:01, Thomas Guillem wrote:
>>>>> 
>>>>> On Thu, May 9, 2019, at 11:52, Rémi Denis-Courmont wrote:
>>>>>> No. Plugins are supposed to be reentrant, and at least the Qt window provider was before you disabled it. Besides, the resource lock cannot prevent reentry into a vout window activation callback anyway.
>>>>> 
>>>>> The Qt window provider is protected by the resource lock since it's created from vout_Create() that is locked. Indeed this lock is not enough since there can be several input_resource.
>>>>> 
>>>>>> -- 
>>>>>> 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
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190509/3bedd363/attachment.html>