After closing and nulling objects the video continues to load.

[delp]

I'm using the OSMF for playing back videos, and when the user closes
the video I stop the player, remove the mediaContainer from the view &
any listenerers I've set up.
Then I'll null the mediaElement, mediaContainer and the mediaPlayer to
clean things up and stop the video from playing. The video does stop
and you can no longer hear the video but I've noticed that from using
Fiddler that the video still gets streamed in.

So I'm presuming that the loader is still hanging around after
everything else has gone. Where is the loader so that I can stop it?

My mediaElement is being created with the following line
( mediaFactory.createMediaElement( new URLResource( value ) ) as
VideoElement; )

Any hints?
Thanks.

[Danny]

in reops.as there is a NetConnection object that is used for the
stream. Have you tried explicitly closing the netconnection?

[turbidity]

Hi,

If you're able to see it with Fiddler, is it a progressive video
rather than a stream? If it is streaming, then what Danny says would
work, although it should be closed by the stop call on the player. If
it is a progressive video, then the loader may still be working behind
the scenes. It looks like you can stop any in progress loading of a
progressive video by getting the LoadTrait off of the MediaElement
with its getTrait method and then call the unload method on that
LoadTrait.

Hmm, actually, after doing some digging, it looks like a stop is only
called on a NetStream by the NetSTreamPlayTrait when the media has
completed or there was an error, so you may need to do a close on the
NetConnection, though that may not be the best if you're going to play
more media after the first one.

Nils

[Danny]

yes, perhaps closing the NetConnection is a BFI approach (brute force
and ignorance) although the mediaFactory would create a new connection
if you went to load another video would it not, and the overhead is
not that large. However Ken kindof indicated he was closing things
down altogether by nulling out the player...perhaps that was an ever
more drastic attempt and shutting down the flow ;-)

It looks like the OSMF NetLoader has an unload method
(executeUnload(LoadTrait)) which is used to unload and close the
NetStream at leas according the inline comments.

I would argue that this is plumbing that should remain "under the
covers". Those extending should not need to know the type of stream
or download, just perhaps a single method exposed that can stop the
loading, or handled automagically when the user stops or closes the
player. "closing the player" is application specific though. In my
case, I will have the player in a canvas but stopping the play or
completion of the video should stop all loading as would removing the
player from the canvas.

There should certainly be a cleanup method for the player that handles
removal of all listeners, stops loading, releases network resources
etc., no?

> > Thanks.- Hide quoted text -
>
> - Show quoted text -

[delp]

Thanks for all that info, I'm doing progressive download (or actually
pseudo streaming ). I'll give those things a go and advise on what
solves it, providing I do solve it :)

[delp]

OK, well I've sorted it. Perhaps not the cleanest but it works.
I've created my own SWC file from the OSMF codebase and I've added the
following to the VideoElement class.

private var stream : NetStream;
public function closeVideoElement() : void
{
var loadTrait : NetStreamLoadTrait =
getTrait( MediaTraitType.LOAD ) as NetStreamLoadTrait;
loadTrait.connection.close();
stream = loadTrait.netStream;
stream.close();
loadTrait.unload();
}

calling this actually stops the download that is in progress.

Thanks Kenneth.

[turbidity]

Hi Kenneth,

I would recommend against altering the OSMF code. When OSMF gets
updated, you'd have a harder time updating your application. I would
recommend that in your main application file you could define the same
method. The getTrait method on a video element is public so you could
call it when you needed to from the main application. That way you can
update REOPS and OSMF without having to redo your code in the video
element. I'm glad that you found something that works, though.

Nils

[Danny]

I used a similar approach in building an osmf/reops swc library, but
rather than altering any osmf classes directly, I extended a
particular class to add setters/getters to expose protected or private
objects I needed or added some new methods to my extended class.

So in your case you could do
public class VideoElementKen extends VideoElement

...and then of course you'd have to use VideoElementKen in the classes
that reference the videoElement so you might need to extend a few more
classes until your dependencies are exhausted and the main application
file can reference the new classes rather than the originals. You
could add methods like you've done or override existing ones.

But since getTrait is public, you have the better option that Nils has
suggested. In my case, no such luck, so I had to extend PlayerCore
and SkinContainer.

--Danny

> > > > > - Show quoted text -- Hide quoted text -

[delp]

Thanks, yes you're quite right I shouldn't really have put it in the
actual VideoElement class. Being a bit lazy there while just trying
to get it to work. Much nicer to move it outside any of the OSMF code.

cheers.