[vlc-devel] [PATCH 1/2] share: add wrapper script for the YoutubeDL Python module

[Marvin Scholz]

On 21 Sep 2020, at 10:34, Steve Lhomme wrote:

> On 2020-09-21 10:30, Marvin Scholz wrote:
>>
>>
>> On 21 Sep 2020, at 10:22, Steve Lhomme wrote:
>>
>>> On 2020-09-20 20:57, Rémi Denis-Courmont wrote:
>>>> This script generates a M3U playlist from a given URL, providing a
>>>> simple serial format that can be read and parsed by another 
>>>> process.
>>>>
>>>> There are in principles two other alternative ways to access it:
>>>>
>>>> 1) Calling the YoutubeDL module directly in-process through 
>>>> CPython.
>>>>     This poses a number of problems:
>>>>     - CPython must be loaded by the main executable. Python 
>>>> modules will
>>>>       fail to resolve their CPython symbols otherwise.
>>>>     - Multiple CPython interpreters are still very immature; GIL 
>>>> behaves
>>>>       weirdly. CPython is really not meant for multithread.
>>>>     - The GIL prevents concurrent uses (that's the whole point 
>>>> of it).
>>>>     - CPython network I/O cannot be interrupted by VLC 
>>>> interruptions, so
>>>>       the calling thread may get stuck inside CPython.
>>>>     - A build-time dependency on CPython is added.
>>>>
>>>> 2) Parsing the output of the youtube-dl program. This is what MPV 
>>>> does.
>>>>     But this requires a whole new parser for the Python syntax.
>>>>
>>>> With a custom Python script, we can decide on the serialisation 
>>>> format
>>>> that most suits the usage.
>>>> ---
>>>>   share/Makefile.am     |   2 +
>>>>   share/ytdl-extract.py | 103 
>>>> ++++++++++++++++++++++++++++++++++++++++++
>>>>   2 files changed, 105 insertions(+)
>>>>   create mode 100755 share/ytdl-extract.py
>>>>
>>>> diff --git a/share/Makefile.am b/share/Makefile.am
>>>> index 2373ffbe91..8a92f04360 100644
>>>> --- a/share/Makefile.am
>>>> +++ b/share/Makefile.am
>>>> @@ -49,6 +49,8 @@ nobase_dist_pkgdata_SCRIPTS = \
>>>>       utils/audio-vlc-default.sh \
>>>>       utils/video-vlc-default.sh \
>>>>       $(NULL)
>>>> +
>>>> +dist_pkgdata_SCRIPTS = ytdl-extract.py
>>>>   endif
>>>>    EXTRA_DIST += \
>>>> diff --git a/share/ytdl-extract.py b/share/ytdl-extract.py
>>>> new file mode 100755
>>>> index 0000000000..2d784c5090
>>>> --- /dev/null
>>>> +++ b/share/ytdl-extract.py
>>>> @@ -0,0 +1,103 @@
>>>> +#! /usr/bin/python3
>>>> +#
>>>> +# Copyright (C) 2020 Rémi Denis-Courmont
>>>> +#
>>>> +# This program is free software; you can redistribute it and/or 
>>>> modify it
>>>> +# under the terms of the GNU Lesser General Public License as 
>>>> published by
>>>> +# the Free Software Foundation; either version 2.1 of the License, 
>>>> or
>>>> +# (at your option) any later version.
>>>> +#
>>>> +# This program is distributed in the hope that it will be useful,
>>>> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
>>>> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>>> +# GNU Lesser General Public License for more details.
>>>> +#
>>>> +# You should have received a copy of the GNU Lesser General Public 
>>>> License
>>>> +# along with this program; if not, write to the Free Software 
>>>> Foundation,
>>>> +# Inc., 51 Franklin Street, Fifth Floor, Boston MA 02110-1301, 
>>>> USA.
>>>> +
>>>> +import sys
>>>> +import youtube_dl
>>>
>>> How does this work if the import library is not there ? Do we have 
>>> requirements on the version of the library ? Can we check it in 
>>> configure.ac ?
>>
>> Checking it in configure.ac seems useless as this is about the host 
>> system, not a build time requirement.
>> If the library is not there or its the wrong version so API does not 
>> match, it the script would just fail
>> which IIUC is handled properly by the access module calling the 
>> script.
>>
>>> Can it be part of contribs ?
>>
>> Could be possible, but IMO out of scope of this patchset.
>>
>>> Should we run python with out local environment with our little set 
>>> of dependencies ?
>>
>> Why would you want to do that? I dont really see any benefit doing so 
>> while possibly
>> breaking the import.
>
> I think it's the opposite. Using the system dependencies might be the 
> one breaking the version we support.

Not sure what you mean by "version we support" as we rely on the 
system-installed
youtube-dl here. Worst case the API is different and it fails?

> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel