[FFmpeg-devel] [PATCH] codec_desc: mark CFHD as intra-only

James Almer jamrial at gmail.com
Wed Jun 10 15:46:21 EEST 2020


On 6/10/2020 6:19 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-06-09 14:45:33)
>> On 6/9/2020 6:06 AM, Anton Khirnov wrote:
>>> I don't think this needs to be visible externally, since it's only
>>> meaningful for internal use. I'm wondering if the presence of
>>> update_thread_context() callback won't be sufficient for this.
>>
>> True, it could be a caps_internal. But take for example the possibility
>> of an external library with a fully featured decoder getting a wrapper,
>> this being a public capability would let the user choose it over the
>> internal one, same as how it can choose a stable decoder over an
>> experimental one, or a software one over an hybrid/hw one.
> 
> I don't see why this should be a criterium for the user to base any
> decisions on. It's purely an internal implementation detail that's tied
> to the way frame threading is currently implemented and can potentially
> change later. So I don't see why it should be accessible through the
> API.

An intra only decoder returns I frames only. A fully feature decoder
would return I and P (and actually get you something other than a key
frame slideshow). Or at least that's how i understood it.
Giving the user a way to choose the best decoder for their needs is not
too crazy. We already do with other implementation specific
capabilities, as i mentioned above.

> 
> Also, not sure if you saw but I have new patch fixing this problem in
> another manner.

Yes, i saw. I'm arguing about this other approach because if it's done
now, it can be done seamlessly (Just revert the change and pretend the
flag was never deprecated). After 4.3 is effectively tagged, we would
require to undo the deprecation with another API change, and it will
look messy.

The flag was meaningless and a duplicate of the codec prop, but now we
found a way to use it to actually convey information about a decoder, so
why not do it?


More information about the ffmpeg-devel mailing list