hashing out medium="video"

[daveajones]

Let's constrain the medium="video" debate here for the sanity of all.

[daveajones]

The initial idea behind medium="video" was that since medium is a channel level tag, having a way to specify that a feed is meant to always be a youtube-like experience would be beneficial to apps. An app like Castamatic could see quickly that it has no means to support such a feed and take appropriate measures.

For instance, 3speak feeds and Peertube feeds just aren't going to ever be playable in Castamatic in it's current form.

The term "video" was chosen just because no other more appropriate term could be found.

3speak and Peertube are probably the best example of what was intended. It wasn't intended to cover normal podcasting scenarios where audio and video of the same content is mixed in the same feed.

I'm not going to go to the death on this. I just want to make sure we all understand each other as best we can before actually taking any actions because this tag is very much in use.

[SilasVt]

What if the problem people have comes from the fact that in some ways it is very specific. Like Podcast, blog, newsletter, music and Audiobook. Which all have fairly defined ideas in peoples minds. But then you have just the word video. which means anything. I wonder if it had been defined differently from the start this would not be a problem. Like calling it audio, video or text. to represent the focus of the media provided.

[jamescridland]

Music videos: medium="music" and an enclosure which is a video. (And maybe an alternateEnclosure which is audio).

Podcast videos: medium="podcast" and an enclosure which is a video. (And maybe an alternateEnclosure which is audio).

With alternateEnclosure, we've successfully split the concept of "content" from the concept of a filetype. There will only be ONE feed for any one show. This benefits recommendation engines, users, and developers alike.

With a medium tag that defines a filetype, we're undoing all that good work.

Let the enclosure-type define the UX; and the medium define the expected content. (Though, really, the category tags ought to do that, but let's not open that can of worms).

(And this is one example where it's really important what we call a feature. This is a problem specifically because we went with a woolly, un-defined word of "medium", rather than a tightly defined one of "ux" or "features" or anything else).

[theDanielJLewis]

So we essentially want a tag that indicates to apps the player type that should be used in the UI? For example, an "audio" option is always assumed, and displays as a normal audio podcast. A "video" option could be excluded from the app or trigger something as fancy as a Netflix-like UI. A "text" option could trigger a reading mode.

I think the solution to issues like "music videos" is to separate the concerns. One option triggers the UI/exclusions, the other option might trigger additional features. Thus, I think indicating "video" should be completely separate from "music." Then, developers can decide whether how to adjust the UI when both options are present.

With this in mind, I think the medium tag should be focused only on the medium (audio, video, or text) containing the content, but not the format of the content itself (music, chapters, articles, etc.).

Maybe we make it even more obvious its use, like browsers have @media (prefers-color-scheme: dark), we could have <podcast:uiPreference> or something like that. Again, only for the sake of triggering UI differences or exclusions.

[Dwev]

There are 59 feeds using medium=video at the moment, but probably several hundred or thousand more feeds with a video enclosure.

In some cases, a podcaster might have two feeds, one audio only and the other video. New Media, and TWiT are the main examples I'm thinking of. There are also some video only feeds, that are normal podcasts. (Unfortunately apps like Castamatic don't show me the episodes at all, because they only have .mp4 enclosures. I don't even have the option to just play the audio track there, but that's a Castamatic issue.)

I agree with @jamescridland that a podcast with a video enclosure should be treated as a podcast, and the app players should be able to handle whatever enclosure is present. If they don't want to show the video, just take the audio track and play that.

That said, there is a big potential for video content that is not necessarily a podcast, that would work well in a podcast player, such as YouTubers, and broadcasters that make YT clips.

For example, I don't know how much Comedy Central earns on Jon Stewart clips on YouTube from ad revenue, but is that the reason they post clips there? If they had a Daily Show video clip RSS feed, they could publish that in the open RSS sphere, (and still monetize it with ads or V4V) but not be as beholden to YT. Fans would get the content they want in the same place as other subscriptions, and the monopolistic influence of YT attenuates. I think this would be a good case for medium=video.

(I'm not really sure what point I'm trying to make here, so sorry if this isn't very coherent. Just wanted to add some thoughts to the discussion.)