Luca Barbato lu_z...@gentoo.org added the comment:
Fixed
--
status: open - closed
substatus: open - fixed
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2318
landhar de...@larre-borges.com added the comment:
lu_zero says that the issue comes from the fact that the default values for the
stream and the codec are different. Isn't there any way to override this values
from the configuration file ?
On the other hand, his patch works in my machine.
Luca Barbato lu_z...@gentoo.org added the comment:
That's because the whole machinery got broken by the fact the codec defaults and
the stream defaults now are different (one is 0/0 the other 0/1). I have a
stupid patch to fix that by overwriting the value.
Still we should either rethink this
Luca Barbato lu_z...@gentoo.org added the comment:
Update topic
--
topic: +ffserver
FFmpeg issue tracker iss...@roundup.ffmpeg.org
https://roundup.ffmpeg.org/issue2318
Colin Law clan...@googlemail.com added the comment:
It is unclear to me from the earlier reports here whether this bug is fatal or
whether the server continues. For me it is fatal. Using the sample config file
from http://www.ffmpeg.org/sample.html but with all streams except mutlipart
jpeg
Rocky rocky.cardw...@lifespringschool.org added the comment:
This seems to have been introduced in revision 25338 with changes to the
av_cmp_q function in libavutil/rational.h. I don't understand it well enough to
fix it but as a workaround it works for me when I use the rational.h file from
Carl Eugen Hoyos ceho...@rainbow.studorg.tuwien.ac.at added the comment:
Described as a regression.
--
priority: normal - important
status: new - open
substatus: new - open
topic: +regression
FFmpeg issue tracker
Benjamin Larsson ba...@ludd.ltu.se added the comment:
/ffmpeg6.1/ffmpeg-0.6.1$ ./ffserver -f ffserver.conf
FFserver version 0.6.1, Copyright (c) 2000-2010 the FFmpeg developers
built on Oct 22 2010 15:31:23 with gcc 4.4.3
configuration: --enable-libmp3lame --enable-libfaac --enable-nonfree
