Post Meeting Questions (Nov 19th)

<p>1) I would imagine that audio or video streamed over RTMP doesn't have an ILoadable trait.</p> <p>2) I see what you're trying to achieve here; one piece of content defined as multiple MediaElements, with varying seek times for each. In between these elements in your SerialComposition you want advert MediaElements. My feeling is that the way compositions and elements work at the moment, you wouldn't be able to achieve this 'out-of-the-box' but such is the nature of OSMF you could easily extend VideoElement so that it 'completed' once the specified seek time was reached, causing a switch to the next element in the composition. Alternatively, you could look at approaching it in a different way, and leverage the new Cue Point features added with the TemporalFacetEvents.</p>

<p>1) Actually, streamed audio and video have an ILoadable trait.&nbsp; The term "loadable" is a bit misleading in the streaming case, in that it implies the transfer of bytes.&nbsp; But the intent of ILoadable is to encapsulate all initialization logic that needs to take place before the media can be player.&nbsp; For streaming media, this means calling NetConnection.connect and potentially cycling through various port/protocol pairs.&nbsp; We considered calling the trait "IInitializable", which is technically more precise but doesn't roll off the tongue very well.</p> <p>An example of media that doesn't have ILoadable would be a custom MediaElement that encapsulates a transition or effect.&nbsp; Transitions don't need any initialization (they generally just do a tween), so there wouldn't be any value in including an ILoadable trait.&nbsp; Another example would be a "ping" MediaElement which is used to ping a server for tracking purposes.&nbsp; (Typically these MediaElements would be integrated into a SerialElement for timing purposes.)&nbsp; There's no need for any set up prior to the ping, so no need for an ILoadable.&nbsp; The BeaconElement class in the framework's "tracking" package is an example of this.</p> <p>2) SerialElement has addChild and removeChild methods, which are designed to work even when called after playback has begun.&nbsp; So you should be able to create a SerialElement with a single piece of video, and modify it in the course of playback to append new MediaElements for the mid-roll ads.&nbsp; One of the hot-off-the-presses features addresses the second part of your request, specifically the ability to play a subset (subclip) of a video.&nbsp; The quick summary is that you can assign metadata to the IMediaResource that gets passed to a MediaElement to indicate what portion (subclip) of the video to play.&nbsp; There are limitations in what OSMF will support (e.g. streaming video and audio only).&nbsp; The feature has been checked into the public trunk, and will be officially available in the next stable release (aimed for early December).&nbsp; For details on usage, see the <a href="http://opensource.adobe.com/wiki/display/osmf/Subclip+Specification">Subclips Specification</a>.&nbsp; A few running examples have been checked into the ExamplePlayer sample app, the most relevant to your use case is called <a href="http://opensource.adobe.com/svn/opensource/osmf/trunk/apps/samples/framework/ExamplePlayer/org/osmf/examples/AllExamples.as">"Serial Composition With Subclips"</a>.</p>

<p>ILoadable does seem misleading - generalized for the purposes of simplicity, but likely to cause confusion further down the line... For example, an ILoadable has a loadState property, of which possible values are Loaded and Loading; how would these be presented for a stream?</p> <p>Given the discrimination between progressive and streamed audio, would it not be better for consistency to do this for video too?</p> <p>The mutable SerialElements during playback is useful, but sub-clipping seems better for me... If your server wanted to be responsible for creating a playlist that comprises of multiple parts of the same video, and some mid-roll ads, this would make it possible :)</p>

<p>For streams, the LOADING state maps to the process of establishing a valid NetConnection (which might involve cycling through different port/protocols).&nbsp; LOADED maps to having a valid/connected NetConnection.&nbsp; In terms of terminology, keep in mind that this trait is intended to cover all media types that need to be initialized, including video (progressive or streaming), audio (ditto), images, SWFs, or custom media types with their own unique initialization processes.&nbsp; Streaming media is probably the one case where "loading" isn't the right term.&nbsp; But for most of the other types (image/swf/progressive), it's probably more appropriate than a term like "connecting".&nbsp; With that as background, do you (or anyone else) have a better name than the current one?</p> <p>Not quite sure what you mean about the discrimination between progressive and streaming audio?&nbsp; Both have the ILoadable trait, it's just the underlying implementations that differ a bit.</p>

