questions for designers

Justin Obara obara.justin at gmail.com
Wed Mar 6 14:09:39 UTC 2013


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?

First off, there are some bugs associated with the flash player, but we should be able to take care of those in future releases. As to the format, I'd suggest going with h.264. In Safari we have no support for playing webm. If you only supply a webm video, you will be provided with a download link instead.

> 
>> 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
> 
> 
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work




More information about the fluid-work mailing list