[FFmpeg-devel] [PATCH] lavf: increase probesize

[Reimar Döffinger]

On 18 Oct 2012, at 07:13, James Zern <jzern at google.com> wrote:
> On Tue, Oct 16, 2012 at 11:49 PM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>> On 17 Oct 2012, at 04:19, James Zern <jzern at google.com> wrote:
>> 
>>> On Tue, Oct 16, 2012 at 7:17 PM, James Zern <jzern at google.com> wrote:
>>>> ---
>>>> libavformat/options_table.h |    2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>> 
>>>> diff --git a/libavformat/options_table.h b/libavformat/options_table.h
>>>> index 778c740..29ee8cd 100644
>>>> --- a/libavformat/options_table.h
>>>> +++ b/libavformat/options_table.h
>>>> @@ -35,7 +35,7 @@
>>>> static const AVOption options[]={
>>>> {"avioflags", NULL, OFFSET(avio_flags), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, INT_MIN, INT_MAX, D|E, "avioflags"},
>>>> {"direct", "reduce buffering", 0, AV_OPT_TYPE_CONST, {.i64 = AVIO_FLAG_DIRECT }, INT_MIN, INT_MAX, D|E, "avioflags"},
>>>> -{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT, {.i64 = 5000000 }, 32, INT_MAX, D},
>>>> +{"probesize", "set probing size", OFFSET(probesize), AV_OPT_TYPE_INT, {.i64 = 10000000 }, 32, INT_MAX, D},
>>>> {"packetsize", "set packet size", OFFSET(packet_size), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, E},
>>>> {"fflags", NULL, OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = DEFAULT }, INT_MIN, INT_MAX, D|E, "fflags"},
>>>> {"ignidx", "ignore index", 0, AV_OPT_TYPE_CONST, {.i64 = AVFMT_FLAG_IGNIDX }, INT_MIN, INT_MAX, D, "fflags"},
>>>> --
>>>> 1.7.7.3
>>>> 
>>> 
>>> This is arbitrary, but I thought I'd send it around for discussion
>>> before updating code locally.
>>> The background: I was doing some 4K encodes and found that I could end
>>> up with initial video frames > 5MB, which would result in no audio
>>> information being reported.
>> 
>> This can delay playback of low bitrate streamed content a lot I believe.
> 
> Assuming the file has header information, wouldn't find_stream_info
> break out early?

TS files are also used for streaming for example, and they most certainly do not have a header.
And even for flv files we ignore the header because it is unreliable.

>> It might be better to have an option to specify how many packets we should at least have before we stop probing, because with that the amount of data probed should scale automatically with bitrate (and also continue working if at some point someone has initial video frames that are 50 MB for example).
> 
> Maybe, but you'd want to have a max per stream then in the case the
> file reports having audio, for example, but doesn't in fact have any
> packets of that type, no?

It's supposed to apply across all streams together.
Or alternatively (and maybe better but more complex) waiting until you had n packets from one single stream (this makes the feature behave independent of the number of streams in the files).