HLS-8: Implement ability to tell FFMPEG the input is a linear stream

I think in the short-term, to allow testing on things like HLS-6 it's probably best to rely on ffmpeg checking the input stream is valid.

Once the file existance check is removed, will need to test against some live streams. For the time being, should test against the following and consider them explicitly supported

- RTMP stream
- Reading from named pipe
- Single bitrate HLS (outputting to adaptive)

For the HLS input, can test a few methods - reading from local file system, from remote URL and via a pipe.

As the input file check has been removed, have been able to run a number of tests.
The file being used is taken from JWPlayer's demo page - technically it's VoD but is at least long enough to run basic tests, will look at setting up a truly live stream later.

Simple RTMP

$ ./HLS-Stream-Creator.sh -i rtmp://fms.12E5.edgecastcdn.net/0012E5/mp4:videos/8Juv1MVa-485.mp4 -s 10 -o /tmp/rtmptest/ -l

Watching as it encodes

- Audio is in sync
- video plays without stutter

Single to Multiple Bitrates

$ ./HLS-Stream-Creator.sh -i rtmp://fms.12E5.edgecastcdn.net/0012E5/mp4:videos/8Juv1MVa-485.mp4 -s 10 -o /tmp/rtmptest/ -l -b 36,128,512

vlc appears to get stuck just after the video intro when using the master playlist - lower bitrates play fine, where the 512k stream falls off at the same point, so think it's actually just that the highest bitrate isn't currently keeping up. vlc is obviously parsing the manifest OK as it's playing back video, so think it's just falling off the end of the manifest (more a limitation of the hardware I'm testing on) - it's not switching down a bitrate because it's not experiencing delivery issues, just an EOF

Will drop the higher bitrate from the next set of tests to simplify testing, but worth coming back to

Sliding window, 50 seconds of video per manifest

./HLS-Stream-Creator.sh -i rtmp://fms.12E5.edgecastcdn.net/0012E5/mp4:videos/8Juv1MVa-485.mp4 -s 10 -o /tmp/rtmptest/ -l -b 36,128 -c 5

The two bitrates remain relatively in sync in terms of segment count, though the lower may be a few seconds ahead. The video looks terrible at 36K mind :)

So, all seems to work within the constraints of my test hardware.

General
Because the variant playlist is generated before the encode is started on the bitrates, a player arriving early may try to load the video before it's ready (for it's part ffmpeg doesn't generate the manifest until one segment has been encoded), so it may be worth looking at moving the variant playlist generation.

Using a non-local resource obviously works, though the streams may currently go out of sync. That's not an issue for VoD (as the encoding will likely be done before the media is available for delivery) but is a potential headache for live streams - you don't want there to be too big a difference when using a sliding Window.

If the 36k stream in test 3 where to get 50 seconds ahead (unlikely, but possible) a player switching down a bitrate might find it's current position simply isn't available in the manifest.

One of the requirements in HLSDVD-2 (which is intended to use this script) is that it should be possible to read from a named pipe (a FIFO). It'll also need short segment sizes so that there's not too great a delay between the source changing and the output changing (2 seconds seems an OK starting point).

Although technically it can be handled as a linear stream, there are a few complications (if you're wanting to publish an adaptive stream for example) so will raise a separate issue for that - HLS-13.

For a single bitrate output (i.e. a single ffmpeg output) the principle works OK though

$ mkfifo test.fifo.avi
$ mplayer -dumpstream -dumpfile test.fifo.avi test.avi

$ ./HLS-Stream-Creator.sh -i /tmp/test.fifo.avi -s 2 -o /tmp/fifotest/ -l -b 512 -c 20

The caveat being that ffmpeg needs to know the input stream type, so the FIFO needs to carry a suitable filename extension.

To get multiple output bitrates supported, we'll need some kind of wrapper which can read from the FIFO and make available for multiple processes to read.

The output stream from the FIFO also plays OK on in MX Player on an Android tablet.

Closing as implemented - the stream plays back OK on multiple devices and handling FIFO and ABR streams is better handled in the dedicated issue: HLS-13