On Thu, 2012-10-25 at 11:37 +0200, Kostya Shishkov wrote:
> On Thu, Oct 25, 2012 at 11:30:02AM +0200, Tomas Härdin wrote:
> > On Thu, 2012-10-25 at 06:43 +0200, Kostya Shishkov wrote:
> > > On Wed, Oct 24, 2012 at 09:27:57PM +0200, Luca Barbato wrote:
> > > > On 10/24/2012 04:15 PM, Tomas Härdin wrote:
> > > > > Oh boy, here we go.
> > > > >
> > > > > On Wed, 2012-10-24 at 12:10 +0200, Kostya Shishkov wrote:
> > > > >> @@ -1605,6 +1606,12 @@ static int transcode_init(void)
> > > > >> codec->codec_tag = icodec->codec_tag;
> > > > >> }
> > > > >>
> > > > >> + desc = avcodec_descriptor_get(codec->codec_id);
> > > > >> + if (desc && (desc->props & AV_CODEC_PROP_IDIOTIC)) {
> > > > >
> > > > > AV_CODEC_PROP_IDIOTIC? How professional.
> > > >
> > > > Surely AV_CODEC_PROP_DISCOURAGED with a -strict suggest mode to output a
> > > > rationale on why certain codecs should not be generally used beside for
> > > > compatibility, might be a good service.
> > > >
> > > > The patchset as it doesn't really help anybody since "idiotic" as for
> > > > "lovely" is one of those English words with too many meanings and
> > > > nuances.
> > >
> > > This patchset was not serious and it should be obvious from the property
> > > name
> > > selection. But I hoped it might encourage people do something good
> > > instead.
> >
> > What about something like AV_CODEC_PROP_UNMAINTAINED?
>
> That's completely different - the original "intent" was to discourage users
> from creating new files with formats that are not well designed at best. For
> example, Monkey Audio is still maintained but I'd rather not see people
> encode in that format because it's horrible starting from container.
There doesn't appear to exist an encoder or muxer for Monkey's Audio, so
that point may be moot for that format. For the other formats it sounds
like you want to remove support for muxing them. If so, then remove that
support and prepare for user wrath. If not, then this seems pointless -
either you support the formats or you don't.
Oh, and I sincerely hope you're not talking about removing decoding
support, for any format. This doesn't seem to be the case, AFAICT (due
to codec->codec_id and ost->st->codec->codec_id).
/Tomas
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
