questions for designers
Novak, Alexey
anovak at ocadu.ca
Wed Mar 6 16:09:52 UTC 2013
Hi Colin,
Thanks a lot for your replies they clarify lots of things for me.
So if I understand you correctly, Amara component can use the first listed video source in order to pull available list of captions. VP can do this since most likely all sources listed in the videoPlayer would point to the same videoID and only one source would be used by the VP anyway.
We could possible add an extra logic to deal with the case you mentioned, when list of URLs associated with the video have different videoIDs. For example we could query each source to get the videoID and chose the source which has the most frequently seen id. Although this extra logic sounds like an overkill, since it is a solution (possibly for a very rare case) with potentially adding extra jsonp requests. What do you think?
As for the videoID, I am currently using Amara API 2.0 (http://s3.www.universalsubtitles.org/docs/api.html) to get the list of available captions using just a video URL. In 2.0 when you do a request using a video url it returns the list of available captions AND videoID in one request (as well as extra data such as description, when created, array all_urls, original language, title, …).
While in API 1.0 you have to do two JSONP requests in order to get videoID first and then captions using earlier obtained videoID.
Thanks,
Alex
On 2013-03-05, at 6:00 PM, Colin Clark <colinbdclark at gmail.com> wrote:
> Hi Alex,
>
> Some comments inline...
>
> On 2013-03-05, at 4:15 PM, "Novak, Alexey" <anovak at ocadu.ca> wrote:
>
>> 1) Currently Amara component uses a video source options to query for available captions on Amara.org . Most likely the integrator would want to include multiple source for different video file types (Example: integration can specify .webm file to support FireFox, .mp4 to support Chrome/Safari/IE and youtube link for browsers which do not support HTML5) in order to support multiple browsers.
>
> I think it's not typical that the same video will have three separate URLs, though it is possible. Typically, a user will choose to either host their video themselves (encoding it into both WebM and H.264 formats for cross-browser compatibility) or they'll use YouTube. It seems unlikely to me that they'll want to use all three, especially since the VideoPlayer is designed to ease some of these cross-browser issues.
>
> Unless I'm mistaken, MediaElement.js will actually do the work of handling non-native video codecs. I think a user at this point can actually get away with choosing a single codec (likely H.264, since even Firefox has begun adding support for it now) and it will play correctly across all browsers using a Flash-based polyfill. Justin or Michelle, is that correct?
>
>> How would the Amara component work if there are multiple sources? Which source should it use in order to pull the available language list? There are couple of potential solutions for this problem but I am not sure which one works best if any.
>> • Amara component would check every source until it finds the first which has captions on Amara.org and only applies them. This solution introduces importance of the sequence in which sources are listed by the integrator.
>> • Amara component would check every source and construct a list of available languages using every single source. This solution could be very costly since VP would be querying every source to assemble the language list. Furthermore, which language has the priority if two sources have two different captions for the same language type?
>> • Amara component checks every source which is marked by an integrator for checking Amara for available captions. The same problem as above, which language has the priority if two marked sources have two captions for the same language type?
>> • Any other ideas
>
> As I understand it, Amara's API supports assigning multiple URLs to a single video id:
>
> http://amara.readthedocs.org/en/latest/api.html#video-url-resource
>
> So, if you know the Amara ID of the video, you should be able to query the /urls resource and get back a list of the URLs associated with it. I assume this resource exists to support exactly the use case that you mention, i.e. the same video encoded as both WebM and H.264.
>
> If you don't have the Amara video ID, it looks like you'll need to make multiple requests to the /videos resource with the source URLs you do have, and use that to retrieve the appropriate video ID.
>
> If, for some reason, you find that the same video has different IDs for each format, there is also an API to update the list of URLs associated with the video. That will likely be an edge case, I believe (if it happens at all).
>
> So, assuming all of this holds up in practice, you'll actually be querying Amara for a list of languages for a video, not for a video URL. You thus shouldn't have to worry about consolidating multiple lists of languages in any but the most extreme cases.
>
> I hope this helps,
>
> Colin
>
> ---
> Colin Clark
> http://fluidproject.org
>
>
More information about the fluid-work
mailing list