What Alexander means to say is that the caps for ffmpegcolorspace use big endian for 24 and 32 bpp, but little endian for 16 bpp as can be seen with gst-inspect : 
http://privatepaste.com/bac504a359

So the question is whether or not it's intentional or if there's a bug in ffmpegcolorspace which should use BIG_ENDIAN for bpp=16 instead of BYTE_ORDER. Or if it's normal and the problem is his camera driver which should be outputting little endian when it's capturing in 16 bpp.

      video/x-raw-rgb
                    bpp: 32
                  depth: 32
             endianness: 4321
                    ...
      video/x-raw-rgb
                    bpp: 16
                  depth: 16
             endianness: 1234
                    ...

(In reply to comment #0)
> Is it normal that bpp=24 and bpp=32 have endianness=4321 but bpp=16 has
> endianness=1234?

24 and 32 bits are always big endian, we use the masks to say where the R,G,B is.

For 16 bits it depends on how the bytes are in memory. You need to look at how 16 bits are placed inside the memory by the driver and then put this in the endianness property.

ffmpegcolorspace can only handle the native endianness for 16 bits so it only exposes BYTE_ORDER.

(In reply to comment #2)
> (In reply to comment #0)
> > Is it normal that bpp=24 and bpp=32 have endianness=4321 but bpp=16 has
> > endianness=1234?
> 
> 24 and 32 bits are always big endian, we use the masks to say where the R,G,B
> is.
> 
> For 16 bits it depends on how the bytes are in memory. You need to look at how
> 16 bits are placed inside the memory by the driver and then put this in the
> endianness property.
> 
> ffmpegcolorspace can only handle the native endianness for 16 bits so it only
> exposes BYTE_ORDER.

Ok, in that case, I suggest ffmpegcolorspace should handle both. v4l2src has in its caps both endianness 1234 and 4321 for 16 bits rgb. And in the case of alex's device, he gets 4321 as output, but he can't link v4l2src to ffmpegcolorspace because of that (unless he forces a different bpp through a capsfilter).
I would then suggest adding a endianness conversion method to ffmpegcolorspace to allow it to convert the format properly.

p.s: I checked 1.0. All I see is RGB16, BGR16 (in videoconvert and v4l2src), but no way to determine if it's LE or BE. If v4l2 allows for specifying LE and BE formats in 16 bits, then v4l2src is missing something...

Maybe I'm confused, but isn't it like this (in 1.0):

RGB16 = in bits inside an uint16_t: RRRR RGGG GGGB BBBB
BGR16 = in bits inside an uint16_t: BBBB BGGG GGGR RRRR

So basically both are a mirror image of each other, like LE/BE.

So if it's all expressed in terms of big endian:

BGR16 == BGR16_BE == RGB16_LE and
RGB16 == RGB16_BE == BGR16_LE

?

No, our RGB16/15 and BGR16/15 are native endianness only, there is no LE/BE variant.

So let's close this?