Found a gap of size

[shaka-project]

Found a gap of size

[kqyang]

It is normally caused by either 1) a gap in the original stream or 2) packager is not fast enough to keep up with the stream, due to slow machine or slow input/output media.

Can you describe your setup in detail? It can help troubleshooting.

[nrmmota]

I'm using VLC to transcode a Live input stream into a HLS valid stream output. I transcode it into H264/AAC for iOS HLS native playback. After the transcoding stub I place two destination stubs.

duplicate{dst=std{acces=httplive..},dst=std{access=udp,mux=ts,dst=239.192.1.1:1234}}

The packager then complains about the 239.192.1.1:1234 stating that there are gaps between segments.

The machine has a core i3 and is transcoding only one stream. Around 25% of CPU. The HLS stream output from VLC is flawless. I assume the UDP is too. VLC is by far the best TS muxer I've seen so far. Every hardware decoder does not complain when I use it.

I can save the UDP TS output for a sample just for debug purposes.

[kqyang]

Are vlc and packager running on the same machine? I am suspecting the cpu is not powerful enough and vlc/packager may compete for resources. Run them on different machines could help.

As for player, you could try shaka player: http://shaka-player-demo.appspot.com/ (https://github.com/google/shaka-player), which should be able to tolerate small gaps.

[nrmmota]

I have 70% of idle cpu. There are plenty of resources I can assure you.

Packager creates all the segments, but even shaka player stops and keeps downloading segment -2 repeatedly. A very different experience from the HLS system I have running at the moment.

[nrmmota]

I've sampled a TS from a live feed. It might help troubleshoot.

https://dl.dropboxusercontent.com/u/63418458/hls/livestream2.ts

[kqyang]

I don't see problems in the above ts.

Several questions:

1. Are all the gaps the size of 685? Does it happen once for every segment?

2. What is the full vlc and packager command parameters you are using?

3. Have you tried running vlc and packager on different machines? How does it go?

4. Can you post the logs and the generated mpd (it would be great if you can put the generated media files in an accessible location too)? A small gap of 685 should not cause playback problem.

5. Are you using latest packager code?

[nrmmota]

I did find one small thing that seems to have triggered my playback problems.

I was using the original 5Mb bandwidth. I downsized it to around the same bandwidth of the original stream and its working.

This is working:
edash/src/out/Debug/packager
'input=udp://239.192.232.71:1234,stream=audio,init_segment=live-audio.mp4,segment_template=live-audio-$Number$.mp4,bandwidth=130000'
'input=udp://239.192.232.71:1234,stream=video,init_segment=live-video-sd.mp4,segment_template=live-video-sd-$Number$.mp4,bandwidth=2000000'
--profile live
--segment_duration 10
--mpd_output live.mpd

Gap size still occurs, but playback is flawless at the moment.

[tinskip]

Interesting. Perhaps what may have been happening is that the stream had a
lot of padding, which when removed by the packager, created gaps?

Glad to hear it's working for you now.

On Fri, Jun 12, 2015 at 10:54 AM, Nuno Mota [email protected]
wrote:

I did find one small thing that seems to have triggered my playback
problems.

I was using the original 5Mb bandwidth. I downsized it to around the same
bandwidth of the original stream and its working.

This is working:
edash/src/out/Debug/packager
'input=udp://239.192.232.71:1234,stream=audio,init_segment=live-audio.mp4,segment_template=live-audio-$Number$.mp4,bandwidth=130000'

'input=udp://239.192.232.71:1234,stream=video,init_segment=live-video-sd.mp4,segment_template=live-video-sd-$Number$.mp4,bandwidth=2000000'

--profile live
--segment_duration 10
--mpd_output live.mpd

Gap size still occurs, but playback is flawless at the moment.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

Thomás Inskip | Software Engineer | [email protected] | [phone]