HTTP Live Stream via CLI does not obey EXTINF?

[JackNorris]

I have been trying to save an HTTP Live Stream with VLC by launching it from the command line, unfortunately while this does begin to save the file it soon exhausts the playlist and then quits.

When playing the stream via the GUI everything is fine and plays+saves as expected. I suspect that this is because VLC is playing the stream in real time and is updating the playlist after every segment. If I launch VLC through the command line with the dummy switch there is no video to play and VLC just steams ahead and downloads everything in the playlist as fast as it can. This is causing me issues because the playlist I am trying to save is being updated constantly with new entries.

Here is the command I am trying:

vlc -vvv "input_stream" --sout "#file{dst=output.ts}" -I dummy

This successfully launches VLC and downloads the entries in the playlist. The problem is that the playlist is running out of new content as VLC does not appear to be obeying the EXTINF attribute of the playlist.
Without the dummy switch VLC loads the full interface but no video is played (although it is saved) and the problem occurs in the same way. It seems that the video has to be playing in order for this to work correctly.

According to this draft (http://tools.ietf.org/html/draft-pantos ... tion-6.3.4), the player should read the EXINF attribute in the playlist and use that to workout when to next reload the playlist.

Can anyone advise if this is a bug or if I doing this incorrectly? I have tested with VLC 2.0.1 and the nightly builds on Windows and Linux - both act the same way.

[Jean-Baptiste Kempf]

-I qt or -I dummy should not change anything in input parsing and playback. Something else is wrong.

[JackNorris]

Thats what I would have thought

I currently have a workaround for this... If I supply the :display in the sout argument then everything seems to work fine, even with -I dummy. This does feel like somewhat of a hack though.
I don't suppose you have any ideas on what this could be?

[Jean-Baptiste Kempf]

Look at the logs.

[JackNorris]

I have looked at the logs, unfortunately they don't mean a whole lot to me as I don't know the internal workings of VLC.

Here's the log (http://pastebin.com/48t6rjdN) from VLC that was started with the following command:

Code: Select all

vlc "http://192.168.10.32:1940/stream01/_definst_/mp4:stream01/playlist.m3u8" --sout "#file{dst=c:\test12.ts}"

This does not work correctly. It downloads the contents of the first playlist and does not look like it even attempts to reload the playlist and check for updates.


Here's the log from VLC (http://pastebin.com/V0itYww0) that was started with the following command (note the added :display at the end):

Code: Select all

vlc "http://192.168.10.32:1940/stream01/_definst_/mp4:stream01/playlist.m3u8" --sout "#file{dst=c:\test12.ts}:display"

This works correctly and processes the playlist and then attempts to reload and update at the correct intervals.

Nothing really stands out from the two logs apart from the additional stream module being used in the working log (main debug: using sout stream module "stream_out_display").

Without :display there are "playback in danger of stalling" errors, it is almost as if VLC is just playing each segment as fast as it can read them and with the display module loaded it is playing them at the correct speed (even though there is no interface). I don't think this explains why the non-working log doesn't show any playlist update after the initial download though.

[Jean-Baptiste Kempf]

This may be because of pacing. Try to force pacing in the options.