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

[Michael Niedermayer]

On Thu, Oct 18, 2012 at 07:43:02AM +0200, Reimar Döffinger wrote:
> 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.

TS files have many headers at many different layers, and many different
kinds of timestamps that could all be used to estimate delay per byte


> And even for flv files we ignore the header because it is unreliable.

flv has timestamps


> 
> >> 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).

possible

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20121018/95fbd5ba/attachment.asc>