[FFmpeg-devel] [PATCH 2/2] avformat: add avformat_flush()

[Reimar Döffinger]

On 29.09.2014, at 22:02, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Mon, Sep 29, 2014 at 08:34:44PM +0200, wm4 wrote:
>> On Mon, 29 Sep 2014 20:25:47 +0200
>> Michael Niedermayer <michaelni at gmx.at> wrote:
>> 
>>> On Mon, Sep 29, 2014 at 07:41:28PM +0200, wm4 wrote:
>>>> Useful for Bluray and DVD, since the libraries used to read them just
>>>> change the byte stream under your feet on seeking.
>>>> 
>>>> Maybe there should be a AVInputFormat callback for this. But the
>>>> mpeg-ps (DVD) and the mpeg-ts (Bluray) demuxers don't change much
>>>> state during seeking - they just try to find a new packet with
>>>> timestamps (in read_timestamp), so I haven't found a need for this
>>>> yet. I don't want to add unused things.
>>>> 
>>>> I've also thought about adding a flush callback, and implementing
>>>> them in mpeg.c and mpegts.c by just calling ff_read_frame_flush().
>>>> Might be slightly better, because you can have avformat_flush() fail
>>>> on formats which don't support this?
>>>> 
>>>> Or maybe a flag?
>>>> 
>>>> TODO: add entry to APIchanges, bump minor version.
>>>> ---
>>>> libavformat/avformat.h | 13 +++++++++++++
>>>> libavformat/utils.c    |  6 ++++++
>>>> 2 files changed, 19 insertions(+)
>>>> 
>>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>>> index 78054de..eaa52fa 100644
>>>> --- a/libavformat/avformat.h
>>>> +++ b/libavformat/avformat.h
>>>> @@ -2173,6 +2173,19 @@ int av_seek_frame(AVFormatContext *s, int stream_index, int64_t timestamp,
>>>> int avformat_seek_file(AVFormatContext *s, int stream_index, int64_t min_ts, int64_t ts, int64_t max_ts, int flags);
>>>> 
>>>> /**
>>>> + * Discard all internally buffered data. This can be useful when dealing with
>>>> + * discontinuities in the byte stream. Generally works only with some simple
>>>> + * formats.
>>> 
>>> id call them stream based or without a central header instead of
>>> simple.
>> 
>> I can change that and replace "simple" with "headerless".
> 
> please do, headerless is more specific

Why does it require headerless?
I would have expected this feature to work for e.g. Ogg as well, which clearly is not headerless.
As such I'd claim headerless may be more specific, but it is also wrong.
It should work for all formats that can be read without index and can resync reliably at least.