Introducing Clip API improvements and "Clip From VOD" in open beta

Announcements
1

We’re excited to introduce a handful of new features that help developers build solutions to create, edit, and share short-form video content via Twitch clips. In September, we introduced a Twitch API endpoint to enable Clip downloads. Today, we are expanding third-party Clip capabilities with improvements to the existing Create Clip endpoint and the new endpoint in open beta to create clips from VODs.

What’s new for Create Clip?

First, it’s worth mentioning that our updates to Create Clip do not affect existing usage of the endpoint. Developers are now able to take advantage of the following additive features at their convenience.

  • 2k video (if applicable)
  • Vertical video from dual format streams (if applicable)
  • An optional parameter to specify a title
  • An optional parameter to specify duration
  • An updated edit URL in the response with more features:
    • Exporting to third-party social platforms
    • Creating a portrait version of the clip
    • Downloading landscape and portrait versions of the clip

We have also removed the former “has_delay” parameter, which did not have an effect on the resulting clip.

Introducing Clips From VODs

Sometimes you can’t get a clip just right in the moment while streaming. Streamers and viewers have been able to clip from VODs on Twitch, but we’re bringing this feature to the Twitch API. Now that developers can clip from VODs given a video ID, this will unlock new use cases for post-stream moment detection and editing solutions. We believe this will result in more quality Clips for streamers to showcase their key moments with the community.

In fact, a live stream is technically a VOD in the making. This means that the endpoint can also be used to create clips from a time earlier in the current stream if VODs are enabled for the channel.

We look forward to seeing the innovative clip features developers create with these new additions.

3 Likes
2

How does this endpoint work with an app access token? It only says in the 401 response code:

The user access token must include the editor:manage:clips or channel:manage:clips scope.

Does the application both need the scope and be manually registered as an editor on the channel?

Edit: It seems like i am interpreting the API wrong, but it would still be nice to have that when a user authorises the app to make clips, the account that owns the app is allowed to make clips without being an editor on the channel.

Or the other way around, the app is allowed to make clips if the account that owns the app is an editor on the channel, without having to allow the app individual clipping access.

We have an application that finds great clips for users from streams, and we would like to create them with our own user account which owns the application.

I guess this is do-able by just authenticating the app account with the app internally but this is a bit convoluted.

3

Either

  • broacaster and channel:manage:clips
  • editor of channel and editor:manage:clips

So yes, the authenticated user needs to have the role editor (or better)

To use an app access token you need to have prior auth/created user access tokens, then generate a no scope app access token after the fact, the same as how authenticating to eventsub works

The owner of an application has no bearing on how authentication works.

Broadly whom owns the clip doesn’t matter, unless you need to manually tweak/edit the clip. So here it just doesn’t matter the owner but do do this

Either:

Auth as the broadcaster, whichever scope, I’d use the broadcater centered one and create the clip as the broadcaster, and then you’ll still be able to use the Download Clips API, as the broadcaster is an editor of their own channel

or

Auth as yourself/whichever user you control to your application with the editor style scope and require the broadcaster to editor the user, then you have the fun part of how to know to go or not.

Personally I expect the former over the latter for your use case as easier to generate the clip and then have the broadcaster modify it within 24 hours before using it elsewhere.

For both of these whence done a scopeless app access token can be substitued instead

This sounds like you are taking existing clips and recreating them, losing all the views on the original clips?

Again the owner of an appliction/clientID is irrelevant. Only whom auths to the application/clientID

To clarify

Across the entire Twitch API whom owns a clientID is irrelevant.

What is important is which users grant access to the clientID

Then depending which way round you want to create clips as, will suggest what auth steps to take.

4

Thanks for the reply, yeah i was confused at first, good to know the owner of the client has nothing to do with auth.

We went with just authing the account that creates the clips with the scope one time and then use the app access token. But it’s a good argument that the actual broadcaster then can’t edit the clip.

This sounds like you are taking existing clips and recreating them, losing all the views on the original clips?

No, the app creates clips from streams primarily for smaller streamers who don’t have a lot of clips. We aren’t republishing already made clips :slight_smile:

5

Yeah for your use case I’d auth the broadcaster, and make the clip as the broadcaster, so then the broadcaster has 24 hours to adjust it.

Saves the additional step of having to have the broadcaster also make the the user account an editor. And easier to troubleshoot issues, as in some cases smaller broadcasters might not be aware of twitch roles and/or how those roles are assigned/setup/etc.

6

Experimenting with the clip from vod endpoint more now. It doesn’t exactly respect the vod_offset most of the time, there is a slight variation when the clip actually ends.

When specifying an exact vod_offset, the clip often, for no reason at all, ends a few seconds later, but it isn’t predictable how many seconds this is. Sometimes it’s as much as 9 seconds, sometimes it’s only 2 seconds. The duration does get respected, so the entire clip is shifted a couple of seconds to the right.

For example: in the request i give a vod_offset of 7631 and a duration of 15. However i observe the actual clip created ends at 7639 instead. It does have the duration of 15 however. So yeah, it gets shifted to the right.

I get that it is a beta, so it might be fixed in the future, but it’s a strange issue.

Edit: I tried setting vod_offset to 60 and duration to 60 and the clip contained 10 seconds of stream which was not viewable in the normal vod view on the website. I guess some timing weirdness occurs which cuts a few seconds off the vod on the start for all streams, and this endpoint does not account for that? But that’s a theory from me, idk how the twitch infra works :slight_smile:

7

Thanks for this detailed feedback. We wanted to confirm that the team as confirmed the cause of the mismatch between the provided VOD offset and the resulting clip’s offset. This will be addressed during our short open beta period and is considered a requirement before considering the endpoint generally available.

8

Copying this feedback thread over so not lost

9

It is worth mentioning that I’m experiencing the same issue with the URL provided as ‘edit_url’ from the Create Clips endpoint as well (from a live stream in this case, not the VOD).

According to the description of that endpoint, that edit URL is supposed to allow the user “identify the part of the clip to publish” i.e. show the clip editing window with the aforementioned draggable timeline.
That feature used to work well until it suddenly stopped working a couple months ago now. Now the edit URL does not take you to the clip editing page anymore, only the clip’s page.

1 Like