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

[James Almer]

On 6/12/2020 7:05 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-06-10 14:46:21)
>> 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?
> 
> It still seems to me that this is a solution in search of a problem. If
> I understand you correctly, the case you have in mind is a codec where
> there is an internal implementation that only supports intra frames
> and an external implementation that also supports inter frames.
> But that seems incredibly contrived to me. For one thing, I don't know
> of any actual situations like this, now or in the past.

What do you think prompted the whole issue with the intra-only flag used
for cfhd if not the fact the internal decoder is intra only when the
codec itself isn't?

> For another, why
> pick out specifically the ability to decode intra vs inter frames?

Because the flag already exists. I wouldn't suggest to introduce it if
it didn't. I'm saying it could be easily and seamlessly repurposed.

Anyway, no point arguing about something as obscure as this scenario (Of
which only one case exists, as stated by Kieran, and it's a matter of
merging an old gsoc patch to render it moot), so i'm not going to insist
on it.
I already approved your alternate solution for the threading issue, for
that matter.

> There is a huge number of codec features that may be potentially
> unsupported by various implementations (see e.g. AAC) and there's no
> sane way we can have capability flags for them all.
>