user11789: I was wondering about the difference between rgb and bgr pixel formats available in many codecs.
It reminds me in some way the Big Endian and Little Endian flavours of computer processors.
While I always guessed that the big / little endian was more a matter of patents rather than performance, why we have both rgb and bgr?

It's still a matter of patents?  
Have something to do with Subpixels Rendering ?  
Why some codecs has alternate support of them like this huffyuv example here:


Encoder huffyuv [Huffyuv / HuffYUV]:
  Threading capabilities: no
  Supported pixel formats: yuv422p rgb24 bgra

It has rgb24 but then not rgba as I could expect. It jumps directly to bgra!  
Could be again a matter of patents that the codec author could not break ?

Please feed my curiosity with some extended explaination here if possible, i want to know something more about this various pixel formats!

user4169: 
While I always guessed that the big / little endian was more a matter of patents rather than performance,

Nope little endian was developed as a performance optimization whern moving to multi byte words. https://en.wikipedia.org/wiki/Endianness#Optimization
Nothing to to with patents. Different representation have different advantages and disadvantage. Hence different situations may use different representations. Codecs suffer from network effect. Nobody wants to use your encoder if nobody uses your decoder. And vice-versa. So codec designers go for maximum compatibility, and often support several formats. But the usually don't support them all, because there are dozens. So they use a combination of the most common, and easiest to include into the design.

user1871: The order of the components in RGB32 seems to do with endianness:

PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA color
  is put together as: (A << 24) | (R << 16) | (G << 8) | B This is
  stored as BGRA on little-endian CPU architectures and ARGB on
  big-endian CPUs.

The descriptions of the various related formats enumerated on that page provide more details.

11789: <p>I was wondering about the difference between <strong>rgb and bgr pixel formats</strong> available in many codecs.</p>

<p>It reminds me in some way the Big Endian and Little Endian flavours of computer processors.</p>

<p>While I always guessed that the big / little endian was more a matter of patents rather than performance, why we have both rgb and bgr?</p>

<ul>
<li>It's still a matter of patents?  </li>
<li>Have something to do with <a href="https://en.wikipedia.org/wiki/BGR_%28subpixels%29" rel="nofollow">Subpixels Rendering</a> ?  </li>
<li>Why some codecs has alternate support of them like this huffyuv example here:</li>
</ul>

<blockquote>
  <p>Encoder huffyuv [Huffyuv / HuffYUV]:<br>
  Threading capabilities: no<br>
  Supported pixel formats: yuv422p <strong>rgb24 bgra</strong></p>
</blockquote>

<p>It has <strong>rgb24</strong> but then not <strong>rgba</strong> as I could expect. It jumps directly to <strong>bgra</strong>!  </p>

<p>Could be again a matter of patents that the codec author could not break ?</p>

<hr>

<p>Please feed my curiosity with some extended explaination here if possible, i want to know something more about this various pixel formats!</p>
 4169: <blockquote>
  <p>While I always guessed that the big / little endian was more a matter of patents rather than performance,</p>
</blockquote>

<p>Nope little endian was developed as a performance optimization whern moving to multi byte words. <a href="https://en.wikipedia.org/wiki/Endianness#Optimization" rel="nofollow">https://en.wikipedia.org/wiki/Endianness#Optimization</a></p>

<p>Nothing to to with patents. Different representation have different advantages and disadvantage. Hence different situations may use different representations. Codecs suffer from network effect. Nobody wants to use your encoder if nobody uses your decoder. And vice-versa. So codec designers go for maximum compatibility, and often support several formats. But the usually don't support them all, because there are dozens. So they use a combination of the most common, and easiest to include into the design.</p>
 1871: <p>The order of the components in RGB32 seems to do with <a href="https://www.ffmpeg.org/doxygen/0.5/pixfmt_8h.html" rel="nofollow">endianness</a>:</p>

<blockquote>
  <p>PIX_FMT_RGB32 is handled in an endian-specific manner. An RGBA color
  is put together as: (A &lt;&lt; 24) | (R &lt;&lt; 16) | (G &lt;&lt; 8) | B This is
  stored as BGRA on little-endian CPU architectures and ARGB on
  big-endian CPUs.</p>
</blockquote>

<p>The descriptions of the various related formats enumerated on that page provide more details.</p>
