01:45:10 RRSAgent has joined #images 01:45:10 logging to https://www.w3.org/2019/09/18-images-irc 01:45:12 RRSAgent, make logs public 01:45:15 koalie has changed the topic to: https://w3c.github.io/tpac-breakouts/sessions.html 01:45:18 koalie has left #images 01:59:48 toshiakikoike has joined #images 04:28:10 toshiakikoike has joined #images 05:31:08 toshiakikoike has joined #images 06:05:22 shimazu has joined #images 06:32:05 shimazu has joined #images 07:32:14 smfr has joined #images 07:34:13 toshiakikoike has joined #images 07:34:53 shimazu has joined #images 07:36:44 smfr has joined #images 08:05:41 kzms2 has joined #images 08:17:31 hyojin has joined #images 08:27:34 shimazu has joined #images 08:28:29 smfr has joined #images 08:30:44 ChrisLilley has joined #images 08:31:14 rrsagent, here 08:31:14 See https://www.w3.org/2019/09/18-images-irc#T08-31-14 08:31:23 present+ 08:31:58 gkatsev has joined #images 08:32:16 zcorpan has joined #images 08:32:39 JakeA has joined #images 08:32:41 Meeting: Images 08:32:44 present+ 08:32:45 MasakazuKitahara has joined #images 08:32:45 present+ 08:32:46 present+ 08:32:47 RRSAgent, make minutes 08:32:47 I have made the request to generate https://www.w3.org/2019/09/18-images-minutes.html zcorpan 08:32:47 mstange has joined #images 08:32:48 lizheming has joined #images 08:32:49 present+ 08:32:50 present+ 08:32:54 HeWenli has joined #images 08:32:56 domfarolino has joined #images 08:32:57 dlibby has joined #images 08:33:00 RRSAgent, make logs world-visible 08:33:04 present+ 08:33:05 RRSAgent, make minutes 08:33:05 I have made the request to generate https://www.w3.org/2019/09/18-images-minutes.html zcorpan 08:33:09 toshiakikoike has joined #images 08:33:12 markw has joined #images 08:33:17 present+ 08:33:17 scribenick: zcorpan 08:33:18 present+ 08:33:29 bdekoz has joined #images 08:33:39 [presentation] 08:34:13 yoav has joined #images 08:34:13 annevk has joined #images 08:34:13 jib has joined #images 08:34:23 present+ 08:34:30 cyril has joined #images 08:34:37 present+ 08:34:56 cyril: container format used heavily for video, now proposed for images 08:35:00 cyril: HEIF 08:35:11 bkardell_ has joined #images 08:35:14 cyril: lots of images on a web page, on average 30 per page 08:35:18 present+ 08:35:19 cyril: small in resolution 08:35:21 cyril: for icons 08:35:29 jya has joined #images 08:35:30 cyril: constraints cna be very different compared to video 08:35:35 cyril: images need to be decoded very fast 08:35:38 cyril: footprint is a problem 08:35:45 cyril: small footprint for video decoder 08:35:51 cyril: gpu for video 08:36:06 cyril: goal is to try to understand the consequences for browsers, content providers, users 08:36:10 cyril: overlap and differences 08:36:20 cyril: not everyone is familiar, want to give more details 08:36:28 hhan1 has joined #images 08:36:31 cyril: ISOBMFF 08:36:33 ericc has joined #images 08:36:37 cyril: "boxes" 08:36:47 cyril: MSE-type video "moov" "moof" 08:36:52 cyril: for images "meta" box 08:36:58 cyril: freely available 08:37:01 cyril: link to spec 08:37:27 cyril: more recent spec defines hwo to use the "meta" box to store props for th eimage 08:37:39 cyril: new type of track, "pict" for animations 08:37:43 cyril: how to store thumbnails 08:37:48 cyril: something channels 08:37:54 cyril: codec agnostic 08:38:11 cyril: annexes how to store HEVC, AVC, JPEG, but can use any codec 08:38:35 ISO BMFF: https://standards.iso.org/ittf/PubliclyAvailableStandards/c068960_ISO_IEC_14496-12_2015.zip 08:38:41 pal: freely available? Rf? 08:38:48 cyril: the spec is freely available. 08:39:05 cyril: in terms of royalties, the spec has been available for 20 years... 08:39:13 pal: ISO patent database... 08:39:17 cyril: doesn't mean naything 08:39:20 hhan2 has joined #images 08:39:34 MPEG Image File Format: https://standards.iso.org/ittf/PubliclyAvailableStandards/c066067_ISO_IEC_23008-12_2017.zip 08:39:40 cyril: if someone impl it, and has been sued, that's relevant 08:40:04 cyril: large spec with lots of tech, not all of it is useful 08:40:15 cyril: MIAF 08:40:18 pal has joined #images 08:40:25 cyril: meta box is required 08:40:29 cyril: for specifying base image 08:40:35 cyril: even if you have a sequence of images 08:40:44 cyril: e.g. middle image is representative, used for thumbnail 08:40:49 cyril: media profiles 08:40:56 cyril: brands, special profiles 08:41:01 cyril: progressively loaded 08:41:03 cyril: burst of images 08:41:10 cyril: spec is not freely downloadable 08:41:14 cyril: can pay to get it 08:41:23 cyril: AVIF 08:41:26 cyril: hosted on github 08:41:29 cyril: freely available 08:41:35 cyril: is based on MIAF 08:41:42 cyril: uses AV1 codec 08:41:49 cyril: transparency 08:41:53 cyril: two media profiles 08:41:57 cyril: baseline, advanced 08:42:02 cyril: main and high 08:42:11 cyril: reference software 08:42:16 cyril: C impl, portable 08:42:20 cyril: encode and decode 08:42:23 cyril: including alpha 08:42:39 cyril: the support, HEIF-based images, in browsers is ... currently limited 08:42:57 cyril: does apple support HEIF? 08:43:27 OS supports it but not web-exposed 08:43:57 JakeA: you can encode but not decode in Safari macOS 08:44:04 cyril: other browsers, dunno? 08:44:20 mstange: firefox doesn't support 08:44:36 cyril: chrome bug... 08:44:40 annevk: we're looking into it 08:44:53 annevk: open issues with AVIF 08:45:27 cyril: open questions... is it reasonbale to assume that if a video codec is supported, will the image codec be too? 08:45:31 annevk: once we support both, sure 08:45:33 LOL 08:45:45 cyril: don't want to use multiple decoders 08:46:01 ??: path for gecko, between image and video totally different 08:46:08 ??: but can change 08:46:22 mstange: in the past the answer has been no. for webp and webm 08:46:42 mstange: we don't want the web platform to rely on (something) image formats 08:46:52 yoav: it may be technically possible but there are other considerations 08:47:19 cyril: would media capabilities ? 08:47:24 mstange: i don't see why not 08:47:35 yoav: accept headers... 08:47:50 ChrisLilley: accept were expected to have that role, but failed 08:47:57 yoav: ok but sounds like a reasonable use case 08:48:14 YY: possible that the device can support both 08:48:21 YY: which should you choose 08:49:00 s/YY/markw/ 08:49:01 s/YY/markw/ 08:49:12 yoav: nowehere near that spec but sounds reasonable use case 08:49:31 cyril: AVIF format, supported in video 08:49:37 shimazu has joined #images 08:49:39 Yves has joined #images 08:49:42 cyril: how likely is it to get uniform support 08:49:48 cyril: delta to achieve parsers 08:50:07 ??: common demuxing and decoding video and images 08:50:09 https://tools.ietf.org/id/draft-ietf-httpbis-variants-00.html is relevant to the 'accept' header discussion 08:50:10 Rochw has joined #images 08:50:16 annevk: for image loading there's some byte sniffing 08:50:32 annevk: some challenge 08:50:39 annevk: don't want to add new sniffing 08:50:57 annevk: strict mime types for new formats 08:51:09 yoav: strict mime types seems reasonable 08:51:13 annevk: more than reasoanble 08:51:26 ChrisLilley: do you say ?????? 08:51:36 ??: only to determine the container, not the codec 08:52:10 zcorpan: for top level navigation, sniffing to figure out type of document 08:52:18 cyril: the way HEIF define mime types 08:52:22 cyril: one for static images 08:52:26 cyril: one for image sequences 08:52:47 ??: discussion a while back with w3c on media whether you listen to the server mime type 08:52:57 ??: can only determine by sniffing, not by what the server says 08:53:01 yoav: servers lie 08:53:11 yoav: but if we add new stuff, we can break it 08:53:46 ??: for firefox/safari (some format) , need sniffing 08:53:59 ??: issue of trust 08:54:08 ??: already don't trust mime type 08:54:13 yoav: we should trust and verify 08:54:20 yoav: if they lie, nothing runs 08:54:30 yoav: people should figure it out and fix it 08:55:02 annevk: we require the mime type to be correct, for webvtt, javascript modules... 08:55:12 ??: video in particular 08:55:22 ??: what makes major difference is the container 08:55:29 annevk: video element does a request 08:55:39 ??: media source, you specify what you're going to be fed 08:55:45 annevk: you pass into an API 08:55:55 ??: when you create your SourceBuffer 08:56:01 ??: (missed) 08:56:07 yoav: the server mime type is irrelevant 08:56:29 JakeA: sniffing is fine if you have full access to (something?) 08:56:36 s/??/jya/ 08:56:40 annevk: sniffing i'm talking about if you navigate to a random url 08:56:52 annevk: or if we load cross-origin resources 08:56:58 annevk: safe-listing media resources 08:57:02 annevk: others we'd block 08:57:13 annevk: i'd like to restrict the sniffing. not keep adding 08:57:26 cyril: the first bytes of the file contains the type of file 08:57:34 cyril: the mime type tells you that 08:57:43 jya: video src = bla 08:57:48 yoav: server sends a mime type 08:57:55 yoav: it needs to correspond to the content 08:58:03 yoav: otherwise we need to add to the sniffing 08:58:05 shimazu has joined #images 08:58:34 JakeA: if ... CORS, would just work 08:58:37 annevk: maybe 08:58:40 igarashi_ has joined #images 08:58:52 cyril: specific mime type 08:59:00 cyril: issue is "why 2 mime types" 08:59:16 cyril: either you change the spec, if the static mime type is given but the content is actually a sequence 08:59:21 cyril: rendered as the static 08:59:28 cyril: or get rid of the second mime type 08:59:35 ChrisLilley: given it has htumbnail 08:59:39 ChrisLilley: show static image 08:59:48 ChrisLilley: may want to do that deliberately 09:00:04 yoav: are there scenarios where static will be supported but sequence not? 09:00:13 yoav: if so we need 2 mime types 09:00:28 cyril: when i talk to media folks at google, they don't know 09:00:35 mstange: animations 09:00:44 jya: does the user want to be annoyed with sound 09:00:57 yoav: can be scenarios where people will have multiple ... dunno 09:01:24 cyril: no requirement in the spec to treat the mime types differently 09:01:41 annevk: problem is the mime type has no impact on processing model, will end up the same 09:01:48 yoav: