Progress bar for video dowloads? (1 Viewer)

[Wiesel]

Thats great to hear, thanks!!

Are the gui and graphbuilder managed in the same thread? If not you could at least display an animated loading screen so the user knows >something< is happening and MP isn't stuck.

 

[offbyone]

I already tried to build the graph in a seperate thread and it still locked up

 

[Wiesel]

I just tried the lastest svn version and the progress bar really works great, also some flv streams that didn't work for me on v0.20 with SAF5 (e.g. Pro7 Desperate Housewifes) are now working as well

I just got another idea for an improved user experience... 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!?

 

[offbyone]

In plugin config you can already set a buffer level. The playback will be delayed and waitcursor shown until the set percentage has been downloaded.

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.

 

[Wiesel]

I noticed the buffer level setting but it doesn't seem to do anything. Playback starts immediately, no matter what I set the percentage to (eg. YouTube or Apple Movie Trailers)...

 

[offbyone]

Good bug finding I'll fix that with the next commit.

 

[Wiesel]

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.

Does that mean that the buffer is handled by some filter, not by you?

edit: nevermind, I just found it out

I've never done anything programming related with DirectShow but after taking a look into MSDN, wouldn't this be a solution to detect buffer drainage:

Currently, at least in case of a file source url, the graph as I read it from the sources looks something like this: "File Source (URL)" > unknown demux/decode filters > renderer.
What if we just put a custom filter in between the file source and demux/decoding stage ("File Source (URL)" > buffermonitoring filter > demux/decode ...) that implements IAsyncReader, this way we would know how big the file is, how much has been buffered and how much the subsequent filter has read. If readBytes == bufferedBytes we know that the buffer drained and ths way playback could be paused for some time. If there isn't more magic behind that I can't see, it would be pretty easy to implement, as the read requests would just have to be passed through.

 

[offbyone]

The only problem is: Who's gonna develop a directshow filter? That's a really tough one. And I don't have enough time and don't want to wander on the C++ site.
But, as this is an opensource project ... someone could ...

 

[Wiesel]

If you think that my proposal would theoretically work, I'll take a look into it. I've never programmed in C++ (just ansi C) but if it turns out that the implementation isn't too hard I'll give it a try.

 

[offbyone]

I am not sure if you idea works. IAsyncReader might not be possible in our scenario.
There are two ways data can go through the directshow graph. Push or Pull.
I don't recommend going blindly into developing this, with directshow filters you have to do a lot of reading and research before wasting even more time.