"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2011/9/23 Måns Rullgård <[email protected]>: >> "Ronald S. Bultje" <[email protected]> writes: >>> 2011/9/23 Måns Rullgård <[email protected]>: >>>> Alex Converse <[email protected]> writes: >>>>> On Thu, Sep 22, 2011 at 5:51 PM, Justin Ruggles >>>>> <[email protected]> wrote: >>>>>> On 09/22/2011 08:33 PM, Måns Rullgård wrote: >>>>>>> Benjamin Larsson <[email protected]> writes: >>>>>>>> On 09/23/2011 12:10 AM, Diego Biurrun wrote: >>>>>>>>> --- >>>>>>>>> libavformat/utils.c | 1 + >>>>>>>>> 1 files changed, 1 insertions(+), 0 deletions(-) >>>>>>>>> >>>>>>>>> diff --git a/libavformat/utils.c b/libavformat/utils.c >>>>>>>>> index 05d4fda..17b342e 100644 >>>>>>>>> --- a/libavformat/utils.c >>>>>>>>> +++ b/libavformat/utils.c >>>>>>>>> @@ -852,6 +852,7 @@ static int is_intra_only(AVCodecContext *enc){ >>>>>>>>> case CODEC_ID_MJPEG: >>>>>>>>> case CODEC_ID_MJPEGB: >>>>>>>>> case CODEC_ID_LJPEG: >>>>>>>>> + case CODEC_ID_PRORES: >>>>>>>>> case CODEC_ID_RAWVIDEO: >>>>>>>>> case CODEC_ID_DVVIDEO: >>>>>>>>> case CODEC_ID_HUFFYUV: >>>>>>>> >>>>>>>> How about a codec capability instead ? >>>>>>> >>>>>>> WTF is that used for at all? >>>>>> >>>>>> >>>>>> looks to me like a shortcut to not require all the demuxers set the key >>>>>> frame flag like they're supposed to. >>>>> >>>>> For mov files the keyframe box is often missing for intra only >>>>> streams. I'm sure some other formats are similar. >>>> >>>> Then codec_cap flag makes more sense than keeping lists like this >>>> floating around. >>> >>> I believe this list exists so that we have the freedom to add new >>> codecIDs without implementing the actual decoder (in which case the >>> struct that specifies the flag is missing). In that case, transmuxing >>> will produce the expected results. >>> >>> But yes the list is brittle also... Maybe we need both: a list for >>> those where codecs are still missing and a flag for codecs that exist. >> >> Due various design lunacies, it is impossible to do anything with a >> stream for which no codec exists. > > We can fix that. Please think forward, not backward.
Are you volunteering to rewrite libavformat from scratch? -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
