- PC (via loopback) in VLC
- Android tablet (Wifi) in MX Player
- RaspBMC (copper ethernet)
The PC occasionally sticks and/or briefly drops audio where the other devices do not. It's possible it's related to the delivery speeds achieved over the loopback - it is consistently ahead of the other devices. Tweaking segment length and count may address that.
The Tablet (wifi) pauses occasionally, but recovers. So far, doesn't appear to have dropped audio. The wifi on that tablet can be a little iffy at times, so it's possible it's more of a delivery issue than an encoding issue.
XBMC is playing consistently without issue, it's a little ahead (couple of seconds, so 1 segment) of the tablet and probably around half a segment behind the PC.
So the issues seen on the PC and the tablet are probably related to the speed at which segments are delivered.
It shouldn't be possible for the PC to get ahead though, as it should start from the beginning of the manifest. Might need to look at little closer at vlc_s behaviour and test with another player (_mplayer ?) to see whether the behaviour is still observed.
One issue on RaspBMC is that it doesn't like it (hangs) when a live manifest comes to an end. It seems ffmpeg isn't appending #EXT-X-ENDLIST once the input stream is complete, so we'll need to look at appending that ourselves (but only for live streams) - HLS-15 .
One concern for linear streams, ffmpeg doesn't appear to take into account that it may be ahead of the player and that the player will take SEGLENGTH seconds (so 2 seconds above) to progress through each segment.
As a result, if the encodes happen quickly (i.e. in less than 2 seconds), the sliding window bumps content off the beginning of the manifest before the player has played them, leading to the video and audio jumping (so far, usually by a single segment).
Using a longer sliding window will probably briefly address this, but it's only really extending the time before the issue occurs. It doesn't seem to consistently happen (suggesting ffmpeg is getting through some segments much faster than others).
It doesn't break playback, but can make it a little uncomfortable to watch.
Given that project HLSDVD will be entirely concerned with pushing live streams, it's something that going to need to be addressed - having a long manifest won't be an acceptable solution because user-input (such as a press on the remote control) needs to be reflected on the output stream within a reasonable timeframe (likely within a second...)
Activity
2015-06-15 16:13:22
Playing back a stream being read from a named pipe
Playback on 3 devices
- PC (via loopback) in VLC
- Android tablet (Wifi) in MX Player
- RaspBMC (copper ethernet)
The PC occasionally sticks and/or briefly drops audio where the other devices do not. It's possible it's related to the delivery speeds achieved over the loopback - it is consistently ahead of the other devices. Tweaking segment length and count may address that.
The Tablet (wifi) pauses occasionally, but recovers. So far, doesn't appear to have dropped audio. The wifi on that tablet can be a little iffy at times, so it's possible it's more of a delivery issue than an encoding issue.
XBMC is playing consistently without issue, it's a little ahead (couple of seconds, so 1 segment) of the tablet and probably around half a segment behind the PC.
So the issues seen on the PC and the tablet are probably related to the speed at which segments are delivered.
It shouldn't be possible for the PC to get ahead though, as it should start from the beginning of the manifest. Might need to look at little closer at vlc_s behaviour and test with another player (_mplayer ?) to see whether the behaviour is still observed.
One issue on RaspBMC is that it doesn't like it (hangs) when a live manifest comes to an end. It seems ffmpeg isn't appending #EXT-X-ENDLIST once the input stream is complete, so we'll need to look at appending that ourselves (but only for live streams) - HLS-15 .
2015-06-15 16:16:09
2015-06-15 17:23:59
One concern for linear streams, ffmpeg doesn't appear to take into account that it may be ahead of the player and that the player will take SEGLENGTH seconds (so 2 seconds above) to progress through each segment.
As a result, if the encodes happen quickly (i.e. in less than 2 seconds), the sliding window bumps content off the beginning of the manifest before the player has played them, leading to the video and audio jumping (so far, usually by a single segment).
Using a longer sliding window will probably briefly address this, but it's only really extending the time before the issue occurs. It doesn't seem to consistently happen (suggesting ffmpeg is getting through some segments much faster than others).
It doesn't break playback, but can make it a little uncomfortable to watch.
Given that project HLSDVD will be entirely concerned with pushing live streams, it's something that going to need to be addressed - having a long manifest won't be an acceptable solution because user-input (such as a press on the remote control) needs to be reflected on the output stream within a reasonable timeframe (likely within a second...)
2019-11-23 12:09:19
2019-11-23 12:09:19