[Bug 693175] Endianness inconsistency in ffmpegcolorspace caps

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=693175
  GStreamer | gst-plugins-base | 0.10.36

--- Comment #3 from Youness Alaoui <youness.alaoui at collabora.co.uk> 2013-02-05 19:55:00 UTC ---
(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...

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.