[FFmpeg-devel] [PATCH 09/18] avformat/hls: always return EOF for unneeded playlist streams

Anssi Hannula anssi.hannula at iki.fi
Tue Dec 31 00:12:48 CET 2013


30.12.2013 18:18, Michael Niedermayer kirjoitti:
> On Mon, Dec 30, 2013 at 01:14:23PM +0200, Anssi Hannula wrote:
>> Even if we returned AVERROR_EOF previously due to playlist no longer
>> being needed, we may still be called again, and we do not want to
>> trigger a segment download in that case.
> 
> should this call recheck_discard_flags() or something like that
> (for the case that AVStream->discard changed) ?

Possibly. Note that the previous code (without the additional check) did
not call it either, and it would hit a pls->needed check a bit upwards
in the call chain (hls_read_packet(), but this is after the unneeded
segment has already been requested), so it is not worse than before
unless I'm missing something.

This new check is for things like url_feof() which try to see if new
data is available despite everything.


The code seems to currently only consider !pls->needed => pls->needed
changes on segment switches (I guess to try to facilitate "clean"
switches between streams without requesting overlapping segments from
different variants - this requires some trickery from the application,
though, as it needs to continue playing back the previous stream until
the new one is available... hmm wait, but the demuxer might then
download the next segment for both the old and new variant if it the
application doesn't discard the old variant immediately...).

As noted here I did plan to make some changes to it anyway:
http://trac.ffmpeg.org/ticket/2737#comment:6

As I just noticed above, I guess the current behavior doesn't make that
much sense after all. I guess the discard flags should just be checked
between every packet and any new selected playlist segments downloaded
immediately and seeked to the playback position... it would even
simplify the code (I almost changed it so already).

Unless the current way already facilitates "clean" switches in some way
I'm not seeing.

-- 
Anssi Hannula


More information about the ffmpeg-devel mailing list