Support for SponsorBlock

[hatzel]

It would be great to block sponsor reads as collected in SponsorBlock. This might involve a lot of work (i.e. calling ffmpeg manually) as modifying the actual data would be required.
In principle, however, the feature would not be immensely complicated. FFmpeg can be passed cut-lists and can if desired cut only at key-frames. The SponsorBlock API can easily be used to retrieve the blocked segments.

[hatzel]

Turns out this is a lot easier than I thought. Supplying the right arguments to youtube-dl's --postprocessor-args should do the trick, so if you'd be willing to merge something like this (as an opt-in setting in the config file) I'd probably crank out a PR for this in the next few days or weeks.

I'd suggest having one global flag to set up a sponsorblock default which can than be overwritten on a per feed basis.

Maybe something like this:

[sponsorblock]
enable = true
url = "https://sponsor.ajay.app"

[feeds]
  [feed.my_feed]
  ...
  sponsorblock = false

[mxpv]

Could you please provide an example what arguments needs to be passed to youtube-dl? I'm wondering if we can do that in generic way and just give an ability to provide additional arguments to youtube-dl binary.

[hatzel]

Okay, after looking into this a bit more, while the approach works, there are potential problems:

youtube-dl -v --recode-video mkv --postprocessor-args "-filter_complex
   \"[0:v]trim=duration=491.69[av]; [0:a]atrim=duration=491.69[aa];
     [0:v]trim=start=562.16,setpts=PTS-STARTPTS[bv]; [0:a]atrim=start=562.16,asetpts=PTS-STARTPTS[ba];
     [av][bv]concat[outv]; [aa][ba]concat=v=0:a=1[outa]\"
         -map [outv] -map [outa]" \
     -f 18 https://www.youtube.com/watch\?v\=WIVUbBIrbM4

Potential problems arise from the fact that youtube-dl only adds this to FFmpeg invocations. If, however, youtube-dl doesn't even call FFmpeg (which for many formats it doesn't) the arguments are not used. In this case I 'enforced' FFmpeg being called using --recode-video mkv. There may also be situations where FFmpeg is invoked multiple times.

I think the only solution is to call FFmpeg explicitly, after the download has completed, instead. This would mean no modification to the youtube-dl calls are required. Would you be alright with explicitly calling FFmpeg?

For future reference:
The timecodes above were acquired from the Sponsorblock API:
$ http https://sponsor.ajay.app/api/getVideoSponsorTimes\?videoID\=WIVUbBIrbM4

{
    "UUIDs": [
        "96b9e1dc8dc5893e195c1d1f5964eab52ace9081e8568742ab46974b3cd731a2"
    ],
    "sponsorTimes": [
        [
            489.539569,
            562.494883
        ]
    ]
}

[ticky]

Hey! I’ve implemented such an “an ability to provide additional arguments to youtube-dl binary” in #163. ☺️

I think for the use case of forcing the postprocessing to occur, @hatzel, I believe adding --add-metadata alongside the --postprocessor-args would likely do the same thing without incurring a video conversion to a different container!

[shelvacu]

I don't believe this should be closed, SponsorBlock integration can't be done simply with youtube_dl_args. Podsync would need to send a HTTP request to SponsorBlock's API servers, and create the --postprocessor-args accordingly.

[hatzel]

I don't really have the time to tackle this currently. So unless someone else is interested it might as wells stay closed :)

[shelvacu]

I may be willing to work on this, and even if not the closed status makes it seem like this has been implemented, or perhaps won't ever be implemented even with a pull request.