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).

> I don't think it belongs in a public header.

I agree.

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to