Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Ronald S. Bultje
Hi,

On Fri, Apr 8, 2011 at 5:48 AM, Anton Khirnov an...@khirnov.net 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?

Ronald
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Anton Khirnov
On Fri, Apr 08, 2011 at 07:43:35AM -0400, Ronald S. Bultje wrote:
 Hi,
 
 On Fri, Apr 8, 2011 at 5:48 AM, Anton Khirnov an...@khirnov.net 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.
I don't think it belongs in a public header.

-- 
Anton Khirnov


signature.asc
Description: Digital signature
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Ronald S. Bultje
Hi,

On Fri, Apr 8, 2011 at 9:47 AM, Anton Khirnov an...@khirnov.net 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 an...@khirnov.net 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
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Anton Khirnov
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 an...@khirnov.net 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 an...@khirnov.net 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
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Ronald S. Bultje
Hi,

On Fri, Apr 8, 2011 at 10:42 AM, Anton Khirnov an...@khirnov.net 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 an...@khirnov.net 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 an...@khirnov.net 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
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel


Re: [libav-devel] [PATCH 3/5] lavf: get rid of ffm-specific stuff in avformat.h

2011-04-08 Thread Ronald S. Bultje
Hi,

On Fri, Apr 8, 2011 at 10:45 AM, Ronald S. Bultje rsbul...@gmail.com wrote:
 Can we expose this somehow through private API? Can you think of other
 solutions?

Private API == AVOption or so, not ff_*() API.

Ronald
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel