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