Progress bar for video dowloads? (1 Viewer)

[Wiesel]

Did a bit of reading about DirectShow and I now more or less get what's going on there. File Source (URL) is a pull source filter (like all source filters?!?) since it implements IAsyncReader. Push filters implement IMemInputPin. So far it shouldn't be a problem to implement a monitoring filter (or filter wrapper), but there's still a much bigger problem: this solution would only work with sources implementing IAMOpenProgress, which WM ASF Reader doesn't (don't know about the MediaPortal File Reader)... that would lead to an inconsistent behaviour...

 

[offbyone]

WM ASF Reader is mostly used for mms:// streams. This protocol allows random access to the file on the server (seeking possible) - so the buffering stuff is not needed on that. (That filter is poorly implemented anyway - from experiance and google).

 

[peque]

What do I exactly need to see progress bar?

I installed MP 1.1.0 RC3... is it enough, or we must wait for OnlineVideos 0.21? Or maybe an skin update also? (I installed also last StreamedMP, for MP 1.1.0 RC3)

Thanks a lot!

 

[offbyone]

You will need OnlineVideos 0.21 and an updated StreamedMP skin for the OSD.

 

[peque]

Which I must asume are not still public? Last StreamedMP files don't include this?

 

[greybox]

Is it supposed to work with the default skins?

 

[SilentException]

Blue3wide was updated for progress bar display on OnlineVideos Google Code SVN..

I updated Black & White 1080, Black Glass and Black Glass Nova on Google Code SVN..

StreamedMP was also updated on Google Code SVN but don't know about latest released version.. My guess it includes it because it cannot break anything even if you're not using latest SVN version of OnlineVideos..

 

[Wiesel]

It's been some time since my last post here as I unfortunately just have very limited time, but I did a bit of experimenting and do now have a running proof of concept... I'm talking about this issue here:

would it be possible to let the buffer fill to a certain level until the playback starts, and if the buffer drains during playback to pause again until that fill level is reached? For example when watching Apple Movie Trailers on 1080p the stream delivery rate for me is just a tad slower than the playback rate which results in an annoying constant "jidder"... I'd rather wait one time for a few seconds until the stream continues, and I'm pretty sure I'm not the only one!?

Stopping Playback when buffer drains is not so easy, because that is information the filter graph doesn't give. I could match a % of downloaded bytes with the percent of current playback position, but on variable bitrate clips, this isn't equal.

Are you even interested in integrating this functionality into OnlineVideos? That issue really bugged me so I HAD to find out how to solve it, but my concept is far from perfect and I don't want to spend any more time if it's of no use

 

[offbyone]

I'd very much like to know what your concept on this is! If you have tried latest version of onlinevideos, you'll have noticed that the pre-buffering is already in there. I'm interested how you solved the buffer drainage detection.

 

[Wiesel]

Actually there are built in events in DirectShow to detect buffer drainage (EC_BUFFERING_DATA, EC_STARVATION), but unfortunately none of the filters involved in my tests (YouTube with MPC FLV Splitter & ffdshow) signals it

I have now hacked together a C# wrapper for the "File Source (URL)" filter, but it could be used for any source filter supporting IAsyncSource. What I'm doing is intercepting the call from the splitter to the source filter (IAsyncRead.SyncRead) which gives me the current byte-position in the source stream, and if that position is beyond the buffered part of the file I know the buffer of the splitter has drained (it may need a more elaborate logic but basically that's it).

The biggest problem now is that my filter-wrapper doesn't connect automatically in the graph, but if I manually connect it to a splitter it works. Maybe it might be a better idea to implement it more as a proxy filter between the source and the splitter instead of wrapping the source... I'd have to test that.