[FFmpeg-devel] [PATCH] Make sure AVFormatContext->start_time is initialized after the first patch
Wed Jun 2 22:57:16 CEST 2010
On 06/02/2010 01:50 PM, Martin Storsj? wrote:
> On Wed, 2 Jun 2010, Baptiste Coudurier wrote:
>> On 06/02/2010 01:17 PM, Martin Storsj? wrote:
>>> Quoting Michael:
>>>> The problem might be that ffserver calls av_seek_frame()
>>>> with that the first packet demuxed might no longer correspond to the
>>>> first packet.
>>>> thus i think its not unreasonable if lavf doesnt set start_time to the
>>>> first dts/pts once seeking has happened
>> _doesn't set_ does _not_ mean _unset_
>> start_time should be _set_ by av_find_stream_info _before_ the seek.
> Actually, reading the code a bit more in detail, the code doesn't call
> av_find_stream_info at all for inputs where iformat->name is "ffm".
> Is there any particular reason for that?
This explains better why start_time is not set.
I think that's because there is no need to call it: all information is
stored in the ffm file, codec time base, codec pix_fmt, so there is no
> Also, when reading the current ffserver code in more detail, the current
> code that does
> c->cur_pts -= av_rescale_q(ist->start_time, ...)
> ist->start_time in this case is the start time of this particular stream,
> which could be slightly different for each stream. Shouldn't the absolute
> to relative calculation be done using the same fixed origin for all
> streams? That is, use c->fmt_in->start_time (which gets populated if
> av_find_stream_info is called) or c->first_pts instead of ist->start_time?
I think you may be right, but extra checks where the values are used are
needed, like how is cur_pts used, set, etc..
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel