Skąd się bierze różnica w kolejności kolorów na Windows i Linux?

Generuje plik video a źródłem obrazu jest widget ktory jest wielokrotnie przerysowywany i przechwytywany jest jego obraz

Tak wyciągam pamięć obraz z widgetu

const QImage &frame(grabFramebuffer());
const uchar *bits = frame.constBits();

I potem używam libffmpeg aby wygenerować video
Na Windows muszę ustawić format danych wejściowych AV_PIX_FMT_BGRA a na Linux AV_PIX_FMT_RGBA
Czyli w buforze ktory dostałem od Qt jest odwrotna kolejność kolorów

Tak sie zastanawiam skąd się bierze różnica kolejności kolorów?
Dokumentacja grabFramebuffer Renders and returns a 32-bit RGB image of the framebuffer.
Ale może w tym przypadku RGB oznacza tylko ze sa trzy kolory a kolejnosc to już inna para kaloszy

Pamiętam ze kiedyś w Larazus tez była odwrócona kolejność kolorów pomiędzy Windows i Linux jak sie odczytywało pamięć BITMAP na niskim poziomie

Taka tylko ciekawostka

W wielu miejscach widzę konfigurowalność kolejności (i ilości rozmiaru) składowych RGB(A). Najbardziej podstawowy powód, jaki przychodzi mi do głowy to endianness. Logicznym wydaje się, żeby kolor RGB(A) przechowywać w incie i używać masek do pobierania składowych. Tylko, że na różnych procesorach, kolejne bajty są zapisywane w różnej kolejności. XLib tego wymaga (w końcu to protokół sieciowy, nie jest powiedziane, że aplikacja jest na tej samej maszynie co serwer X11). Kod napisany np. w C ma chodzić na różnych architekturach. Głupio byłoby w każdym miejscu robić jakieś kompilacje warunkowe odnośnie masek. Lepiej jest raz załadować maskę i dalej kod jest niezależny od architektury. W związku z tym, logiczne, że QT kontynuuje tę logikę. W końcu QT zdaje się było projektowane głównie z myślą o Xach.

Przecież linux i windows na tym samym komputerze z procesorem amd64 będą miały taki sam endiannes. Poza tym - gdyby to była kwestia LE/BE to przestawiony byłby też kanał alpha.