Skip to content

Live content does not play on Chrome if no IDR-frame in middle of interval

Created by: TobbeMobiTV

The live simulator http://vm2.dashif.org/livesim/testpic_2s/Manifest.mpd plays nicely in both Chrome, IE11 and Safari. It uses a SegmentTemplate and video segments of exact 2s duration with a key-frame every 1s.

However, when trying some less ideal sources, I've run into the issue that Chrome crashes with a Video Element Error: MEDIA_ERR_DECODE, while Safari is starting without a key-frame, and IE11 is behaving OK.

I've tracked this back to the startTime chosen for live streams needs to correspond to a key frame for Chrome (version 38 & 40) to be happy. In ScheduleController.js:

            actualStartTime = request.startTime + (request.duration / 2);

which results in the player seeking to this media time in the middle of a segment interval. In the case of the live simulator, there is always a key frame there, so Chrome is happy. If not, Chrome crashes.

This can easily be seen by changing the actualStartTime in ScheduleController.js by 100ms:

                 actualStartTime = request.startTime + (request.duration / 2) - 0.1;

This makes Chrome crash in both version 38 and 40.

In general, it is a waste to not start playing from the start of a downloaded segment, so I think the strategy should be modified with the earliest possible startTime. Unfortunately, the segment is not downloaded at the time of this decision as the code is now (only the presence of segments have been checked using HEAD requests).

I've tried to patch the updateBufferLevel method in BufferController.js as follows:

        if (!firstMedia) {
            var bufRange = self.sourceBufferExt.getBufferRange(buffer, currentTime, 10);
            if (bufRange != null) {
                var bufStart = bufRange.start;
                currentTime = bufStart;
                self.playbackController.setLiveStartTime(currentTime);
                self.playbackController.seek(currentTime);
                console.log("<<<< Fixing startTime " + currentTime);
                firstMedia = true;
            }
        }

which makes the test source work again, but is not generic enough. It is called multiple times, and give different startTimes for audio and video in the general case.

So, I'd like to see a change to get started from the beginning of the first video segment downloaded (assuming that there is a key frame there). Beyond getting around this Chrome weakness, it would give better buffer fullness as well.