Apple HTTP Live Streaming seeking incorrect

[Takis Issaris]

The libavformat Apple HTTP Live Streaming demuxer uses incorrect units when searching for the MPEG TS segment which contains the requested timestamp. The segment duration is expressed in seconds in the IETF draft, and in the demuxer the added durations are compared with the requested timestamp.

static int applehttp_read_seek(AVFormatContext *s, int stream_index, int64_t timestamp, int flags)
...
timestamp = av_rescale_rnd(timestamp, 1, ...
...
int64_t pos = 0;
...
/* Locate the segment that contains the target timestamp */

for (j = 0; j < var->n_segments; j++) {

if (timestamp >= pos &&

timestamp < pos + var->segments[j]->duration) {

...

break;

}
pos += var->segments[j]->duration;

[Takis Issaris]

The above description was incorrect: The timestamp is indeed being rescaled, but the demuxer assumes that the first segment will start from 0. But, for actual live streaming of HTTP Live Streams, only the last x encoded segments are stored, the earlier segments get deleted. Because of this (and for other reasons), the initial segment fetched after parsing the m3u8 will not start from 0.

[Takis Issaris]

Take sliding window playlists into account when seeking

[Takis Issaris]

The patch I just attached tries to do the right thing when using sliding playlists. It assumes all segments are of equal duration.

[Takis Issaris]

One of the other reasons I mentioned earlier is that AFAIK the timestamps in the MPEG TS streams do not have to start from 0 (or near zero).

[Michael Niedermayer]

I think we should not assume that the segment durations are all equal.
It seems a better choice to take the first timestamp and correct it by the duration of each segment as it
becomes unavailable.

[Takis Issaris]

Agreed, the patch actually doesn't even work for my particular problem :) It was purely meant to illustrate the problem in the current implementation.

But, to be able to fix it correctly, I should be able to parse the first timestamp out of the MPEG TS stream. How should one access the MPEG TS parser from within the Apple HTTP Live Stream demuxer?

[Michael Niedermayer]

pkt->dts/pts after the av_read_frame() might (or might not) work

[Takis Issaris]

Thanks!

I've added a different patch now, which uses the initial dts as an offset for determining which segments should be used.

Would it be better to store the timestamp rescaled to avoid rescaling in the seeking method, or is it better to keep the actual timestamp as it might be useful for other purposes?

I used -1 as an initial value, is AV_NOPTS_VALUE better?

[Michael Niedermayer]

yes, i think AV_NOPTS_VALUE would be better
except that, if you have tested this, i guess its ok

[Takis Issaris]

Excellent. I'm currently testing it some more and will try to commit when done. I kinda skipped the whole ffmpeg.org/libav.org discussion, but I do not think I still have commit access, do I? Or were the SVN commits automatically given commit rights?

[Takis Issaris]

This patch changes this demuxers seeking implementation to use the initial DTS as an offset for searching the segments containing the requested timestamp.

[Michael Niedermayer]

Replying to takis:

Excellent. I'm currently testing it some more and will try to commit when done. I kinda skipped the whole ffmpeg.org/libav.org discussion, but I do not think I still have commit access, do I? Or were the SVN commits automatically given commit rights?

git clones are better than direct write IMHO because they give more freedom to each developer
users can checkout clones, merges can be done when the author considers
it "ready". 2 developers can actually work on the same by cooperation
or competing with clones.

automatically retaining write access wasnt possible as svn used usernames and
passwords while git uses ssh keys. But all people who had svn write are offered
git write if they prefer. I would need a public ssh key, gpg signed and the
gpg fingerprint in our MAINTAINERS file for this

[Takis Issaris]

I agree that git clones give more freedom to developers, in fact I think I was the first suggesting using it for FFmpeg back in 2006 :-)
​http://article.gmane.org/gmane.comp.video.ffmpeg.devel/37959

But, currently, I read in the FFmpeg docs that merges aren't allowed, which means one can't have a stable publicly available tree online (stable as in 'a tree one can clone and pull from'), right? I'd put a tree up on github in august which has my commits publicly available, but that would only work nicely with merges IMHO.

[Michael Niedermayer]

Replying to takis:

I agree that git clones give more freedom to developers, in fact I think I was the first suggesting using it for FFmpeg back in 2006 :-)
​http://article.gmane.org/gmane.comp.video.ffmpeg.devel/37959

And i indeed regret that i did not push toward a git switch longer ago ...

But, currently, I read in the FFmpeg docs that merges aren't allowed, which means one can't have a stable publicly available tree online (stable as in 'a tree one can clone and pull from'), right? I'd put a tree up on github in august which has my commits publicly available, but that would only work nicely with merges IMHO.

You can just grep the git log for "Merge" to convince yourself that merges are not forbidden and that there are actually quite a few in there :)

[Carl Eugen Hoyos]

Implemented by Takis.