[FFmpeg-devel] [RFC] Split libavformat

[Diego Biurrun]

On Thu, Nov 22, 2007 at 02:28:28PM +0100, Luca Abeni wrote:
> 
> Diego Biurrun wrote:
> > On Thu, Nov 22, 2007 at 12:59:07PM +0100, Michael Niedermayer wrote:
> >> On Thu, Nov 22, 2007 at 10:03:20AM +0100, Luca Abeni wrote:
> >>> Luca Abeni wrote:
> >>>> Diego Biurrun wrote:
> >>>> [...]
> >>>>>> +    REGISTER_INDEVOUTDEV (AUDIO_BEOS, audio_beos);
> >>>>> Maybe INOUTDEV would sound better.
> >>>> Ok. configure does not seem to like it; I am investigating the reason
> >>>> and I hope to fix this soon.
> >>> ...And this is the new patch. I hope I addressed all the comments.
> >>> I even went one step further and changed all the *_muxer and *_demuxer
> >>> structure names to *_outdev and *_indev (so the patch is bigger, now).
> >>> If this is wrong, I will remove this last change.
> >> renames (which are pure cosmetic changes) must be seperate
> >> also i dont see any sense in the renames
> > 
> > Which renames?  If it is about the format registration I disagree,
> > calling the input/output devices (de)muxers is suboptimal.
> 
> I think Michael is referring to the fact that in my last patch I changed
> +#define REGISTER_OUTDEV(X,x) { \
> +          extern AVOutputFormat x##_muxer; \
> +          if(ENABLE_##X##_OUTDEV)   av_register_output_format(&x##_muxer); }
> in
> +#define REGISTER_OUTDEV(X,x) { \
> +          extern AVOutputFormat x##_muxer; \
> +          if(ENABLE_##X##_OUTDEV)   av_register_output_format(&x##_outdev); }
> which forces to introduces hunks like:
> Index: ffmpeg/libavdevice/v4l2.c
> ===================================================================
> --- ffmpeg.orig/libavdevice/v4l2.c      2007-11-22 12:48:08.000000000 +0100
> +++ ffmpeg/libavdevice/v4l2.c   2007-11-22 12:48:43.000000000 +0100
> @@ -631,7 +631,7 @@
>       return 0;
>   }
> 
> -AVInputFormat v4l2_demuxer = {
> +AVInputFormat v4l2_indev = {
>       "video4linux2",
>       "video grab",
>       sizeof(struct video_data),
> in the patch.
> 
> So, what I am planning to do is to remove these changes (that can be committed
> in a second time, because they do not affect the API).
> Of course, the other MUXER ---> DEV changes that are you requested yesterday
> are not affected by this.

Yes, I was referring to that as well.  If you prefer, split that off.

This reminds me that there were a few cosmetic hunks in configure.
These could be split as well.

Diego