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

[James Zern]

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?

> 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?