ericc: could have an extra video track as part of the main video resource

cyril: mp4 has this already

ericc: problem is that you only have thumbnails for the currently buffered portion of video
... people want to see thumbnails for the whole length regarldess of what's buffered

<nigel> scribeNick: hober

[scribe missed a bit]

ericc: another way to do it would be to have a separate video file for the thumbnails
... we need a way to associate that with a <video>

could define a new <track kind> value

scribe: one advantage is that it's self-contained, with images and timestamps

FrankOlivier: with compression etc., small file, loads quickly

ericc: could use an image sprite

nigel: video files don't necessarily have timestamps, may just have frame numbers or offset info
... Where in the system architecture should the mapping be done between main video times and thumbnail times: for example what if you want 1 thumbnail per minite of the main video

FrankOlivier: you'd make the thumbnail video have a lower framerate

ericc: have it be the same duration as the main video

cyril: jwplayer uses a vtt file containing geometry fragids to a single image sprite

<cyril> https://support.jwplayer.com/customer/portal/articles/1407439-adding-preview-thumbnails

zcorpan: use cases?

ericc: builtin controls and custom controls

cyril: is this a video track in the main video or a separate file

ericc: you want both

cyril: if the video contains captions in the video file, does edge expose those text tracks to js?

FrankOlivier: we don't

ericc: webkit does
... sites that implement custom controls should be able to use this

zcorpan: doesn't make sense as a track element
... prefer thumbs=""

hober: what about multiple sizes, need microsyntax

FrankOlivier: need multiple formats too, prefers track elements

cyril: we want both, for live you want the thumbs in-band

ericc: we don't have to block the load event like we do for enabled text tracks

nigel: thumbnail viewer is a <video> itself

FrankOlivier: this is MediaController

zcorpan: no, because you might show a range of thumbs at once
... this is not semanticly a track, we should not use <track>

cyril: similar to <track kind=chapter>

FrankOlivier: [something about data cues]

[chat about native controls v. custom controls; novel ui possible]

ericc: maybe a cue type, like data cue
... then you get an event when it's time to display some thumbnail
... not sure that's useful

zcorpan: events don't help

ericc: want a method to get the thumb for a time

FrankOlivier: or to get all of them

zcorpan: and their timings

ericc: and you get blob urls for lazy resolution

nigel: [rounding concern]

ericc: it's simple, it's frame in thumbnail video at same time
... up to author to use same time scale

FrankOlivier: media fragments api has time offset and id

[frank and cyril talk about media frag id being frame id]

ericc: do we need the "get the thumb for time x" api

hober: yes

eric: problem in [something] we shouldn't repeat

ericc: for live content, don't want to hang onto old thumbs that you can't seek back to

zcorpan: UA should be able to purge thumbs for unseekable ranges

ericc: yes
... we should do the same thing for vtt

[more vtt and live streams discussion]

ericc: does it make sense to support both kinds, jwplayer-style and a video file

FrankOlivier: video file only

zcorpan, hober: agreed

[scribe missed something MarkVickers said]

cyril: [concern about compression and performance]

ericc: not a problem in practice, can use hardare decoder

nigel: what about devices with a signle hardward decoder

ericc: software decoder fallback is fine

nigel: animated why not generalise to any format that allows a particular single image at a time to be referenced?

ericc: anything the platform supports as a video

MarkVickers: alternate video track with all iframes

ericc: like mp4, need way to identify purpose of in-band track
... makes sense for live content

MarkVickers: what about on demand?

ericc: can only display thumbs for currently buffered range
... this is another reason for <track type>

zcorpan: this complicates media loading

hober: only if you support them

zcorpan: but you need to expose them to js

nigel: json file with links to images

FrankOlivier: you could use data cue for that
... on cell network, loading lots of images separately is bad

zcorpan: how do you envision multiple sizes working?
... wouldn't work with <track kind>, need something else as well

hober: like sizes=""

zcorpan: or srcset=""

ericc: we only need to expose something if it's important for script to be able to pick whih thumb track

hober: what about custom controls

FrankOlivier: reinventing media queries?

zcorpan ericc: no

[something about adaptive streaming and evaluation of media queries]

cyril: what's the relationship between thumbnails and posters

ericc: poster is dimensions of main video, dimensions of thumb video is different (smaller)
... coming up with api for script to be able to specify resolution

need to expose metadata about each video track in the thumbnail video, including resolution and which one is selected

nigel: maybe storyboard not the same as scrubbing thumbnails

cyril: might want to check sourcing in-band media ... document

<cyril> https://dev.w3.org/html5/html-sourcing-inband-tracks/

hober: action items?

<scribe> ACTION: zcorpan to file bug on HTML [recorded in http://www.w3.org/2016/09/21-thumb-minutes.html#action01]

<zcorpan> https://github.com/whatwg/html/issues/1805 Should allow purging of unseekable inband cues

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/quicly/quickly/
Succeeded: s/??/nigel/
Succeeded: s/what if/Where in the system architecture should the mapping be done between main video times and thumbnail times: for example what if/
Succeeded: s/odn't/don't/
Succeeded: s/gif?/ why not generalise to any format that allows a particular single image at a time to be referenced?/
Found ScribeNick: hober
Inferring Scribes: hober

WARNING: No "Topic:" lines found.

Present: cyril hober zcorpan ericc MarkVickers FrankOlivier nigel
Got date from IRC log name: 21 Sep 2016
Guessing minutes URL: http://www.w3.org/2016/09/21-thumb-minutes.html
People with action items: zcorpan

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report