- From: Courtney Kennedy <ckennedy@apple.com>
- Date: Fri, 17 Oct 2014 15:10:01 -0700
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-texttracks@w3.org" <public-texttracks@w3.org>
Hi Philip, That’s correct, it handles vtt in ISO files or in HTTP Live Streaming. I do not know of any free or inexpensive tools that are publicly available that do create ISO files with VTT in them. MacCaptions has this functionality. ______________________________ Courtney Kennedy Engineering Manager, Media Sharing mobile: 408-771-8615 > On Oct 17, 2014, at 3:04 PM, Philip Jägenstedt <philipj@opera.com> wrote: > > Hi Courtney, > > I've upgraded to Yosemite, but am unable load an external .vtt file in > QuickTime Player. Does it only support in-band WebVTT and if so, are > there any tools that can mux a video file with a .vtt file for > testing? > > Philip > > On Fri, Oct 17, 2014 at 7:28 PM, Courtney Kennedy <ckennedy@apple.com> wrote: >> Hi Again Silvia, >> >> Now that OS X Yosemite is available, I can also let you know that it has >> full support for WebVTT in QuickTime Player X and in iTunes Player, or in >> any 3rd party apps built using Apple's AVFoundation framework for video >> playback. Both Yosemite and iOS 8 have the same level of support for >> WebVTT. >> >> Best Regards, >> Courtney >> ______________________________ >> Courtney Kennedy >> Engineering Manager, Media Sharing >> >> >> >> >> On Oct 12, 2014, at 1:44 PM, Courtney Kennedy <ckennedy@apple.com> wrote: >> >> Hi Silvia, >> >> >> On Oct 11, 2014, at 11:29 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> >> wrote: >> >> Hi Courtney, >> >> Thanks, that's great information. When you say that it supports the >> full content of the WebVTT spec, does that mean you also support >> regions? >> >> >> Yes, we implemented support for regions. >> >> How can I test the features? Is the Video Player App >> available on MacBooks? (I couldn't find it). >> >> >> Its available on iOS8. >> >> Is there a set of test >> files that you support so we can make sure to be compatible with your >> implementation in the spec? >> >> >> We are working on putting together a set of test files, but don’t have them >> ready yet. >> >> >> Thanks, >> Silvia. >> >> >> On Thu, Oct 9, 2014 at 6:51 AM, Courtney Kennedy <ckennedy@apple.com> wrote: >> >> Hi Philip, >> >> Apple’s Video Player App and any third party video players that build upon >> Apple's AVFoundation APIs support the full current version of the WebVTT >> spec in iOS 8. Webkit does not yet. >> >> Courtney >> >> On Oct 8, 2014, at 12:32 PM, Philip Jägenstedt <philipj@opera.com> wrote: >> >> Hi Courtney, >> >> That would indeed qualify as strong interest. >> >> I can't find any trace of this implementation in WebKit: >> https://trac.webkit.org/browser/trunk/Source/WebCore/html/track/VTTCue.idl >> (no lineAlign/positionAlign) >> https://trac.webkit.org/browser/trunk/Source/WebCore/html/track/VTTCue.cpp >> (nothing relevant in setCueSettings) >> >> Searching the Web for "WebVTT iOS8" also doesn't find anything useful. >> >> I guess it's still in Apple's non-public repo and not widely known >> yet? Since I don't have an iOS device to test with, can you provide >> some details on which bits have been implemented? >> >> Thanks! >> >> Philip >> >> On Wed, Oct 8, 2014 at 7:56 PM, Courtney Kennedy <ckennedy@apple.com> wrote: >> >> Hi Philip, >> >> As I stated in my response to Silvia on September 8th, I am strongly in >> favor of having the current version of the spec become V1, with these >> features in place. Apple implemented support for these features in iOS8, >> so there is an existing implementation available now. I think that >> qualifies as strong implementor interest. >> >> Best Regards, >> Courtney Kennedy >> >> On Oct 8, 2014, at 5:49 AM, Philip Jägenstedt <philipj@opera.com> wrote: >> >> On Mon, Sep 8, 2014 at 6:39 AM, Silvia Pfeiffer >> <silviapfeiffer1@gmail.com> wrote: >> >> Hi everyone, >> >> As you may have noticed, Philip and I had some intensive discussions >> about text positioning in general and the "line" and "position" cue >> settings in particular over the last 6 months. >> >> The way I've come to look at text positioning is that the lines in a >> cue together form a cue box and get positioned together. The width and >> height of the cue box is defined by the smallest box that all line >> boxes would fit into (the bounding box) with a width restriction width >> given by the "size" setting. Within that cue box, text alignment is >> controlled via the "align" setting. >> >> When we look at the "line" setting (i.e. vertical positioning), in the >> past, the "line" setting positioned the first line in a cue (for >> snap-to-lines) and the percentage-point of the cue box for a >> percentage-point "line" setting. This meant that it was basically >> impossible to e.g. position a cue box such that the top of the cue box >> was positioned at the center point of the viewport. >> >> Therefore, we introduced what I called the "line alignment" setting. >> It allowed specifying whether the top, the center, or the bottom of >> the cue box was aligned to the "line" setting position. >> >> For example: line:10%,top would align the top of the cue box at the >> 10% mark of the video height. >> >> Similarly, we introduced what I called the "position alignment" >> setting, which does the same for the "position" setting: it allows >> specifying whether the left, the center or the right of the cue box >> was aligned to the "position" setting. This would, e.g. allow left >> aligned text in its cue box to be centered in the horizontal middle of >> the video. >> >> Or another example: position:20%,right would right align the cue box >> at the 20% mark of the video width (it would still at most be 80% >> wide, or less depending on the "size" setting). >> >> >> Now, Philip has pointed out that these specs are not backwards >> compatible. Adding a second, comma-separated value to the "position" >> and "line" settings basically makes existing implementations of these >> fail. E.g. line:10%,middle will not fall back to line:10%, but will >> rather fail parsing and result in no explicit "line" setting, >> reverting back to the default -1 line. >> >> We therefore have a choice: >> >> 1. We can live with this lack of backwards compatibility. If somebody >> decides that they need to specify the alignment for the cue box in >> relation to the "line" and "position" settings, they will want a full >> implementation of that feature anyway. >> >> 2. We can move these alignments to extra cue settings. Thus, we would >> introduce "lineAlign" and "positionAlign" as two new cue settings that >> apply to the cue box alignment. This will make sure that we remain >> backwards compatible. >> >> >> I'm happy to go with either of these two options, so am curious to >> hear what people think. >> >> Incidentally, there is a second question here: should these be >> features of v1 (and thus go down the path towards the REC spec), or is >> it sufficient to move these off to v2? >> >> Opinions? >> >> >> My preference is separate settings in the syntax, which would map >> better to the IDL interface. Chaning the syntax will make it trickier >> to write markup that works OK-ish in both old and new parsers. For the >> same reason, it would also be good if the new settings moves the cues >> around as little as possible, so that even if the alignment isn't >> correct they're still on the same place on screen. >> >> Of course, I must admit that part of the reason is that I'm still on >> the fence about whether this is worth implementing at all. I think >> this should be a v2 feature or wontfix, unless we have some strong >> implementor interest elsewhere. >> >> Philip >> >> >> >> >> >> ____________ >> Courtney Kennedy 408.974.3386, mobile: 408.771.8615 >> Engineering Manager, Media Sharing >> Apple, Inc. >> >>
Received on Friday, 17 October 2014 22:10:31 UTC