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

Martin Storsjö martin
Wed Jun 2 09:33:20 CEST 2010


On Fri, 28 May 2010, Martin Storsj? wrote:

> On Fri, 28 May 2010, Baptiste Coudurier wrote:
> 
> > On 05/25/2010 11:57 AM, Michael Niedermayer wrote:
> > > On Tue, May 25, 2010 at 12:54:50AM +0300, Martin Storsj? wrote:
> > > > Hi,
> > > > 
> > > > When discussing a ffserver patch with Baptiste, he insisted that if
> > > > AVFormatContext->start_time isn't initialized after the first packet, it's
> > > > a bug that should be fixed within libavformat, instead of handled in
> > > > ffserver.
> > > > 
> > > > This attached patch is one way of solving it, although I'm not sure if
> > > > this is the correct way.
> > > 
> > > 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
> > 
> > Hummm, av_find_stream_info should set the start_time however.
> > Isn't av_find_stream_info called ?
> 
> As far as I can see in open_input_stream, we first call 
> av_find_stream_info, then a few lines later do av_seek_frame.

Baptiste, ping?

With the current code:

    if (ist->start_time != AV_NOPTS_VALUE)
        c->cur_pts -= av_rescale_q(ist->start_time, ist->time_base, AV_TIME_BASE_Q);

Either we assume that start_time shouldn't ever have the value 
AV_NOPTS_VALUE - in that case we should just remove the if and change it 
into an assert instead.

If not, if there's even a remote chance that start_time could be 
AV_NOPTS_VALUE in some cases, this if statement absolutely needs an else 
branch. If not, the same problem (an absolute timestamp where a relative 
one was expected) will appear in the rest of ffserver somewhere.

// Martin



More information about the ffmpeg-devel mailing list