Re: Bug#777220: ITP: you-get -- downloader for youtube and number of sites
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi all,
On 02/07/2015 11:42 AM, Jonas Smedegaard wrote:
> Quoting Paul Wise (2015-02-07 08:36:48)
>> On Fri, Feb 6, 2015 at 9:50 PM, Thorsten Glaser wrote:
>>
>>> I smell the chance to share…
>>
>> It would be nice if someone could contact all of the Python ones
>> and ask them to merge their code. Same for all of the Perl ones
>> and all of the other ones.
>
> Looking a bit closer, it seems there _is_ currently a single
> download-only framework for each of Python, Lua and Perl plugin
> APIs (youtube-dl, Lua and get-flash-videos, respectively): The
> (only?) other related reusable framework seems to be python-pafy
> which seems targeted special features of Youtube rather than
> generic download from many sites.
Yep, pafy is trying to get most out of youtube in CLI environment
(notice that mps-youtube is around pafy and uses mpv | mplayer2 for
firing up videos - there are plenty of options and the community
around it is very healthy and productive).
>> Even more interesting would be a standard for video downloader
>> plugins so that video players like Totem and VLC could just play
>> videos on these sites. De-duplicate all the things!
>
> libquvi offers Lua-based plugin API. Used by mplayer2, totem,
> git-annex and older mpv (and possibly also rhtyhmbox and grilo).
>
> youtube-dl offers Python-based plugin API. Used by freevo, lives
> and recent mpv.
>
> get-flash-player offers Perl-based plugin API. Used by no other
> tools, apparently. From personal experience get-flash-player is
> better than the others at "walking blindly", fetching videos from
> random websites.
I suppose you meant get-flash-videos?
> Would be nice if someone...
>
> * rewrote site support in other tools as Python/Lua/Perl plugins. *
> rewrote competing UI of other tools as libquvi/youtube-dl
> frontends. * ported libquvi/youtube-dl/get-flash-player plugins to
> each other.
>
>
> - Jonas
>
What if someone takes a lead in contacting upstream developers of all
this implementations and see if all can work together to one
unique/universal software/library (something as Paul suggested)? Would
that benefit the entire Free software ecosystem regarding this part of
it? Or to let people develop what makes them happy (and fun!) and
maybe we see some unique features in one that others don't have or
that others just experiment it and so on?
My stand is that it wouldn't hurt that we try to combine "forces" of
upstream developers if we can. I am willing to hear opinions on this
matter and would even take time to contact and manage upstream
collaboration if needed.
Cheers,
zlatan
- --
Its not the COST, its the VALUE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJU1iGrAAoJEC5cILs3kzv9IekP/AyFZzFxpN4l9K0gRNKzo75j
006sUSeancx4JMBTe2oRV28YBE8p/U8CNS2qCtnhr8Zd3GbTCoKlYV8k5TX3QZt9
TlcNIqJcH55DGWjMcWKdpLqDb/8JJ+cs2ZM012ennMGwm7m81ijwBg9uG8qluVoo
XzCVbpW9C8E3GD8noIAY1Bxm3GCHr9n+CCi/iH1FciXOe/7EQRPF2SBlraWNsApM
9vDyDjfWn6cVPfS12NrHWy0TZYjn6a4qYGZT6WmVBL00iI4IJg77vkLjd7BrHZ0c
8QhuBoSUwJNu+X20KfJioWMZnES8qppKDOChP450QVwhm27wWUj6hUZtEw+BTIB4
vrHtqODlfhNsz/gZk6FjyKiPl+YWwbQEPGTGN6uu3YtBiOtoDss0vk6DDvZsQV0Y
NB7kuQAkwvQozAqSLq7zddOpolK1fdpt8kJjdirmJNFj0zaxxaLwX+YOMszlu1MP
HGxWZ3fn81WUz4h0zWJLmKSClH+6eDHhcN9JtAAsmgGO8JHfuhRKOp2pMuNS1rMU
oMODIVB5re+qZkVyvuoaAR2uKfecb4UimRe6Of3k/NlFS1Xse4Oo1oj4HXIUdQVJ
hxkb3ONacAJaHoblAdgtaqdO5fLoF/Fs7skwopUDRECkHaqwgdVBOSG7av2lm4Gp
c+2cmNUXwDLkLX/7JHD0
=SCrA
-----END PGP SIGNATURE-----
Reply to: