URL standard for audio/video ‘deep’ linking to a specific time

#1

YouTube permits linking to specific times within video, with a URL query parameter such as:

https://www.youtube.com/watch?v=jNvNgsY2mu4&t=2m3s

But the BBC’s iPlayer uses a hash fragment to achieve the same thing. For example:

http://www.bbc.co.uk/iplayer/episode/b07z8034/horizon-20162017-16-the-lost-tribes-of-humanity#playt=31m30s

And Overcast app uses a URL path segment. For example:

https://overcast.fm/+GH-vVlzhA/13:02

There are probably other hosts enabling time links in yet more ways I’m not aware of.

Shouldn’t there be a standard way that is at least formally encouraged?

Here are those URL examples as links:

#2

There is actually a spec that handles this already:

https://www.w3.org/TR/media-frags/#naming-space

#3

Thanks. I thought there must be, but I couldn’t find it. Reading it now.

#4

I suppose what I’m hoping for (perhaps unrealistically) is an opinionated norm that establishes a convention.

The standard refers to…

from the query or fragment component of a URI

…but the average web user just wants to know “that thing I learned I can do on YouTube I can also do on Facebook, and the BBC”, etc.

It doesn’t serve the average user to have to know the specific way each publisher does things, which publishers are often not very good at communicating anyway.

Wouldn’t a convention be a good thing?

#5

AFAICT, the Media Fragments URI spec applies to URLs pointing directly to media file itself, not to a webpage that contains an embedded media player for the media file where hash notation could conflict with identifiers of HTML elements on the page. Webpage case is left up to web developer.

#6

Sorry for my brevity earlier. It is indeed only for media itself. It is however existing work .Last time I checked some of the video providers supported the same syntax of #t=1m20s

Also interesting prior work: The Web Share API receiving target which is defined as an API which could perhaps could be expanded for other meta data such as time perhaps.

@MT highlights some issues with embedding media which can’t easily be resolved with URLs:

  • IDs will collide with on page anchor behaviour
  • Query params impact with JS and serverside interactions
  • Paths impact with server and JS also
  • Pages could have multiple embedded videos so the deep linking would require a way of specifying a primary media element

The other problem is as I see it would there would need to be some added benefit as to why developers would use this new standard way of linking. What would they get from being unifom?

  • Could the browser make them sharable as part of Web Share?
  • Could users bookmark with increased context
    • Could browsers start behaving smarter with this extra context data?
  • Can browsers help the page developers too?
    • Once the primary element is set could the browser increment the seeking #playt=?
#7

Thank you both for your input, and for thinking about the implications that I haven’t.

As more and more content becomes embedded within audio and video, and frequently without a transcript, I feel it would be in our collective interests to agree a convention that gathers momentum, but perhaps that isn’t a ‘standard’ per se…

Perhaps the answer lies in UI design such as Marco Arment’s wonderfully simple Share at current time option within his Overcast app, with the URL mechanics up to him and made irrelevant to the user.

#8

Aside: Wasn’t there a specfic SMPTE standard about timecoding on broadcast media? (Granted that on web media you’d possibly be only able to timecode down to the key-frame level, not inter-frame interpolations.).