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. _______________________________________________ Libav-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/libav-user
