HTTP file open bugs/weirdness
Posted: 13 Sep 2009 11:37
*VLC 1.0.1
*Windows 7 and Windows 2003 R2
*Apache 2.2
vlc->open->open network stream:
http://localhost/divx.avi
- Vlc start off by requesting Bytes: 0-
- Apache responds with a partial header, sending the whole file, with full content length
- Vlc request Bytes: 2048-
- Apache responds with a partial header, sending the file from 2048 and onwards
- Vlc starts playback of the avi file, with length 00:00, even when apache sends the correct content length. It sais it fills cache to 100% before playback starts - whatever that means
- Seek in the video works, by vlc sending a partial content request, but playtime is set to 00:00, and starts to count upwards from there, but the seek counter acts as if it's the full file still! (seeking backwards works)
- Pause the playback for 10s. Start again - playback fails! The video "shuts down"
- Vlc is reading the information it needs at any one time, so if bandwidth is limited, there's choppy playback for scenes with lots of action (movement in the picture), and smooth playback for slow parts. There is some sort of treshold for how much data can be missing for the fast parts, somehow VLC decides the datastream is too slow, and shuts down the playback. However, the slow areas can consume as little as 10% of the availible bandwith
- Clicking around to seek, at some point VLC goes completely crazy and starts sending Partial Content request with Bytes: 1235- for ~every 10kb!! - Breaking any chance of playback
Why request partial content, when it's a complete file?
Why send a second request after the first 2048 bytes recieved, and not just continue to recieve the original stream?
Why not keep the seek mark at the place on the seek bar you click, instead of returning it to 00:00?
Why not cache more data locally, to have pause/play work, or atleast send another partial content request to resume?
What could possibly be the reason to send a new GET request every 10kb?
Expected behaviour:
- vlc request file, without partial header
- request end of file, for parity(?) and seek information after mime type (or video codec) established
- partial requests for seek, if file has same timestamp as the first request
- working seek bar
- keep full local cache, in order to even out slow/fast scenes, and not halt playback
As a note - Windows Media Player 12, that ships with Windows 7 final seems to tunnel the data requests into GET requests quite nicely for divx, first requesting end of the file, to get proper seek, then accept all the data sendt by apache as a readahead, and keep a local cache of all the different seek parts in addition.
http://localhost/x264.mkv
Playback behaves similar to above, with one important difference - seek bar is working as expected!
The bandwidth contraints are behaving the same also, but easier to spot due to higher bitrate.
WMP12 runs cache quite well with this format also, however using matroska media splitter causes WMP12 to send shitloads of partial content requests, instead of reading one large stream - which render it useless.
http://localhost/test.wmv
Playback starts, after the cache counter reach 100%, but picture freezes after 1 second.
Seek works, but playback only last for 1 second before the picture freeze.
http://localhost/dvdr.iso
I've done the most extensive testing with divx, and for the most parts the behaviour is the same.
But for an ISO file, with dvd menu I get to see the menu for about 2 seconds, then playback shuts down. No explanation.
*Windows 7 and Windows 2003 R2
*Apache 2.2
vlc->open->open network stream:
http://localhost/divx.avi
- Vlc start off by requesting Bytes: 0-
- Apache responds with a partial header, sending the whole file, with full content length
- Vlc request Bytes: 2048-
- Apache responds with a partial header, sending the file from 2048 and onwards
- Vlc starts playback of the avi file, with length 00:00, even when apache sends the correct content length. It sais it fills cache to 100% before playback starts - whatever that means
- Seek in the video works, by vlc sending a partial content request, but playtime is set to 00:00, and starts to count upwards from there, but the seek counter acts as if it's the full file still! (seeking backwards works)
- Pause the playback for 10s. Start again - playback fails! The video "shuts down"
- Vlc is reading the information it needs at any one time, so if bandwidth is limited, there's choppy playback for scenes with lots of action (movement in the picture), and smooth playback for slow parts. There is some sort of treshold for how much data can be missing for the fast parts, somehow VLC decides the datastream is too slow, and shuts down the playback. However, the slow areas can consume as little as 10% of the availible bandwith
- Clicking around to seek, at some point VLC goes completely crazy and starts sending Partial Content request with Bytes: 1235- for ~every 10kb!! - Breaking any chance of playback
Why request partial content, when it's a complete file?
Why send a second request after the first 2048 bytes recieved, and not just continue to recieve the original stream?
Why not keep the seek mark at the place on the seek bar you click, instead of returning it to 00:00?
Why not cache more data locally, to have pause/play work, or atleast send another partial content request to resume?
What could possibly be the reason to send a new GET request every 10kb?
Expected behaviour:
- vlc request file, without partial header
- request end of file, for parity(?) and seek information after mime type (or video codec) established
- partial requests for seek, if file has same timestamp as the first request
- working seek bar
- keep full local cache, in order to even out slow/fast scenes, and not halt playback
As a note - Windows Media Player 12, that ships with Windows 7 final seems to tunnel the data requests into GET requests quite nicely for divx, first requesting end of the file, to get proper seek, then accept all the data sendt by apache as a readahead, and keep a local cache of all the different seek parts in addition.
http://localhost/x264.mkv
Playback behaves similar to above, with one important difference - seek bar is working as expected!
The bandwidth contraints are behaving the same also, but easier to spot due to higher bitrate.
WMP12 runs cache quite well with this format also, however using matroska media splitter causes WMP12 to send shitloads of partial content requests, instead of reading one large stream - which render it useless.
http://localhost/test.wmv
Playback starts, after the cache counter reach 100%, but picture freezes after 1 second.
Seek works, but playback only last for 1 second before the picture freeze.
http://localhost/dvdr.iso
I've done the most extensive testing with divx, and for the most parts the behaviour is the same.
But for an ISO file, with dvd menu I get to see the menu for about 2 seconds, then playback shuts down. No explanation.