On Mon, 26 Dec 2011, Andrey Utkin wrote:
According to draft-pantos-http-live-streaming-07, 6.3.4.,
=== quote ===
The initial minimum reload delay is the duration of the last media
segment in the Playlist. Media segment duration is specified by the
EXTINF tag.
If the client reloads a Playlist file and finds that it has not
changed then it MUST wait for a period of one-half the target
duration before retrying.
=== quote end ===
Did not implement the second part (if playlist has not changed).
Previously, playlist reloading interval was TARGETDURATION seconds,
and lags have happened at playback.
Now reloading interval is last known (listed in playlist) segment's
EXTINF value.
Tested old and new way with Wowza 3.0.2 patch3.
---
libavformat/applehttp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavformat/applehttp.c b/libavformat/applehttp.c
index 99febc6..a1fcea1 100644
--- a/libavformat/applehttp.c
+++ b/libavformat/applehttp.c
@@ -393,7 +393,7 @@ reload:
if (v->finished)
return AVERROR_EOF;
while (av_gettime() - v->last_load_time <
- v->target_duration*1000000) {
+ v->segments[v->n_segments-1]->duration * 1000000) {
if (ff_check_interrupt(c->interrupt_callback))
return AVERROR_EXIT;
usleep(100*1000);
--
1.7.7
This might be ok, but this needs a check for v->n_segments > 0. To
simplify the expression, a separate duration variable perhaps can be
declared above, e.g.
int duration = v->n-segments > 0 ?
v->segments[v->n_segments - 1]->duration :
v->target_duration;
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
