[vlc-devel] MPEG Duration/Playback Ending?

[Rémi Denis-Courmont]

   Hello,

On Wed, 04 Nov 2009 20:34:43 -0500, Developer <developer at noknok.net> wrote:
>> 1. During an acquisition via HTTP (eg:  http://www.xyz.com/movie.mpg),
>> VLC inititially requests the file from 0-, then does a secondary
>> request 200,000 bytes less then size.  I am assuming this is so it can
>> determine the estimated time length.  What specifically is it looking
>> for in that second request?  It doesnt seem to be a TIMESTAMP_PACKET,
>> so I am assuming a VIDEO packet, or an AUDIO packet to which to read
>> the timestamp from?

I don't know. The MPEG-PS file parser probably thinks that this data is
useful, and sees that the input stream support seeking.

(...)
> Since playing some, in regards to #2 above.  It has to do with the range
> requests.  To further my question and explanation:
> 
> 1. VLC Send HTTP-GET Request with RANGE of     200000-
> 2. I receive the request, though I currently only have say 80000 bytes
> in my source file (which is actively growing).
> 3. What I currently do, is accept the request, and respond
> PARTIAL-CONTENT with the range quoting what was requested, BUT I
> actually just stream data beginning at 80000 (my current size of file -
> which as explained is a live source and growing).
> 
> In doing this, VLC is doing as it should with the LINEAR STATUS BAR
> position, as it believes I am sending from position 200000.
> 
> Now, when I change this, by changing my response to show my STARTRANGE
> as 80000-, VLC does not like/nor accept this, and starts from 0 again.

It is not clear to mean that sending a different range from the requested
one is even legal in terms of RFC2616.

> Since VLC can seek forward and backward, could it not ACCEPT my
> different STARTRANGE position in the response, and adjust its position
> accordingly?

This is not allowed by the byte stream abstraction (open, seek, read,
close), which sits between the HTTP input and the MPEG-PS file parser. In
principle, the HTTP access could just skip data until it reaches the
actually requested offset. But that would not solve your problem anyway.

In theory, you can always change the API, but I doubt anyone would ever
undertake this.

-- 
Rémi Denis-Courmont