[FFmpeg-devel] [PATCH] Make decoding alpha optionalforsomecodecs.

[Don Moir]

>>
>>> On Wed, Sep 18, 2013 at 2:54 PM, Don Moir <donmoir at comcast.net> wrote:
>>>>
>>>>
>>>>> On Wed, Sep 18, 2013 at 1:33 PM, Kieran Kunhya <kierank at obe.tv> wrote:
>>>>>>
>>>>>>
>>>>>> This patch is a good idea for quick previews and the likes.
>>>>
>>>>
>>>>
>>>> If it's the default behavior, maybe. If it's not the default behavior,
>>>> you
>>>> might have to dig up the option that would only work sometimes and
>>>> probably
>>>> add more confusion.
>>>
>>>
>>> Of course it should not be default behavior and that's what Michael
>>> suggested and I think that's good because people who know how to use
>>> it can and others don't need to worry about it. If all I have to do in
>>> our video player to get a few percent less CPU load for these formats
>>> is to set an option for a given list of formats (might not even be
>>> necessary if the codec would simply ignore the flag if it does not
>>> apply), I would certainly do that.
>>
>>
>> Yes, originally it just wasn't clear before comments came in and just to be
>> sure.
>>
>>
>>>>> and basically every video player. E.g. quicktime displays full
>>>>> transparency in Prores4444 as black and so does FCP. You only see the
>>>>> alpha if you actually have an overlay. So people building software for
>>>>> looking at single video clips would probably like it to behave the
>>>>> same and if that can be achieved with less CPU it definitely has
>>>>> value.
>>>>
>>>>
>>>>
>>>> I suspect no measurable CPU decrease on a modern computer and some on
>>>> older
>>>> computers. If user has a computer that can barely keep up, well he has
>>>
>>>
>>> Just curious, on what do you base the assumption?
>>
>>
>> I base it on extreme testing. I have an i7 next to me where I ran 15 HD
>> videos at same time and it wasn't even breathing hard.
>>
>> On my slower machine, yes it might make a difference but probably not by
>> much. If user is watching general video in all shapes and sizes on low end
>> computer, his experience can't be that good.
>
> OK. I work on a software for video editors and in that area Apple
> Prores is a very common format and when you play 1080 Prores4444 on an
> entry-level Macbook Pro (dual-core i5), it is indeed working quite a
> bit (after all it typically crunches 200-300 MBit of encoded data per
> second). My point is that I have a gut feeling that there may be
> real-world use cases where saving, say 5%, decoding time might make
> the difference between good and mediocre playback and the suggested
> option (whichever way it is implemented) seems to offer something
> there.

Yeah ok. I was not sure how common Proress4444 was. We don't know if it's a 5% CPU savings or what. Probably not that high but 
maybe.

I am not sure what the actual measurement is... If 4 planes take 24 ms to decode then maybe 3 planes take 18 ms to decode? Don't 
know what the actual numbers are and will vary of course.

Don't get me wrong either. I am all for saving CPU cycles whenever as long as you get expected results.