Slow seeking with matroska streaming

[Reckie]

Hi!

When streaming a matroska file through HTTP/1.1 and then seeking far out in the file, the VLC generates a lot of requests to the webserver with increasing Range header in stead of going directly anywhere near the actual position in the file where it should start playing.

This results in a long delay when seeking on a remote file, where neither the network bandwidth or CPU seem to be the bottleneck. The effect is not noticable when streaming from localhost however, but are noticable over a fast LAN. This is tested using a fairly recent SVN checkout on Windows platform.

This only seem to effect Matroska container handling, the WMV and ASF container handling does not have this problem.

The way I see it, it should be possible to do a first guess on where to start reading from just by looking at total length in time, total filesize and seek position. If this fails, then one can always fall back to the old way. Any comments?

The web server requests also seem to have an open end in the Range-header, and a Connection: close header. Would it be better to specify how much we want to read and to reuse the connection to the webserver?

We use VLC as a player in a project with an MPEG-7 database prototype with instant streaming of fragments. We have extended VLC with support for playing fragments using #hh:mm:ss-hh:mm:ss or #mm:ss-mm:ss syntax in the URL, and can upload or commit this patch if anyone is interested. We've also enabled VLC as a urlhandler in Windows so that VLC can stream these fragments directly from a vlc:http://the.url link on a webpage. Comments are welcome.

Terje Bakken and Jarle Snertindalen

[The DJ]

vlc has :start-time and :stop-time options for files that can support that.... I don't really think this belongs in the URL, perhaps as ?option-nam=value or something.....

[Reckie]

vlc has :start-time and :stop-time options for files that can support that.... I don't really think this belongs in the URL, perhaps as ?option-nam=value or something.....

Thank you for your reply, but I respectfully disagree. Look at how the HTML pages work, the fragment part of the URL (following the # character) is not even sent to the web server, but instead the fragment identifier tells where the browser should scroll down to on the web page. This is analogus to the start-time and stop-time options.

Example HTML: <a href="myfile.html#myanchor">Some page</a>

Example VLC: <a href="vlc:http://myserver.com/myvideo.avi#15:00-17:00">Video fragment</a>

With our patch to VLC, you can (with a simple .reg file) make VLC a url handler for all URLs starting with vlc: in Windows, and you can specify the start and stop time on the URL.

With your "?start-time=value" suggestion, this would be supplied to the server, why should it? This is an issue between the linking page and the VLC player, and the actual server where the media resides does not need to know where the client wants to start playing (other than getting the appropriate Range: header in the HTTP requests)

We would be very grateful if someone could comment on the slow seeking with MKV container issue.

[The DJ]

Still, having paramaters in the url seems like a bad idea. RTSP was developed for just this reason.


The seeking problem I don't know. I guess only fen or gibalou would know. visit the IRC channel is the advise to any developer working on VLC.

[Sigmund]

Slow seeking with http is indeed because of the connection not being reused. (starting a tcp connection takes some time (tree way handshake etc)). Seems to be a problem with how seek is handled with matroska files.

Thedj: how whould RTSP help here except if we had the same kind of fragmet support there?

Reckie: I think you should send you patch to vlc-devel@videolan.org in any case. If people there seem to like it it will get applied.

[The DJ]

RTSP was about the start time and stop time part being in a url. URL's are not meant to pass such paramaters. They developed RTSP to do a reliable dynamic and customizalbe setup of a stream.

We don't need more unstandard technology then there is already and I would hate to see VLC contribute to this mess. RTSP is perfectly able to handle such and many more a case. That VLC doesn't support RTSP 100% yet is a different issue, but it is the way to implement such a feature.

[Sigmund]

I've searched the entire RTSP rfc for the word "time" and didn't find anything to indicate this kind of information. More specifically I found a BNF specification of the RTSP url grammar which left no notion for anything like this but with this note:

Note that fragment and query identifiers do not have a well-defined
meaning at this time, with the interpretation left to the RTSP
server.

So I will have to say you are wrong and this is a welcomed contribution

[Sigmund]

If I'm wrong with this I kindly ask you to show me the correct way to link to a fraction of a clip using rtsp

[The DJ]

i'm pretty sure it's possible.

There are a number of other header fields, such as the time range of the presentation upon which the method executes (Range).

[The DJ]

And for SDP

Descriptions of session use the Session Description Protocol (described in Chapter ), which provides a generic technique for describing the details of the presentation, such as transport and media types of the stream, and the presentation content. Importantly, it also provides the start and end times of the presentation, so that the client can PLAY form and to any point in the presentation they wish.

[Sigmund]

This is all good, but it's not really the point here. The point is to link to a fraction of the stream. This could be done by downloading the sdp file from the rtsp server and editing it before puting it on the website but if that isn't messy nothing is.

[hans-jürgen]

As far as I know, streaming files over RTP affords hinting of the elementary streams in this file, at least that's how MP4 files are streamed. The player/client then uses the information in the hinted tracks for fast seeking etc. Streaming live events without an existing file which could be hinted uses the SDP file to describe the properties of the live RTSP stream. So maybe Matroska lacks a similar method to hint elementary streams in a file for RTP transport? I don't know either what Microsoft uses to achieve this for files streamed over HTTP.