[FFmpeg-devel] [PATCH] Make sure AVFormatContext->start_time is initialized after the first patch

[Baptiste Coudurier]

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 
need to.

> 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..

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org