[vlc-devel] MPEG Duration/Playback Ending?

[Developer]

> 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
> Shawn
>

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.

Shawn
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel