[vlc-devel] RGB capture issues in DirectShow

[Rémi Denis-Courmont]

	Hello,

Le lauantaina 11. helmikuuta 2017, 19.17.23 EET Salah-Eddin Shaban a écrit :
> The orientation issue is that frames are bottom to top, and should be
> flipped before rendering. But the statement in line 720 of dshow.cpp
> 
> fmt.video.orientation = ORIENT_BOTTOM_LEFT;

I made VLC use the EXIF orientation syntax as reference because it 
unambiguous. The first term is where the top field goes, the second is where 
the left field goes. So Bottom-Left means that the image is flipped around the 
horizontal axis.

I much prefer this over the popular horizontal/vertical flip, and 270/90 
degrees rotation terminology. You never know if the flip name their axis or 
their direction, and you never know if the rotation are trigonometic/direct or 
clock-wise/indirect.

> is interpreted differently by different vout modules. When using
> direct3d11 it seems to have no effect (so frames are still rendered
> upside down). With direct3d9 it causes horizontal (not vertical)
> flipping, so the end result looks like this
> 
> https://drive.google.com/open?id=0B36ioujDBJZsZ0w1cDIyTzJkUjg
> 
> With --vout=opengl however it is rendered correctly.
> 
> So this is not a DShow bug right?

Well, yeah. I mean, obviously if different video outputs behave differently, 
it has to be a bug in video outputs...

> In which case #11778 should be fixed in the direct3d vout modules.
> 
> The chroma issue is swapped red and blue. This happens with all
> capture sources that use RGB24 output. I have tested with one USB
> webcam and three virtual video devices (Fake Webcam, ManyCam, and
> screen-capture-recorder).
> 
> I have attached a small patch that shows the first 12 bytes of
> block_t's just before they are passed to es_out_Send. In this case the
> capture source outputs bluish solid-color frames of R=0x2b, G=0x9b,
> B=0xd8
> 
> When capturing in RGB24:
> dshow debug: DShow format: RGB24
> dshow debug: Block buffer: 0xd8 0x9b 0x2b 0xd8 0x9b 0x2b 0xd8 0x9b
> 0x2b 0xd8 0x9b 0x2b
> 
> When capturing in RGB32:
> dshow debug: DShow format: RGB32
> dshow debug: Block buffer: 0xd8 0x9b 0x2b 0xff 0xd8 0x9b 0x2b 0xff
> 0xd8 0x9b 0x2b 0xff
> 
> The color masks used in both cases are the same:
> 
> fmt.video.i_rmask = 0x00ff0000;
> fmt.video.i_gmask = 0x0000ff00;
> fmt.video.i_bmask = 0x000000ff;
> 
> However, in the case of RGB24 VLC renders colors incorrectly. With
> RGB32 everything is fine.
> 
> So again this does not seem to be a DShow bug. Maybe the RGB24 color
> masks are interpreted incorrectly in chroma.c?

The masks are supposed to be in local endianess. But some modules either 
ignore the masks, parse them incorrectly, or only support some combination. It 
gets even more confusing for 24-bits.

I would much prefer we use different FOURCC depending on the byte order. Plus 
the masks cannot deal with high ranges.

-- 
雷米‧德尼-库尔蒙
https://www.remlab.net/