[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
>> _______________________________________________

Hello,

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.

thank you
Shawn