Step 3: Animate the frames at the client, response to user interaction and request for more frames if needed. Step 2: Transport our frames over HTTP to the client’s browser. Step 1: Getting the frames, frame rate and other necessary information from a video file or a live stream From what we planned, we divide our efforts into smaller steps: If we had all frames of a video clip in our browser, we could display them one after another at a frame rate and there we had our video playing! This sounds like a plan, let us see how we can translate this into an actual web application.
AJAX VIDEO PLAYER LIKE VLC PATCH
Live sample: Watch the Snoopi at pumpkin patch from AJAX Video Player ! Using the code BackgroundĪ video is a sequence of framed images that are displayed at a rate one after another. The AJAX video player can broadcast live (using an XML service) or cached video streams (XML file) to a variety of users on different platforms and browsers.
This AJAX video player is a scripted prototype-based video player that runs in JavaScript enabled HTML browsers that support Base64 encoded images (almost all modern browsers but IE). I know this sounds very abstract, that is why I decided to write an AJAX application that does the most common task associated with plug-ins: video player. Even though JavaScript language, as the version of today (the latest 1.7 in Firefox 2), is not fully capable of performing the tasks associated with plug-ins, I believe the future versions can offer enough browser integration and supporting libraries which eliminate the need of using complied plug-ins. While using plug-ins seems to be inevitable for pages with rich contents, AJAX has created high hopes in my opinion. This is not to mention security, accessibility, platform independency, and web standards issues that are involved in pages that use plug-ins. Unlike Hyper Text Markup Language or JavaScript, plug-ins are mainly compiled binaries and they are difficult to customize. Plug-ins are executed outside of your application’s context. Here is where the browsers make use of plug-ins to overcome these boundaries, and also add new troubles! Playing video clips, displaying RSS fields, and updating time sensitive data are considered common features of a webpage nowadays, but yet, we are bounded to HTTP capabilities. So, why would we need data streaming over HTTP? Because, we build our web applications over HTTP. However, this does not pose a problem because there are other UDP-based protocols that can be used for streaming where it is needed. As a result, there are few real world applications that use HTTP for streaming data, and normally, an additional protocol is built on top of HTTP for reconnection and error detection. HTTP 1.1 added support for streaming through keep-alive header so data could be streamed, but yet for performance proposes, the majority of implementations including ASP.NET tend to buffer the content, send it, and close the connection.
Usually, HTTP responses are buffered rather than streamed. HTTP communications are stateless, and they take place over TCP/IP where there is no continuous connection between the ends. In reality, HTTP was not designed for data streaming. Streaming is mostly referred as a delivery system for media content or dynamic data where it is beneficial to begin processing while data is being delivered. Step 3: Animate the frames at the client browser.Step 1: Getting the frames, frame rate and other attributes of video clip.
0 kommentar(er)
