Hi Dmitry,
I enabled the debug output and ran some tests again.
This is with the source (Windows / Nvidia GPU) set to 1920 x 1080 / 59
Hz and 4:4:4 chroma. I use the default EDID.
# gst-launch-1.0 -v v4l2src device=/dev/video2 ! fakesink
# dmesg
hdmirx_hdmi_irq_handler: en_fiq
[ 226.901822] fdee0000.hdmi_receiver: wait_reg_bit_status: i:0, time: 10ms
[ 226.938715] fdee0000.hdmi_receiver: wait_reg_bit_status: i:36, time:
50ms
[ 226.938730] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
scdc_regbank_st:0x0
[ 226.938738] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
HDMITX less than 3.4Gbps
[ 226.946675] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 226.946689] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
scdc_regbank_st:0x0
[ 226.946698] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
HDMITX less than 3.4Gbps
[ 226.954724] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 226.954738] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
scdc_regbank_st:0x0
[ 226.954746] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
HDMITX less than 3.4Gbps
[ 226.962824] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 226.962838] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
scdc_regbank_st:0x0
[ 226.962846] fdee0000.hdmi_receiver: hdmirx_tmds_clk_ratio_config:
HDMITX less than 3.4Gbps
[ 226.962856] fdee0000.hdmi_receiver: hdmirx_wait_signal_lock: signal
lock ok, i:3
[ 227.036484] fdee0000.hdmi_receiver: pkt_2_int_handler: pk2_st:0x800
[ 227.036504] fdee0000.hdmi_receiver: pkt_2_int_handler: AVIIF_RCV_IRQ
[ 227.036512] fdee0000.hdmi_receiver: hdmirx_hdmi_irq_handler: en_fiq
[ 227.092219] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV444
[ 227.092233] fdee0000.hdmi_receiver: hdmirx_get_colordepth:
color_depth: 24, reg_val:4
[ 227.092251] fdee0000.hdmi_receiver: hdmirx_format_change: queue
res_chg_event
[ 227.092261] fdee0000.hdmi_receiver: hdmirx_set_ddr_store_fmt:
pix_fmt: YUV444, DMA_CONFIG1:0x12006001
[ 227.092272] fdee0000.hdmi_receiver: hdmirx_interrupts_setup: enable
[ 231.039033] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 231.039061] fdee0000.hdmi_receiver: get timings from dma
[ 231.039068] fdee0000.hdmi_receiver: act:1920x1080p, total:2200x1125,
fps:86, pixclk:214076000
[ 231.039080] fdee0000.hdmi_receiver: hfp:84, hact:1920, hs:48,
hbp:148, vfp:4, vact:1080, vs:5, vbp:36
[ 231.039092] fdee0000.hdmi_receiver: tmds_clk:214076000, pix_clk:214076000
[ 231.039100] fdee0000.hdmi_receiver: interlace:0, fmt:2, color:24,
mode:hdmi
[ 231.039108] fdee0000.hdmi_receiver: deframer_st:0x11
It seems that YUV444 is recognized - but not always - sometimes it does
not register changes in the source and it tries to establish a pipeline
still with RGB.
This is with the source set to RGB.
# gst-launch-1.0 -v v4l2src device=/dev/video2 ! fakesink
[ 869.317467] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 869.317491] fdee0000.hdmi_receiver: get timings from dma
[ 869.317497] fdee0000.hdmi_receiver: act:1920x1080p, total:2200x1125,
fps:86, pixclk:214072000
[ 869.317506] fdee0000.hdmi_receiver: hfp:84, hact:1920, hs:48,
hbp:148, vfp:4, vact:1080, vs:5, vbp:36
[ 869.317515] fdee0000.hdmi_receiver: tmds_clk:214072000, pix_clk:214072000
[ 869.317521] fdee0000.hdmi_receiver: interlace:0, fmt:0, color:24,
mode:hdmi
[ 869.317528] fdee0000.hdmi_receiver: deframer_st:0x11
[ 869.317534] fdee0000.hdmi_receiver: query_dv_timings: 1920x1080p86.49
(2200x1125)
[ 869.317556] fdee0000.hdmi_receiver: s_dv_timings: 1920x1080p86.49
(2200x1125)
[ 869.317574] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.317581] fdee0000.hdmi_receiver: hdmirx_set_fmt: req(1920, 1080),
out(1920, 1080), fmt:0x33524742
[ 869.317637] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.317650] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.317881] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.318092] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.318287] fdee0000.hdmi_receiver: C-Plane 0 size: 6220800, Total
imagesize: 6220800
[ 869.318298] fdee0000.hdmi_receiver: hdmirx_set_fmt: req(1920, 1080),
out(1920, 1080), fmt:0x33524742
[ 869.318836] fdee0000.hdmi_receiver: vid-cap-mplane: count 4, size 6220800
[ 869.321814] fdee0000.hdmi_receiver: hdmirx_start_streaming:
start_stream cur_buf y_addr:0xe10c0000, uv_addr:0xe10c0000
[ 869.321831] fdee0000.hdmi_receiver: hdmirx_start_streaming: enable dma
[ 869.331693] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:546
[ 869.331708] fdee0000.hdmi_receiver: line_flag_int_handler: last have
no dma_idle_irq
[ 869.339684] fdee0000.hdmi_receiver: dma_irq st1:0x80, st13:0
[ 869.348380] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:547
Observe the reported fps of 86 in the above log file. Also gstreamer
reports a framerate of 214072/2475 - also around 86.
I could sometimes also create the "Device wants 1 planes" using RGB -
replugging fixed it, but could never fix it in YUV444.
Next week I have time for more testing.
Best regards,
Tim
On 1/14/25 12:37, Dmitry Osipenko wrote:
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.
