Opened 5 years ago

Closed 5 years ago

#649 closed defect (fixed)

Apple HTTP Live Streaming seeking incorrect

Reported by: takis Owned by:
Priority: normal Component: avformat
Version: git-master Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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;

Attachments (3)

phmi-20111114T1312-ffmpeg-applehttp_sliding_window_seek.diff (549 bytes) - added by takis 5 years ago.
Take sliding window playlists into account when seeking
phmi-20111114T1820-ffmpeg-applehttplive-seek_fix.diff (1.5 KB) - added by takis 5 years ago.
phmi-20111115T1452-ffmpeg-fix_seeking_when_using_apple_http_live_streaming.diff (2.9 KB) - added by takis 5 years ago.
This patch changes this demuxers seeking implementation to use the initial DTS as an offset for searching the segments containing the requested timestamp.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 5 years ago by takis

  • Version changed from unspecified to git-master

comment:2 Changed 5 years ago by takis

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.

Changed 5 years ago by takis

Take sliding window playlists into account when seeking

comment:3 Changed 5 years ago by takis

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

comment:4 Changed 5 years ago by takis

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).

comment:5 Changed 5 years ago by michael

  • Status changed from new to open

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.

comment:6 Changed 5 years ago by takis

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?

comment:7 Changed 5 years ago by michael

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

comment:8 Changed 5 years ago by takis

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?

comment:9 Changed 5 years ago by michael

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

comment:10 follow-up: Changed 5 years ago by 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?

Changed 5 years ago by takis

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

comment:11 in reply to: ↑ 10 Changed 5 years ago by michael

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

comment:12 follow-up: Changed 5 years ago by 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

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.

comment:13 in reply to: ↑ 12 Changed 5 years ago by michael

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 :)

comment:14 Changed 5 years ago by cehoyos

  • Resolution set to fixed
  • Status changed from open to closed

Implemented by Takis.

Note: See TracTickets for help on using tickets.