[FFmpeg-trac] #10418(avdevice:new): DirectShow, wrong pixel format

[FFmpeg]

#10418: DirectShow, wrong pixel format
--------------------------------------+------------------------------------
             Reporter:  Michael Koch  |                    Owner:  (none)
                 Type:  defect        |                   Status:  new
             Priority:  normal        |                Component:  avdevice
              Version:  git-master    |               Resolution:
             Keywords:                |               Blocked By:
             Blocking:                |  Reproduced by developer:  0
Analyzed by developer:  0             |
--------------------------------------+------------------------------------
Description changed by Michael Koch:

Old description:

> There is a problem with a ASI178MM (monochrome) camera and its
> DirectShow driver. When I check the options with this command
>
> ffmpeg -list_options 1 -f dshow -i video="ASI178MM Camera (ZWO Design)"
>
> I get this output:
>
> [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=3096x2080
> fps=1.0842e-12 max s=3096x2080 fps=30
> [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=1280x960
> fps=1.0842e-12 max s=1280x960 fps=30
> [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=1280x800
> fps=1.0842e-12 max s=1280x800 fps=30
> ...  (there are more sizes listed, all with the same pixel format rgb8)
>
> When FFmpeg gets a frame from the camera, the detected pixel format is
> rgb8 (as defined in FFmpeg: 2 bits red, 3 bits green, 3 bits blue). Of
> course that's wrong, because it's a monochrome camera and the data is
> 8-bit gray.
>
> My first idea was that it must be a bug in the DirectShow driver. The
> data is obviously correct 8-bit gray (I did verify that), but it's
> incorrectly labeled as "rgb8" instead of "gray".
>
> When you look at the specifications of DirectShow
>
> https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-
> rgb-video-subtypes
>
> you see that there exists no "gray" pixel format, and "RGB8" is a
> different pixel format described as "RGB, 8 bpp, palettized". It seems an
> uncompressed 8-bit gray frame must be encoded with "RGB8" pixel format,
> together with a palette which contains 256 levels of gray.
>
> "RGB8" in DirectShow should become "pal8" or "gray" in FFmpeg, and not
> "rgb8".
>
> By the way, in line 64 of dshow.c there is a comment that this pixel
> format is untested. So this might be the first test.

New description:

 There is a problem with a ASI178MM (monochrome) camera and its DirectShow
 driver. When I check the options with this command

 ffmpeg -list_options 1 -f dshow -i video="ASI178MM Camera (ZWO Design)"

 I get this output:

 [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=3096x2080
 fps=1.0842e-12 max s=3096x2080 fps=30
 [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=1280x960
 fps=1.0842e-12 max s=1280x960 fps=30
 [dshow @ 00000203f5b315c0]   pixel_format=rgb8  min s=1280x800
 fps=1.0842e-12 max s=1280x800 fps=30
 ...  (there are more sizes listed, all with the same pixel format rgb8)

 When FFmpeg gets a frame from the camera, the detected pixel format is
 rgb8 (as defined in FFmpeg: 2 bits red, 3 bits green, 3 bits blue). Of
 course that's wrong, because it's a monochrome camera and the data is
 8-bit gray.

 My first idea was that it must be a bug in the DirectShow driver. The data
 is obviously correct 8-bit gray (I did verify that), but it's incorrectly
 labeled as "rgb8" instead of "gray".

 When you look at the specifications of DirectShow

 https://learn.microsoft.com/en-us/windows/win32/directshow/uncompressed-
 rgb-video-subtypes

 you see that there exists no "gray" pixel format, and "RGB8" is a
 different pixel format described as "RGB, 8 bpp, palettized". It seems an
 uncompressed 8-bit gray frame must be encoded with "RGB8" pixel format,
 together with a palette which contains 256 levels of gray.

 "RGB8" in DirectShow should become "pal8" or "gray" in FFmpeg, and not
 "rgb8".

 By the way, in line 64 of dshow.c there is a comment that this pixel
 format is untested. So this might be the first test.

--
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10418#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker