Re: Decisions related to "line" and "position" cue settings

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:04:48 UTC