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

[Robert Krüger]

On Wed, Sep 18, 2013 at 4:25 PM, Don Moir <donmoir at comcast.net> wrote:
>>>
>>>> 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

Not super-common but I think for some things like effects work in an
Apple workflow, where people want to avoid chroma subsampling, it's
the format of choice for many. Not sure how often alpha is really
activated in those files (the format allows to specify if alpha is
there or not in the bitstream IIRC).

> 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.

No, neither do I. That was just guessing

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

I agree.