Le mardi 14 janvier 2025 à 14:37 +0300, Dmitry Osipenko a écrit : > 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. GStreamer uses G_PARM to get and report the frame interval (and flip the fraction over to make it a frame rate). I've assumed these two should match and it wasn't worth a special case of HDMI receivers. Nicolas > > 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. >
