[libav-api] mov demuxer: avformat_seek_file with AVSEEK_FLAG_BYTE
onlineweinies at bluewin.ch
Tue Jul 10 16:14:35 CEST 2012
>> On 06/06/12 13:50, Beni Weine wrote:
>> (again same post as few weeks ago, because I haven't received anything)
> Looks like it got lost, I never received it.
>> We need to improve the seeking
(performance) in our video player.
>> The video player concurrently manages 5
>> different video files (MP4),
and plays them
>> in a time synchronized manner.
>> Each video file has a time index file (proprietary)
>> among other things a time stamp and
>> the corresponding byte position of the H.264 data (I frame).
>> Pure time-based
>> seeking is not an option due to performance reasons.
>> The same player can handle
>> file. They come with a video
>> time index file as well.
>> We have amazing results with bytes-wise
>> avformat_seek_file with AVSEEK_FLAG_BYTE).
>> It seems that the mpegtsraw demuxer
(libavformat/mpegts.c) is doing that
>> pretty good.
>> Different story with the mov demuxer:
>> To me it looks
that the current implementation of
>> libavformat/mov.c does not support
>> byte-wise seeking.
>> Having a look into
the mov.c confirms my impression.
>> It there a possibility that this feature
>> will be added to
>> the mov
demuxer any time soon?
> Luca Barbato lu_zero at gentoo.org
> Thu Jun 7 07:57:10 CEST 2012
> Looks like it is
missing a read_seek2 implementation and it has the
> somehow curious peculiarity of seeking in the read_packet
How does libav handle such requests?
Again, is there a chance that mov.c (mov demuxer) gets extended
with the byte seek feature, which would implement read_seek2?
For us this is a crucial feature, and we would certainly
honor any effort in that area of the libav.
More information about the libav-api