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

Hi Again,

Dave Singer reminded me that I *do* know of some free tools for putting VTT into ISO files.  

Here are two:

Cyril Concolato’s tool, called MP4Box which is part of the GPAC project.  It's open-source and freely accessible from: http://gpac.io <http://gpac.io/>. It runs on Windows, Mac, Linux.

and 

Armin Trattnig’s tool, which is available from the MPEG repository, though it requires an account to access.  
http://wg11.sc29.org/svn/repos/MPEG-04/Part30-Timed_text_and_associated_images_in_ISO_Base_Media_File_Format/trunk/ <http://wg11.sc29.org/svn/repos/MPEG-04/Part30-Timed_text_and_associated_images_in_ISO_Base_Media_File_Format/trunk/>

Best Regards,
Courtney
______________________________
Courtney Kennedy
Engineering Manager, Media Sharing
mobile: 408-771-8615



> On Oct 17, 2014, at 3:10 PM, Courtney Kennedy <ckennedy@apple.com> wrote:
> 
> 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.
>>> 
>>> 
>