HTTP file open bugs/weirdness

Microsoft Windows specific usage questions
Forum rules
Please post only Windows specific questions in this forum category. If you don't know where to post, please read the different forums' rules. Thanks.
pion
Blank Cone
Blank Cone
Posts: 14
Joined: 01 Nov 2008 19:07

HTTP file open bugs/weirdness

Postby pion » 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.

pion
Blank Cone
Blank Cone
Posts: 14
Joined: 01 Nov 2008 19:07

Re: HTTP file open bugs/weirdness

Postby pion » 16 Sep 2009 15:17

The behaviour is also present in vlc-1.1.0-git-20090915-2208-win32-debug.zip

The 10kb packet requesting bug can be reprodused by clicking to different seek positions in a fast pase. Clicking "stop", and then "play" again will make it work as expected again.

VLC_help
Mega Cone Master
Mega Cone Master
Posts: 25661
Joined: 13 Sep 2006 14:16

Re: HTTP file open bugs/weirdness

Postby VLC_help » 17 Sep 2009 16:59

You can open a trac ticket for this.
trac-test.videolan.org/vlc

pion
Blank Cone
Blank Cone
Posts: 14
Joined: 01 Nov 2008 19:07

Re: HTTP file open bugs/weirdness

Postby pion » 17 Sep 2009 18:28

Registering has been down the last few days tho, but I'll check back

pion
Blank Cone
Blank Cone
Posts: 14
Joined: 01 Nov 2008 19:07

Re: HTTP file open bugs/weirdness

Postby pion » 23 Sep 2009 19:53

Trac registering seems to be down still... any idea when it would be back?

VLC_help
Mega Cone Master
Mega Cone Master
Posts: 25661
Joined: 13 Sep 2006 14:16

Re: HTTP file open bugs/weirdness

Postby VLC_help » 24 Sep 2009 16:08

trac-test.videolan.org/vlc/register you tried via that and you get some sort of error?

pion
Blank Cone
Blank Cone
Posts: 14
Joined: 01 Nov 2008 19:07

Re: HTTP file open bugs/weirdness

Postby pion » 30 Sep 2009 12:40

The link at the site points to https://trac.videolan.org/vlc/register - which states that trac is down

VLC_help
Mega Cone Master
Mega Cone Master
Posts: 25661
Joined: 13 Sep 2006 14:16

Re: HTTP file open bugs/weirdness

Postby VLC_help » 01 Oct 2009 13:39

Use trac-test, not trac


Return to “VLC media player for Windows Troubleshooting”

Who is online

Users browsing this forum: Google [Bot] and 28 guests