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

Benjamin Larsson banan
Mon Dec 14 22:08:59 CET 2009

Jai Menon wrote:
> 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

20623 is the culprit, should be fixed now in svn.

Benjamin Larsson

More information about the ffmpeg-devel mailing list