[vlc-devel] MPEG Duration/Playback Ending?
developer at noknok.net
Mon Nov 9 15:04:26 CET 2009
>> I have a question to which I am hoping I can be enlightened on.
>> 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 ask because am attempting to build a pseudo-live streaming server
>> for MPEG2 (VOB), using a live source. In the initial request I pass
>> back in the HTML a length of "x", which is actually 1/2 of 1% bigger
>> than the what the resulting file will be. I need to also now send
>> back in that 2nd request request appropriate frames with timestamps
>> matching my estimated length.
>> This in fact works - somewhat - in that, on a a live stream, when I
>> get that 2nd request, I am serving the last 10,000 bytes of a
>> previous 5 minutes long MPEG video. I add 0xFF to the rest of it
>> matching the request i got (so if VLC asked for the last 200,000
>> bytes, i send my 10,000 + 190,000 0xFF) and VLC accepts this, and in
>> the playback window i see it has estimated the video at 5 minutes (as
>> that is what the length is of the video i clipped the ending from).
>> I of course need to dynamically be able to set the timestamps or
>> whatever in that chunk to whatever my real estimated time is going to
>> be. So needing to know what it is VLC is looking for.
>> 2nd issue. Event though the above works, when I fast forward say 2/3
>> (3.5 minutes) into the slider scale, and say only having 1/3 (90
>> seconds) the file available, when I get the HTTP Request moving to
>> that position, I just serve data from the point at which I am in the
>> live feed. VLC accepts this, adjusts the CURRENT POSITION TIMESTAMP
>> NUMBER in the lower right corner correct, so if i really served data
>> from 90 seconds on, it displays that appropriately, BUT (1) the
>> slider bar does not correctly adjust to 90 seconds, it stays at where
>> I moved it to. This is a problem because it seems when the BAR
>> reaches the end (not the stream), VLC stops playing, even though I am
>> still streaming the data to it.
>> I know this is probably (not even a little) but a lot off kilter, but
>> being able to play LIVE (meaning truly live, not recorded and
>> streams, but live video streaming) streams, with fast forward/rewind
>> is real important, and using a web based solution (http progressive)
>> for this solves a lot of interop. issues, and removes the need for
>> FLASH RTMP, or other realtime solutions.
>> Any feedback would be really appreciated
> 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.
> Since VLC can seek forward and backward, could it not ACCEPT my
> different STARTRANGE position in the response, and adjust its position
> accordingly? If that is the case, then I have a 100% complete
> solution for streaming live content, both seekable forward and
> reverse. :) I dont think it would break anything, as 99.99% of the
> HTTP Servers responding will be the requested STARTBYTE, but this
> would allow the position to then be set differently if needbe by the
> HTTP response, it would be just like to a backward seek.
> So I guess 1st question is, would you maintainers accept this
> proposal? then 2nd, if someone has the experience and want, Id be
> willing to pay something to have it done and merged in.
> And maybe same person can help me out with #1 up top as well.
Is their possibly a more "appropriate" mailing list to which I should be
using to engage "persons" in the know in regards to my 1st question, and
then secondly to find (a) if it would be acceptable to allow a change in
the code to access the range response as returned from the server (b)
find a consultant in VLC to do the mod? I would like to make sure it
would be an acceptable mod which could be merged into the branch.
More information about the vlc-devel