Yes. You want to edit the EDID to designate a different native resolution. At a very simplistic level, if taking the EDID I had listed
Code: Select all
00ffffffffffff005262888800888888 1c150103800000780aEE91A3544C9926 0F505400000001010101010101010101 010101010101011d007251d01e206e28 5500c48e2100001e8c0ad08a20e02d10 103e9600138e2100001e000000fc0054 6f73686962612d4832430a20000000FD 003b3d0f2e0f1e0a2020202020200100 020321434e 841303021211012021223c 3d3e1f 2309070766030c00300080E300 7F8c0ad08a20e02d10103e9600c48e21 0000188c0ad08a20e02d10103e960013 8e210000188c0aa01451f01600267c43 00138e21000098000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000
The top bit is used to denote the native mode, hence 04 ([email protected]) is defined as native.
Change the "84" to "04", and change the "22" almost at the end of that line to "a2", and you should get a default of 1080P30. (Don't insert the spaces I've done above for clarity).
Use "edid-decode < file.txt" to check the content of the EDID file first before downloading it to confirm your change is valid (ignore checksum errors).
v4l2src doesn't subscribe to the resolution change events or set any of the timings, therefore you will have to do those manually. After that then yes v4l2src should be able to capture the raw data fine. You'll then need to convert it to I420, and encode it. yavta is doing all of that for you.ialpert wrote:1. Is there a way to capture with same results but without yavta? Meaning right from GStreamer, maybe v4l2src? I seem to be able to run pipeline but can't decode it on the client. There is no need for OMX encoding, yavta already encoded video data with hardware acceleration, right?
What gets worse? What format are you encoding? BGR3 will be more resource intensive than UYVY.ialpert wrote:I don't know if it is related but performance downgrades over time, it works perfectly for a few minutes and then getting worse. Still, CPUs are around ~15% and it seems to be enough memory for everything. GPU memory is set to 128
I have been profiling the encode pipeline and the input of the encoder is maxing out one of the VPU cores when I'm trying to push 1080P60 through it (CM3 with B102). There is an approach I can take which will remove most of that load and push it back into the ISP component, but it's a modest chunk of work that I don't know when I'll get around to doing. 1080P30 should be OK.
Not totally trivial, but plausible.ialpert wrote:2. Is it hard to implement dynamic resolution change in yavta? when I switch from UI to video or back I got the full blue (sometimes black) screen and have to restart everything
I've just pushed updates to yavta that detect the SOURCE_CHANGE event as I had it as boilerplate from another project. It still needs to tear everything down, reconfigure it, reallocate the buffers, and then start it all up again. All the code is there, but probably needs restructuring to make it available. You've got all the code so it's there if you want to experiment