Hi, On Fri, Apr 8, 2011 at 10:42 AM, Anton Khirnov <[email protected]> wrote: > 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.
I agree, again. But I don't think duplicating the define is any better. In fact, it's worse. Can we expose this somehow through private API? Can you think of other solutions? Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
