[Libav-user] Help in understanding seeking behaviour of FFmpeg API on MP4 video with hint tracks

declan harrison harrison.declan at gmail.com
Wed Apr 22 16:55:39 CEST 2015


Hi Anton

Thanks for your advice, setting to discard to AVDISCARD_ALL, worked a treat
for me, thanks.

Is the libav-user email list active much? When i look i dont see many
emails or replies on the archive. Is there an IRC channel for it ?

Thanks again
Declan

On Sun, Apr 19, 2015 at 11:41 AM, Anton Shekhovtsov <shekh.anton at gmail.com>
wrote:

>
>
> 2015-04-19 12:55 GMT+03:00 declan harrison <harrison.declan at gmail.com>:
>
>> I need help understanding the internals of FFmpeg API seek call with
>> certain files.
>>
>> Im using the ffmpeg libav* API in an appliaction that reduces the bitrate
>> of MP4 files.  The output MP4 file has 1 H264 video and 1 AAC audio track.
>>
>> The application supports seeking on the input file to a specifc video
>> frame using
>> the seek API call.
>>
>> I added some diagnostics to FFmpeg to help me see what happens during
>> seek calls.
>>
>> So generally seeking works fine for me. I make seek API call on the video
>> track to a PTS and the MP4 demuxer
>> aligns its internal sample index pointers for each track, so the next
>> time demuxer reads for the next frame, it will
>> seek to  position the file pointer into the required offset to get the
>> required frame. The behaviour is predicatble
>> for input files that have audio and video tracks. So ffmpeg may 2 two
>> phyical file/stream seeks if it need to
>> locate the correct frame for audio and video.
>>
>> Posted this originally to ffmpeg-devel, which is the wrong mailing list
>> for this query so re-posting here. Apoligies for this.
>>
>>
>> However I have an issue when i Have an input flle with 6 tracks. 1 H264
>> Video track, 1 AAC audio
>> track, 2 Hint tracks (one for vidoe and audio), an OD track (has 1
>> sample) and a Scenes track (which has 1 sample).
>>
>> the layout of this file is ftyp-moov-mdat-free-free
>>
>> When I perform the seek API call this time on this file, the MP4 demuxer
>> as expected aligns its internal sample index pointer for each track, so the
>> next time we request a frame from demuxer it will seek to the correct
>> postiion in the file to get the correct frame.
>>
>> This works as expected, we seek into the correct  location in the file,
>> and align correctly for each of the other tracks.
>> Only 4 of the tracks have samples at the desired time, audio, video and
>> both hint tracks.
>>
>> So application is able to start demuxing the frames from this seek time
>> (e.g. 1 second) for
>> all 4 tracks.
>>
>> However after reading a certain amount of data another 2 seek requests
>> are made
>> internally by FFmpeg to a position in bothj of the Hint tracks at a time
>> unrelated
>> to the oriignal seek request e.g. 3 seconds.
>>
>> Im at a loss to explain, why FFmpeg internally needs to perform these 2
>> addiitonal
>> seek requests into each of the hint tracks, when no other seek API call
>> is made.
>>
>> Surely 1 seek request, results in at maximun 1 seek request per track.
>> However in this
>> case I have 2 seeks on the hint tracks.   The 'Scene'  and 'OD' track
>> dont have any sample
>> for this seek location.
>>
>> Im hoping someone can explain, why this happens and how predictable it is?
>>
>> Thanks
>>
>> _______________________________________________
>> Libav-user mailing list
>> Libav-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/libav-user
>>
>>
> I failed to fully understand your scenario, but you may want to set
> discard = AVDISCARD_ALL for streams you dont care about.
> Otherwise, if you have stream with only one sample, this effectively means
> you always seek right to the beginning of entire file, so seek is not
> efficient.
>
> _______________________________________________
> Libav-user mailing list
> Libav-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/libav-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20150422/b74a2b86/attachment.html>


More information about the Libav-user mailing list