[Libav-user] Reducing latency of file opening (when playing from http)

[Kalileo]

On May 15, 2013, at 11:09 , Bjoern Drabeck wrote:

>>> 
>>> When I am opening a file I call avformat_open_input, then after that I
>>> call avformat_find_stream_info, and I am timing those calls:
>>> 
>>> 'avformat_open_input':          9.7970 seconds
>>> 'avformat_find_stream_info':  0.1080 seconds
>>> 
>>> So for me the problem seems to be avformat_open_input. My testfiles
>>> are all around that range, maybe +-2 sec
>> 
>> You mentioned that you read the files using http urls, so isn't there the download time included in the values you measure for avformat_open_input?
>> 
> Yeah sure, it will have to get the data first, but I am wondering if
> that amount of data can be reduced, because 10 sec seems quite long to
> me for opening, but those probesize etc don't seem to make a
> difference.
> 
> On the other hand, once I have opened, and I seek to a spot later in
> the file, it is so fast it is almost instant.. so that's why I
> wondered if the amount of data analyzed/download on initial opening
> can be reduced…

Based on the values I measure (see below) I think that you have this latency at avformat_open_input only because there you have the download time included.

> 
>> In my case I fill a memory buffer first and then feed that to the avformat functions.
>> 
>> Nevertheless I will time these two functions again. I always assumed that the time is lost in avformat_find_stream_info and not in avformat_open_input, but may be my assumption was wrong.
>> 
> 
> yeah please let me know your findings, am curious to hear...
> 
>>> 
>>> As I mentioned before, changine probesize/analyzeduration from 5000000
>>> to 5000 doesn't seem show any visible effect (just ranging within the
>>> usual fluctuations of the above timings)
>>> 
>>> Is that what you experienced too?
>> 
>> if I reduce probesize/analyzeduration it does not get faster, but at some point it fails to recognize the streams. At 100000 it does fail most of the time (mpegts h264/aac).
>> 
> 
> for me I can often go down as low as 5000 (or at least 10000) before
> it starts failing.. but the timing doesn't seem to change really…

timings change in avformat_find_stream_info only, but not in avformat_open_input (where for you the http downloads times are included).

> 
>> Which is why I would love to configure all possible settings which can be set before these functions are called.
>> 
> 
> yeah me too…


Here the values I measured (in ms for mpegts /h264/aac read from memory buffer):

Test 1:
probesize 5000000  max_analyze_duration 5000000 
avio_alloc_context time:  0 
avformat_open_input time:  0 
avformat_find_stream_info time:  30 
openVideoCodecContext time:  0 
openAudioCodecContext time:  1 

Test 2:
probesize 5000000  max_analyze_duration 5000000 
avio_alloc_context time:  0 
avformat_open_input time:  0 
avformat_find_stream_info time:  43 
openVideoCodecContext time:  1 
openAudioCodecContext time:  0 

Test 3:
probesize 50000  max_analyze_duration 50000 
avformat_find_stream_info time:  14 ms +/- 2
but sometimes the codecs are not recognized. 


Test 4:
probesize 500000  max_analyze_duration 500000 
avformat_find_stream_info time:  18  ms +/- 4
codecs are recognized

Test 5:
probesize 1000000  max_analyze_duration 1000000 
avformat_find_stream_info time:  22  ms +/- 4


Conclusion: 

1. avformat_open_input is always very fast, no time lost.

2. avformat_find_stream_info is taking time, but not that much.

3. avformat_find_stream_info can be made faster by reducing probesize /  max_analyze_duration

4 avformat_find_stream_info can fail at low values (50000) despite the stream chunks starting with  PAT/PMT and keyframe.


Based on these values it seems to be not a question of latency but more of making sure that  avformat_find_stream_info gets the correct values, by setting known values before running avformat_find_stream_info (which seems to not work for me).

Latency is low enough for me now.