Progress bar for video dowloads? (1 Viewer)

[offbyone]

I can see 2 benefits from knowing if the current playback's byte-position in the stream:
a) If buffering is a tad slower than playback, buffer will drain often and playback will be juttery. This could be detected and the graph paused to allow more to download before resuming playback.
b) --not sure on this one though-- If a seek operation goes beyond the buffer, that this seek could be canceled Right now, if I seek almost to the end of the clip in MediaPortal, the playback will freeze until the buffer has reached that position and I can't "seek back".

Right now, I can only manually watch the buffer progress and decide if I need to pause or can seek from the look of the progress bar in MediaPortal.

Does the "Render Pin" action work on your filter? Currently I'm adding the FileSourceUrl manually and then render the pin to build the graph automatically.

One more thing to think about:
If you use the flash player on YouTube for example, you can set the playback postion somewhere in the file and it jumps pretty fast. I think what they are doing is another http request of the file but starting at a certain byte range, like resuming. If we had a source filter that could mimic that, it would also be really nice

 

[Wiesel]

I can see 2 benefits from knowing if the current playback's byte-position in the stream:
a) If buffering is a tad slower than playback, buffer will drain often and playback will be juttery. This could be detected and the graph paused to allow more to download before resuming playback.
b) --not sure on this one though-- If a seek operation goes beyond the buffer, that this seek could be canceled Right now, if I seek almost to the end of the clip in MediaPortal, the playback will freeze until the buffer has reached that position and I can't "seek back".

Indeed, a) is the reason for writing the wrapper, and b) is a very good idea which I haven't thought of This would be perfectly possible with the current wrapper.

Does the "Render Pin" action work on your filter? Currently I'm adding the FileSourceUrl manually and then render the pin to build the graph automatically.

No, that's the problem I described before that I currently have. The automatic rendering doesn't work yet, and I have no idea why it doesn't. Currently I add the wrapper and splitter to the graph, connect them manually, and then render the splitters output pins. I don't know if and how this problem can be resolved, but I think it can be avoided completely by changing the wrapper to a proxy or implementing a completely new source filter.

One more thing to think about:
If you use the flash player on YouTube for example, you can set the playback postion somewhere in the file and it jumps pretty fast. I think what they are doing is another http request of the file but starting at a certain byte range, like resuming. If we had a source filter that could mimic that, it would also be really nice

Yeah this is what they do. Actually when I began my experiments I wanted to write a completely own source filter, but then I figured that 1. wrapping would be easier, and 2. an own implementation might not be as universally useable as the File Source URL filter. But in general, writing a file source filter shouldn't be that hard, it could be even implemented in pure C#.

 

[offbyone]

Just an idea:
There are entries in the registry how automatic graph building is done. You might have to add quite a few entries.
Check this article: Registering a Custom File Type

Another one:
The FileSourceUrl filter might set some properties on it's output pin after it got the stream which you might need to copy?

 

[Wiesel]

I guess the custom file types would only help in case we don't know the source filter or need to automatically choose between different ones, but since in our case the source filter is known and added manually to the graph it shouldn't make any difference.

In my wrapper I'm just handing the calls over from the source filter (output pin) to the splitter filter (input pin) and vice versa, so my wrapper doesn't do anything at all except intercepting the calls and reading the passed parameters where I need them. The whole setup/connection/processing logic end everything else is still in the file source url filter. Another interesting fact is that although the graph is working as expected when connecting the source manually, graph studio doesn't show me the connection between the source wrapper and the splitter (no connection line drawn), although the properties of both the source output pin and splitter input pin display "connected".


I'm actually starting to think that writing a source filter from scratch would be the best solution because it would kill a few birds with just one stone, primarily for the "random access" feature of http streams, and the other two features we just talked about will be there for free. Are you using the file source url filter just for http downloads or are there other protocols involved as well? I see mms and rtsp are handled separate but maybe there's still more protocols than http left for the filter to handle.

 

[offbyone]

There aren't many protocols how webvideos are delivered currently.
It boils down to:

• http - file hosted by a webserver -> File Source Url is used
  
  
• mms - Microsoft streaming server -> WM ASF Reader is used
  seeking anywhere possible due to protocol
  
  
• rtmp - Adobe streaming server -> locally restreamed as http
  (not best solution but no filter exists - with special filter seeking anywhere would be possible)
  
  
• rtsp - Not used often, I think something from Apple? - currently not possible, no free filter (again I think)

Writing a new source filter for http would be great. Something is was hoping for someone could do. The current one has some problems with resuming, chunked transfer and more things. But I recon it's a lot of work to improve something that is already working (one reason I stayed away from it).
But if you get enough experiance from it, we might also get a filter for rtmp out of it

 

[Wiesel]

Ok great, I was asking because the .NET WebClient/WebRequest just supports the http(s), ftp and file protocols by default, but custom implementations for other protocols can be added. I'll see if I have some time to play with it. Could you explain what exactly the problems are that the current filter has, beside the obviously missing functionality?

 

[offbyone]

I'll have to dig deeper into the tests I did a while back (too long to remember correctly) but I'll try to write up a list of problems.

 

[Wiesel]

Thanks, that would be nice so I know what to specifically take care of...

 

[DieBagger]

• rtsp - Not used often, I think something from Apple? - currently not possible, no free filter (again I think)

Shouldn't MP be able to play rtsp when the tv server streams it's content with rtsp?

 

[offbyone]

I have tried once to use the MediaPortal Filter for anything other than the TVServer stream and failed I think it has too many assumptions coded inside that it only connects with TVServer.