>> 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 includes >> >> 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 MPEG-2 >> 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 function. > 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. Beni _______________________________________________ libav-api mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-api
