The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. With the maturation of web services giving rise to a stable development platform, Montana State University (MSU) Library decided to build a digital video library with YouTube as the data store and app engine. As we started to sketch out the blueprint for the project, our first consideration was formalizing the requirements for the application and making sure these requirements could be achieved using the YouTube Data API. With these requirements scoped out and the API ready to provide all the necessary functionality, the library put together a development group to build the app. Ease of workflow and usability for the application had to be intuitive and straightforward as we were looking for a tool that would allow simple uploads and editing of metadata.
With the prototype application up and running in the fall of 2012, we had anticipated a number of advantages in using the web service and some of these advantages started to play out. Scale: Using YouTube as a production layer for our web deliverable videos was simple and effective. Discoverability: YouTube as a discovery platform and means to make content findable was an added bonus and the reach of our videos was reflected in YouTube analytics. Application of default tools and methods: Using the metadata index that is part of the YouTube Data API, we were able to create an interface that had a native, out of the box search functionality without having to build a local search index.
With this app, we could create the item view that you see above, but behind the scenes we could add microdata and RDFa data to give our videos newer richer, semantic meanings. Of course, the web service model and distributed nature of using an external service and data source to power a local application also had some drawbacks. Building the application to work well over a network, to route around latency issues, to use local files when necessary requires some development overhead and planning. Converting this data into something meaningful for a user was another significant piece of the development time.
This code template holds up for most of the application with some tweaks here and there to accommodate specific data and interface needs, such as the microdata template that is part of the item level view for the app. Setting metadata standards to organize and tag the videos was another essential requirement. With the results from this API query, we could build the internal navigation on the index page and allow the interface to adapt to new playlists (subjects) if they were needed in the future.
We actually used the interface layer of the application to reinforce the controlled vocabulary by pointing editors to the listing of subjects in the browsing sections of the application and reminding editors how assigning videos to certain playlists would make a video appear under a certain public list view. The broader metadata categories prescribed within the YouTube Video Manager interface were only helpful in classifying our videos for the broader Google and YouTube search indexes.
Using an external data service can be liberating, but also requires some extra thought related to architecture and performance for the app. Our library staff is active in creating and uploading videos, but there is no real need for dynamic, real-time querying of our YouTube data. With the caching routine started, a second snippet (cache-end.php) is included at the end of the file to be cached. With both snippets in place, the file is written to the cache directory and served on subsequent requests until the timestamp on the file shows that 3 minutes have passed.
Caching files was a primary way of ensuring snappy performance and responsible use for the app, but we put other methods in place to keep load times at a minimum. Along with the performance and bandwidth concerns, we looked into archiving and how to best provide a record of the application if an external service, like YouTube, went away or discontinued the API. By using a wget command and concatenating two separate API requests into an output file, we are able to produce a .json file that has all the metadata from the first 100 objects in our YouTube account. We see the work mentioned here as the first phase in the development of this digital video app. With a little planning, these REST-based web services can be used to create digital library apps that work in production settings. Furthermore we’ll also see how to create a Flex View-Based application, how to pass data between views and how to customize the ActionBar icons, all new interesting features of the mobile development process available from Flex 4.5. The project folder contains the xml descriptor file too, used in every Air for Android application to set a lot of application properties and permissions. The firstView property allow you to set the first View (in other words an mxml component) that will be automatically loaded when the application starts.
The default view, HomeView, is automatically loaded when the application starts and it will simply contains two buttons to load two different YouTube videos.
When users click one of these buttons, a new view (in other words a new page) is opened using the pushView method.


These events are automatically fired when a view is opened (activated) or closed (deactivated). I also added a dispose() method helping garbage collector to clean the memory and I have also added other useful methods to play and pause the video and demonstrate the AS3 YouTube API usage.
Instead, the actionContent property allows us to specify the icons on the right side of the ActionBar, used to play and pause the current video. Every AIR for Android application, created in both, Flex and Flash, uses an xml descriptor to set a lot of application properties and permission.
Soon I will write a tutorial to show you how to get videos from YouTube playlists, YouTube channels and how to get info about played videos. As I wrote to RomV, to play other videos (FLV, mp4…) you can use for example the progressive download technique or Flash Media Server, just like you do (more or less) in a web flash application. HOnestly I don’t remember if it already works without any modification or if I have destroyed and re-created the player after every orientation change, saving the player position (time) and using the seek method to start playing from the previous position. Now the reason i tell you all this is because when i used this fix with stagewebview framerate dropped quite badly when the rotation occured, i haven’t checked the framerate (stats) with your youtube example but it works good so far and i think i may have implemented it wrong in my seperate test (trying to push flex hard at the time)…nevertheless enjoy! But the youtube video played on my desktop when i chose to debug on it but almost played on my device and stopped. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. As with any digital library app, we needed a discovery layer that included browse, search, and item views for all objects.
This small working group included myself as lead developer and designer and Rhonda Borland, a library technician on the Cataloging and Processing team. The steepest part of learning curve was understanding how to parse the structured data that is the foundation of the YouTube Data API.
An added benefit of version 2.0 of the API is the public nature of the JSON feeds which do not require developers to authenticate requests to receive data and build applications.
In addition, we were able to use the chromeless YouTube video player (no need to code or download a video player script) which is fast and works across multiple devices and operating systems.
The onus is on the developer to find a way to design and shape the raw data returned into a meaningful software interface. What do the Terms of Service (TOS) say about ownership of data and how data can be consumed via the API?
However, once the application settings, API call, and parsing routine was in place, we were able to develop the other application views relatively quickly.
Once this code was in place, we then adapted the routine for other data views – search, browse, item, etc. We went with singular identifying keywords in the YouTube “tag” field to help create searchable keywords for the index. While the TOS is not overly restrictive, it does provide some rules for non-commercial use of the data and guidelines for attribution (recognizing somewhere in your design that YouTube data is making your application run). To keep application performance steady, we created a caching routine that stores API requests as local files for a few minutes.
With guidance from these tools, mod_deflate compression directive was added to the Apache .htaccess file to make sure all relevant files were as small as possible to reduce bandwidth over the network. We had an advantage in archiving the video objects as all the library video content had been created in house. As the account grows, we can adjust the archive by adding additional requests for the next 50 objects using the start-index= parameter. And finally, we think there is a real opportunity to repurpose the video data and format it to be harvested by other channels and distribution outlets. These types of web services can help a smaller web development shop build a scalable digital video library.
In the case of the YouTube Data API, we also get access to analytics and usage rates related to use of our digital video library app. Clark builds library web applications and sets digital content strategies for Montana State University Library.
Is there a way to play videos that aren’t on youtube or does something like that need a completely different approach?
The “Playlists”, “Search”, and “Videos” API methods could be applied to make this discovery layer. Rhonda consulted on metadata for the application and had primary responsibility for archiving the data. While authentication was not required for our read-only use of the API, we did register as developers and receive a key to help YouTube understand our use of their API.