<p>Thanks for the detailed reply Brian.</p> <p>By discrimination, I was referring to the NetLoader and SoundLoader types that can be used with AudioElement. You can't load a progressive audio track with NetLoader, yet you can load a progressive video with NetLoader. I appreciate they all implement ILoader, but given that a distinction is being made between streaming and progressive loading with audio, should the same not be true for video, and introduce a new IInitializable interface?</p>

<p>There are different loaders for progressive vs. streaming audio primarily because the underlying implementation (flash.media.Sound vs. NetStream) differs.&nbsp; For video, both progressive and streaming use NetStream.&nbsp; I think what you're (perhaps indirectly) pointing out is that these implementation details are bleeding into the client API -- i.e. why not just have an AudioLoader which works for both progressive and streaming.&nbsp; That's definitely something we should consider (and if you agree, feel free to file a bug).</p> <p>I'm still not quite clear if we're on the same page with IInitializable.&nbsp; I was suggesting that we might want to rename ILoadable to IInitializable, but it sounds like you're suggesting we have both (the former for one set of cases, the latter for a different set).&nbsp; Is this correct?&nbsp; If so, what's the distinction between the two, and how would you expect an implementor to know which one to use?</p>

<p>The more traits the better right?</p> <p>Seems like there should be a trait for IInitializable which applies to all media that needs to be initialized in some way. This will initlialize connections or sockets or http requests or whatnot.</p> <p>Then have another trait, ILoadable which applies specifically to media elements which have a byteLoaded and a bytesTotal property. I.e., anything that is not streaming.</p> <p>Streaming Audio and Streaming Videos would only have the IInitializable trait, while progressive Video and progressive Audio and images, will have the Iinitilaziable trait as well as the ILoadable trait.</p> <p>You would know to use the ILoadable trait because you will want to grab the loading events which tells you how many bytes have been downloaded, while with streaming video/audio you might want to use it, but such data will not be available, and thus you won't be able to use that trait on them.&nbsp; (based on the URI)</p>

<p>Got it.&nbsp; What you're describing is more or less what we have now, with some differences in terminology.&nbsp; Our ILoadable represents what you describe as IInitializable, and our IDownloadable represents what you describe as ILoadable.&nbsp; Of course, as soon as we implemented this we became unhappy with the terminology, and started looking for ways to make things clearer.&nbsp; (I think the terminology you suggest is generally an improvement over what we have now.)&nbsp; And worse yet, the separation of the two traits led to some implementation headaches, in that it's much easier to implement ILoadable and IDownloadable together than to separate them.&nbsp; So our current theory is that the two traits ought to be one, and that a client should simply check the bytesTotal property to see whether to show the download progress bar (show if &gt;0, don't show if ==0).</p> <p>That being said, this exact issue (whether to merge or split certain traits, and what names to give them) is undergoing heavy debate right now, and your feedback will be really helpful.</p>

<p>Well, it's more than just the bytesTotal property isn't it?&nbsp; (that was just an example of a day-to-day usecase)&nbsp; It would be nice to be able to handle streaming audio the same as streaming video, and progressive audio the same as progressive video.&nbsp; (it's always annoyed me that the apis were so different for the two of them).</p> <p>But it may just be that ILoadable and IDownloadable were missleading names for what the traits really represented.</p>

<p>"<span style="font-family: Arial, Helvetica, sans-serif; font-size: 12px; color: #424242; ">Transitions don't need any initialization (they generally just do a tween), so there wouldn't be any value in including an ILoadable trait. "</span></p> <p><span style="font-family: Arial, Helvetica, sans-serif; font-size: 12px; color: #424242; ">Based on this sentence here, from your first explanation. &nbsp;(Thank you for that btw), it almost sounds like ILoadable should really be IInitializable or IInitable. &nbsp;It sounds like the ILoadable trait is used to defined if something needs to be initialized before it can "start" or become "active".</span></p> <p><span style="font-family: Arial, Helvetica, sans-serif; font-size: 12px; color: #424242;">From a practical player perspective, we often want to show a "loading" icon/screen or show a loading progress bar for progessive videos/thumbnails. (i.e., we have a set amount of data to load and we want to show/wait for that progress to complete)However with streaming, we have no "totalBytes" to create such GUI elements with. &nbsp;So using ILoadable data for both of those use cases, seems a bit odd, unless there was a way to know within that trait if "totalBytes" is available or not.</span></p>