[bug#61117] Update svtplay-dl to 4.18

[Jessica Tallon <tsyesika@tsyesika.se>]

Leo Famulari <leo@famulari.name> writes:

> Thanks again for working on this package!
>
> On Sat, Jan 28, 2023 at 01:33:44PM +0100, Tobias Geerinckx-Rice via Guix-patches via wrote:
>> > I've also moved ffmpeg form inputs to propagated-inputs
>> 
>> Please avoid propagation whenever possible; it breaks all kinds of nice
>> things.
>
> I'm here to express my weak preference for dynamically binding FFmpeg in
> use cases like this one.
>
> That means, I prefer if packages like svtplay-dl do not depend on FFmpeg
> at all, but rather expect the user to install FFmpeg alongside them.
>
> I prefer this because I use a custom FFmpeg professionally as a video
> engineer, and it's easier to use it with Guix packages if the dependency
> is resolved at run-time rather than at build-time.
>
> I'd expect that many people like me also use a variety of custom FFmpeg
> builds for different use cases.
>
> Like I said, it's a weak preference. And I probably wouldn't use
> svtplay-dl at work in the US, although I do use youtube-dl / yt-dlp. Let
> me know what you think.

Hello,

Thanks for sharing your experiance, especially as a professional video
engineer :)

I think I have a mild opinion for having it bring in ffmpeg, this is
mostly for three reasons:

- There isn't a good way to communicate to users that they might wish to
  pull in ffmpeg.
  
- svtplay-dl will download both audio and video parts and then realise
  it doesn't have ffmpeg and will give up producing a warning. This
  leaves it up to the user to fix, while a merging both files is a
  simple job it often has me searching through a manual as I'm not well
  versed in ffmpeg or similar.

- I like it when things work consistantly (if x version of svtplay-dl
  works a specific way on my machine, it should on another machine, not
  dependent on my profile)

My preference is mild though, let me know what you think!

Thanks,
Jessica.