[FFmpeg-devel] [PATCH] Make decoding alpha optional forsomecodecs.
krueger at lesspain.de
Wed Sep 18 16:13:42 CEST 2013
On Wed, Sep 18, 2013 at 3:40 PM, Don Moir <donmoir at comcast.net> wrote:
> ----- 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 9:18 AM
> Subject: Re: [FFmpeg-devel] [PATCH] Make decoding alpha optional
>> 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,
>>> might have to dig up the option that would only work sometimes and
>>> 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
>>>> 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
>>> I suspect no measurable CPU decrease on a modern computer and some on
>>> 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
More information about the ffmpeg-devel