Adding metadata in YouTube and then re-applying that data to our application with the API made for a simple and efficient cataloging process.
We were able to use the JSON data to rework application settings and data views to just about any user scenario: search, browse, embed, share, mobile, etc. Here’s an example of the PHP code template that allows us to filter and list all videos based on the assigned subject (list.php).
The other part of our development time was spent in understanding the YouTube Data API documentation and learning how to get the proper JSON-C results to return. This not only helped with performance, it made us a more responsible consumer of the API since we used only the data and API calls needed to run our app.
An example of the mod_deflate directive which compresses Javascript files, CSS files, HTML files, and PHP files is below. In the longer term, a CRON job will be set up to run this wget command and create the metadata archive automatically.
With the next phase of the project, we would like to integrate the YouTube Analytics API into how our videos are prioritized in search results and browse points. Reworking the JSON feed into a sitemap.xml file for the Google search index or an XML feed which would create a presence in iTunes or the Google Play store could be one more way to apply the API and get our videos found and watched. Using the administrative and processing tools that are default parts of YouTube services limits the need for additional staff to finalize video objects. We needed a tool that allowed us to create rich enough metadata records to provide subject and keyword filters for browsing and searching the objects in the video library.
Another working group within the library, the User Experience Group (UXG) was the sounding board for an early prototype of the application and championed its placement into production. Populating the search index with relevant metadata was important, but even more crucial was finding a way to organize the browse headings for the application. As an institutional account, the creator was always identified as “msulibrary”, our institutional username for YouTube. The first snippet (cache-begin.php) is included as the first lines in any file that needs to be cached locally. We also downloaded the web-processed .mp3 files from the YouTube Video Manager interface as derivative copies of our videos. On the management side of things, building an interface that allows for batch uploading and prescribes tighter metadata controls would be a logical next step. Learning to harness the metadata controls that are part of the YouTube Video Manager interface allows a small team to create filters and views around a controlled vocabulary to organize the digital library. When he doesn’t have metadata and APIs on the brain, He likes to hike the mountains of Montana with his wife, Jennifer, their daughter, Piper, and their dog, Oakley. The “Video Manager” component of the YouTube interface could be used to tag videos with keywords and group videos into prescribed subjects. It was a small (but agile) group that grew out of a singular research idea to apply a web service to a digital library production application setting. The “Playlists” component of the Video Manager interface allowed us to group sets of videos and proved to be the best method in this regard. Videos are identified as “web” or “original” and the filenames use the unique YouTube id that is assigned once the videos become part of the MSU Library YouTube account. Additionally, a more atomic approach to user authentication within the application would help in making it more suitable for multiple editors spread across different workspaces. And finally, writing simple, reusable code to parse and display the structured data returned from API calls, enables a single developer to create an HTML interface that has all the features of a simple digital library video application. And finally, we needed a simple video editing and uploading tool that would work in any web browser.
With these methods in place, digital library development is within reach for all types of libraries. Again, the “Video Manager” allowed for editing of all video details and enabled uploading of videos from just about any internet-enabled device. With these video and image objects archived, we needed to find a way to preserve all of the metadata that was part of the YouTube data store. A simple command line procedure allows us to make an API call and store a text file with all of the data.



Local mobile marketing trends blog
Avs video editor 7.1.2.262 activation code
Local online display advertising


Comments to «Youtube chromeless player api javascript»

  1. FB_GS_BJK_TURKIYE Says:
    Different from regular accounting give a big reach to a marketer only.
  2. BOP_B_3AKOHE Says:
    For organizations thinking about marketing automation for media.