On 07/09/16 11:25, Carl Eugen Hoyos wrote:
Hi!
Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" <sven.c.d...@sky.com>:
On 07/09/16 09:23, Timo Rothenpieler wrote:
Otherwise will RGBA/BGRA have to
be converted into RGB0/BGR0
and you will again get a performance penalty.
What makes you think so?
I have tested it. What makes you think it wouldn't?
(The problem is that your encoder now reports "I support transparency" and this
will lead to funny effects depending in the colour space of your input file.)
No, it doesn't. The encoder does deal with transparency. It effectively ignores
it. So it is save to pass it on without FFmpeg needing to set the value to 0 but
let the encoder do it.
Please also implement my other suggestion to make documentation and
implementation match (and to match existing and new colour spaces, there is
already an endianness-depending pix_fmt).
I have no idea what you are talking about. If you want to implement a new pixel
format and colour space for what seems to be a mere twist in Nvidia's
documentation then you are welcome to do so. I won't.
Sven
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
