On date Saturday 2011-07-30 13:36:41 +0200, Luca Barbato encoded:
> On 7/30/11 1:25 PM, Stefano Sabatini wrote:
> >On date Saturday 2011-07-30 12:13:48 +0200, Luca Barbato encoded:
> >>On 7/29/11 8:03 PM, Stefano Sabatini wrote:
> >>>If you want to rename the tools just do them consistent:
> >>>avprobe
> >>>avplay
> >>>so the pattern here is av+VERB
> >>>
> >>>avconvert/avmux is consistent with this pattern, avconvert looks a
> >>>more intuitive name.
> >>
> >>I'd rather name it just "av" the name is available and the shorter
> >>the better. I do agree that avconv/avconvert is more intuitive but
> >>mux seems to cover better what av.c should provide.
> >

> >av =>  unexplicative
> 
> I know, but gives you the idea "does stuff on audio video" like "ip"
> does stuff on the ip protocol.

"does stuff on audio video", it applies to all the other tools as
well.

> >avmux =>  the tool muxes, but it's not the only thing that the tool
> >does, "avconvert" explicates better what the tool does (convert A/V/S
> >streams).
> 
> Indeed both cover just a side of it.
> 

> >On the same ground, maybe ffserver =>  av+stream, "server" doesn't tell
> >what the tool does.
>
> avserver tells us that the program serves audio/video so might still
> be easy to get.

My point was also about the fact that "avserver" doesn't match the
av+VERB pattern.

...

I'm used to follow these naming rules, and I'm usually satisfied with
whatever respects them:
1. use meaningful names (possibly meaningful even out-of-context)
2. use globally consistent names (that is, design a common scheme and
   try to follow it)
3. adopt a namespace-resolution method when conflicts may arise
4. favor shorter names, or easier to read/speech/remember/type, when
   more options are available

Of course you're free to ignore my comments.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to