[FFmpeg-devel] ffserver broken between r20620 and r20627 (r20621?)

Jai Menon jmenon86
Mon Dec 14 15:19:11 CET 2009


On Mon, Dec 14, 2009 at 07:34:59PM +1100, Naz wrote:
> Jai Menon wrote:
> >On Sun, Dec 13, 2009 at 02:14:41PM +1100, Naz wrote:
> >>I have been using ffserver for some time now, quite successfully.
> >>However, recently ffserer functionality has been broken. After much
> >>recompiling, I found out that the break occurred on Nov 28th; r20620
> >>works while r20627 does not.
> >>
> >>The break does not appear to be x264 related, as the issue manifests
> >>even when I use vanilla flv. It may not even be a bug in ffserver.c
> >>as ffserver starts fine, but ffmpeg does not begin streaming when it
> >>is instantiated, so it could be a bug in the way that ffmpeg
> >>determines the required output from the ffm file.
> >>
> >>After a quick perusal of the svn log, I think that it was r20621
> >>that did it, as that sounds like it changed the way ffm was handled
> >>and checked.
> >
> >Are you sure about this? That commit just cleans up after r20601 and
> >updates our regression ref checksums. Could you try bisecting r20600
> >and r20601? Also, does reverting r20601 "fix" this for you?
> >
> r20620 and all revisions before that work as expected. r20627 and
> later do not. I've tested a build every 24 hours from Oct 1 through
> to Dec 10.
> 
> As I said, I don't know if that is the build that did it, but I *do*
> know that <20620 works while >20627 do not.

1) Revert r20621 and check if it fixes the problem (though i _really_
doubt that happening)

2) Make sure you are testing against ffmpeg and ffserver from the same
revision (though that probably shouldnt matter)

3) Since you already know the regression exists between [20619,
20628], try bisecting it to narrow down the exact commit.

Thanks.

--
Jai Menon




More information about the ffmpeg-devel mailing list