On Fri, Apr 08, 2011 at 10:07:32AM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Apr 8, 2011 at 9:47 AM, Anton Khirnov <[email protected]> wrote: > > On Fri, Apr 08, 2011 at 07:43:35AM -0400, Ronald S. Bultje wrote: > >> On Fri, Apr 8, 2011 at 5:48 AM, Anton Khirnov <[email protected]> wrote: > >> > --- > >> > ffmpeg.c | 2 ++ > >> > ffserver.c | 1 + > >> > libavformat/avformat.h | 6 ------ > >> > libavformat/ffm.h | 5 +++++ > >> > 4 files changed, 8 insertions(+), 6 deletions(-) > >> > > >> > diff --git a/ffmpeg.c b/ffmpeg.c > >> > index 83e77dd..749c9c7 100644 > >> > --- a/ffmpeg.c > >> > +++ b/ffmpeg.c > >> > @@ -110,6 +110,8 @@ static const OptionDef options[]; > >> > #define MAX_STREAMS 1024 /* arbitrary sanity check value */ > >> > #endif > >> > > >> > +#define FFM_PACKET_SIZE 4096 > >> > + > >> > static const char *last_asked_format = NULL; > >> > static AVFormatContext *input_files[MAX_FILES]; > >> > static int64_t input_files_ts_offset[MAX_FILES]; > >> > >> Hacking ffserver is one thing, but this goes a little far. How about > >> we make this a private AVOption? What is the exact use-case here? > > > > ffmpeg uses this value as the buffer size for ffm streams. > > Can we think of a cleaner way to export this? What about the other > ffm_*() functions? Does ffserver use them (I bet it does). >
ffserver uses them, but i gave up trying to keep it clean. I'd like to keep those hacks from ffmpeg though. Duplication is not nice, but duplicating one line is much better than including a private header. -- Anton Khirnov
signature.asc
Description: Digital signature
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
