[FFmpeg-devel] [PATCH] Make decoding alphaoptionalforsomecodecs.

[Don Moir]

----- Original Message ----- 
From: "Robert Krüger" <krueger at lesspain.de>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, September 18, 2013 10:32 AM
Subject: Re: [FFmpeg-devel] [PATCH] Make decoding alphaoptionalforsomecodecs.


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

I was thinking alpha was probably rare for that usage but I don't know.

One thing to test would be to run the same video coded with and without alpha and see what happens.

>> 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.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel