On 1/9/25 02:17, Tim Surber wrote:
> Hi,
>
> I tested your patch with the command
>
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
>
> If this worked I moved on to a visual test using
>
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! queue ! v4l2convert !
> waylandsink
>
> I used a Windows PC with a Nvidia GTX 4060 as my source for the
> following tests.
>
> | Format | Result |
> | ------------ | ------------------------------------------- |
> | 4k60p RGB | Recognized as 1080p / 120 fps - no output |
> | 4k60p 4:2:2 | Recognized as 1080p / 120 fps - no output |
> | 4k60p 4:4:4 | Error: Device wants 1 planes |
> | 4k30p RGB | ok |
> | 4k30p 4:2:2 | ok |
> | 4k30p 4:4:4 | Error: Device wants 1 planes |
> | FHD60p RGB | ok |
> | FHD60p 4:2:2 | ok |
> | FHD60p 4:4:4 | Error: Device wants 1 planes |
>
>
> When testing 4:4:4 chroma I got the following error:
>
> # gst-launch-1.0 -v v4l2src device=/dev/video1 ! fakesink
> /sys/v4l2/gstv4l2object.c(4344): gst_v4l2_object_set_format_full (): /
> GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Device wants 1 planes
>
> I could record and convert (with errors) the files with 4:4:4 chroma
> using the command Shreeya posted, but the resulting video had wrong
> colors and was flashing.
>
> I was not able to test 4:2:0 chroma. I tried to generate an custom EDID
> with support for it but I could not select it in the graphics driver in
> the source, maybe this is just an issue with my setup.
Thanks a lot for the testing, very appreciate it! Good that RGB works
for you with no problems.
Testing YUV formats isn't trivial. Personally I've a custom setup with a
modified display driver of RPi to test them. See more below.
> I also observed that the the framerate is reported wrong, for example
> setting the source to FHD60p RGB resulted in the following:
>
> # v4l2-ctl --all -L --list-formats-ext -d /dev/video0
> Active width: 1920
> Active height: 1080
> Total width: 2200
> Total height: 1125
> Frame format: progressive
> Polarities: -vsync -hsync
> Pixelclock: 214076000 Hz (86.50 frames per second)
>
> This wrong framerate reporting seemed to happen across all framerates
> and resolutions. Gstreamer Pipeline negotation showed the same results.
I've re-tested YUV444 4k capture using RPi4, works flawlessly. Note for
gst-launch-1.0 you used video1 and video0 device is used by v4l2-ctl
command above, maybe you're using wrong device. Please post a complete
output of the v4l2-ctl command.
The command I used to test YUV444 capture:
# v4l2-ctl --verbose -d /dev/video1
--set-fmt-video=width=3840,height=2160,pixelformat=NV24 --stream-mmap=4
--stream-skip=3 --stream-count=3300 --stream-to=hdmi.raw --stream-poll
The I converted captured data to a video file and played it:
# ffmpeg -f rawvideo -vcodec rawvideo -s 3840x2160 -r 30 -pix_fmt nv24
-y -i hdmi.raw output.mkv && mpv output.mkv -loop 0
Don't see any problems with a reported framerate:
DV timings:
Active width: 3840
Active height: 2160
Total width: 4400
Total height: 2250
Frame format: progressive
Polarities: -vsync -hsync
Pixelclock: 296992000 Hz (30.00 frames per second)
Note the timing data reported by v4l2-ctl updates after launching the
capture. It's not updated dynamically when you changing mode on the source.
Lastly, please run `echo 3 >
/sys/module/synopsys_hdmirx/parameters/debug`. Watch the kmsg log.
Check that it says "hdmirx_get_pix_fmt: pix_fmt: YUV444" when you
connecting HDMI cable to a YUV444 source and see other related messages.
If it says RGB, then your source is transmitting RGB.
> During my testing I got sometimes an error
>
>
> # dmesg
> dma alloc of size 24883200 failed
>
>
> I'm not sure when this happened and how to reproduce it.
This comes from v4l core, should be harmless as long as capture works.
It's a known noisy msg, you may ignore it for today.
> Then I tried to use an AppleTV 4k as source. I don't know what
> resolution it tried to negotiate but I got this error in addition to the
> previous "Device wants 1 planes" and no connection:
>
> # dmesg
> fdee0000.hdmi_receiver: hdmirx_query_dv_timings: signal is not locked
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
> tmds_clk_ratio:0
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
> dma_st10:0x10
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal not lock,
> tmds_clk_ratio:0
> fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: mu_st:0x0, scdc_st:0x0,
> dma_st10:0x14
"Device wants 1 planes" sounds like you're using a wrong v4l video
device. Please double check. Though, the "signal not lock" means it
doesn't work anyways, please make sure you're using the default driver
EDID and not a custom one.
--
Best regards,
Dmitry
