[libav-api] mov demuxer: avformat_seek_file with AVSEEK_FLAG_BYTE

Beni Weine 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 
>> capabilities 
(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) 
>> which 
>> 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 
seeking (calling 
>> 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 
> lu

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 mailing list