6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Mon Aug 19, 2019 9:17 am

Tanner1pl wrote:
Sun Aug 18, 2019 7:28 pm
Hello, I have an issue which might be a bug - tested on both Auvidea B101/3b+ and B102/Zero with two blackmagic camers - Pocket 4K and Micro Cinema Camera. I assume hardware works good, as other video sources are captured properly.

My issue - video captured has broken colors - like way too much green and pink.
Colors are fine when I use different camera or any other video source - so B101 and B102 are fine. Also, when I connect these blackmagic cameras to TV - they works good. Also many hdmi cables tested.

Looks more like TC358743 doesn't recognize format/config of video coming from blackmagic - it sends clear 10bit 1080p@25fps 4.2.2 video which can be recorded using external recorder. Looks very similar (if not exactly) like issue with YCrCb vs RGBFull pixel formatting. Has anyone faced this issue and found solution? :)

Code: Select all

raspivid -t 5000 -w 1920 -h 1080 -fps 25 -o test.h264
Zrzut-ekranu-2019-08-18-o-21.12.59.jpg


While image coming out from camera is fine, like here on preview LCD or when I connect monitor/TV to camera.
68800270_360682631267652_8322857960573239296_n.jpg
As per the message that comes up whenever you run raspivid with a B101 connected.
The driver for the TC358743 HDMI to CSI2 chip you are using is NOT supported.
They were written for a demo purposes only, and are in the firmware on an as-is
basis and therefore requests for support or changes will not be acted on.
The Linux kernel drivers for this board are the only supported configuration.

AFAIK 10bit YUV is not supported by the chip on the board, therefore there is unlikely to be a solution. The cameras should read the EDID provided by the board (or user) and select an output format that is supported by the HDMI sink. If it is selecting a 10bit format then either the EDID is wrong, or it's not parsing it correctly.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Mon Aug 19, 2019 9:19 am

manmathan74 wrote:
Mon Aug 19, 2019 6:56 am
Hi All,
Can someone help? I am trying to get the B101 v4 board to work on Pi 3b+ but am lost with so many point on this forum. Is there a step by step on this board?

Thanks,
https://www.raspberrypi.org/forums/view ... 8#p1339178
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Tanner1pl
Posts: 3
Joined: Sun Aug 18, 2019 7:08 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Mon Aug 19, 2019 10:08 am

6by9 wrote:
Mon Aug 19, 2019 9:17 am
Tanner1pl wrote:
Sun Aug 18, 2019 7:28 pm
Hello, I have an issue which might be a bug - tested on both Auvidea B101/3b+ and B102/Zero with two blackmagic camers - Pocket 4K and Micro Cinema Camera. I assume hardware works good, as other video sources are captured properly.

My issue - video captured has broken colors - like way too much green and pink.
Colors are fine when I use different camera or any other video source - so B101 and B102 are fine. Also, when I connect these blackmagic cameras to TV - they works good. Also many hdmi cables tested.

Looks more like TC358743 doesn't recognize format/config of video coming from blackmagic - it sends clear 10bit 1080p@25fps 4.2.2 video which can be recorded using external recorder. Looks very similar (if not exactly) like issue with YCrCb vs RGBFull pixel formatting. Has anyone faced this issue and found solution? :)

Code: Select all

raspivid -t 5000 -w 1920 -h 1080 -fps 25 -o test.h264
Zrzut-ekranu-2019-08-18-o-21.12.59.jpg


While image coming out from camera is fine, like here on preview LCD or when I connect monitor/TV to camera.
68800270_360682631267652_8322857960573239296_n.jpg
As per the message that comes up whenever you run raspivid with a B101 connected.
The driver for the TC358743 HDMI to CSI2 chip you are using is NOT supported.
They were written for a demo purposes only, and are in the firmware on an as-is
basis and therefore requests for support or changes will not be acted on.
The Linux kernel drivers for this board are the only supported configuration.

AFAIK 10bit YUV is not supported by the chip on the board, therefore there is unlikely to be a solution. The cameras should read the EDID provided by the board (or user) and select an output format that is supported by the HDMI sink. If it is selecting a 10bit format then either the EDID is wrong, or it's not parsing it correctly.


Thank you for your answer. Actually I didn't provide any custom EDID in configuration, so board is sending something default to camera. But here is tricky part, I am pretty sure these blackmagic's hdmi output is fixed, as it can be used for external recorder, they don't provide anything else than 10bit 1080p @ fps same as shooting. And yeah, these cameras don't work with few cheap/old screens, that would make sense.

What I am thinking now, maybe some middle-device would help, like hdmi downscaller or something that could read video from blackmagic and output it in less strict format.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Mon Aug 19, 2019 10:49 am

Tanner1pl wrote:
Mon Aug 19, 2019 10:08 am
Thank you for your answer. Actually I didn't provide any custom EDID in configuration, so board is sending something default to camera. But here is tricky part, I am pretty sure these blackmagic's hdmi output is fixed, as it can be used for external recorder, they don't provide anything else than 10bit 1080p @ fps same as shooting. And yeah, these cameras don't work with few cheap/old screens, that would make sense.

What I am thinking now, maybe some middle-device would help, like hdmi downscaller or something that could read video from blackmagic and output it in less strict format.
Something will always be providing an EDID. In your case it will be the firmware (using the unsupported driver).
Ignoring the EDID is a tad annoying, but nothing much that can be done about it.

I suspect one of the Kramer switchers will do the appropriate down conversion for you. They don't come cheap though (unless you're buying older ones off Ebay as I have been).
There is an updated version of the TC358743 chip that does support up to 4k30 - the TC358840. I haven't seen any discussion of drivers for it, nor boards that use it, and it potentially has some very odd formatting of the data across two CSI2 interfaces. The product brief doesn't list 10bit support either, so it may not be supported even there.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Tanner1pl
Posts: 3
Joined: Sun Aug 18, 2019 7:08 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Thu Aug 22, 2019 12:24 pm

6by9 wrote:
Mon Aug 19, 2019 10:49 am
Something will always be providing an EDID. In your case it will be the firmware (using the unsupported driver).
Ignoring the EDID is a tad annoying, but nothing much that can be done about it.

I suspect one of the Kramer switchers will do the appropriate down conversion for you. They don't come cheap though (unless you're buying older ones off Ebay as I have been).
There is an updated version of the TC358743 chip that does support up to 4k30 - the TC358840. I haven't seen any discussion of drivers for it, nor boards that use it, and it potentially has some very odd formatting of the data across two CSI2 interfaces. The product brief doesn't list 10bit support either, so it may not be supported even there.

Thank you, very appreciated. I've got response from Auvidea, they confirmed as below. So now, last thing that could work (before converter) would be use prepared EEID and only if blackmagic camera could switch to 8bit output, then I would be fine.
we are not exactly sure what the problem could be since we’ve never performed any tests with Blackmagic cameras, but our best guess would be that 10bit color depth is not supported on our chip, so if you could change the output somehow to 8bit, maybe that would fix it then.

edudelosan
Posts: 1
Joined: Tue Oct 22, 2019 5:57 am

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Tue Oct 22, 2019 6:04 am

Hello good mornig for everyone. I need some help.
I have an HDMI to CSI board with the TC358743 chip.
I read the forum but there are some things I did not understand. Someone can guide me in the steps to follow.
I just want to visualize video from a camera. No audio required I don't know if I have to connect something to the GIPO.
Thank you.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Tue Oct 22, 2019 8:59 am

edudelosan wrote:
Tue Oct 22, 2019 6:04 am
Hello good mornig for everyone. I need some help.
I have an HDMI to CSI board with the TC358743 chip.
I read the forum but there are some things I did not understand. Someone can guide me in the steps to follow.
I just want to visualize video from a camera. No audio required I don't know if I have to connect something to the GIPO.
Thank you.
Please read https://www.raspberrypi.org/forums/view ... 8#p1339178
The one update is that you can use

Code: Select all

v4l2-ctl --set-dv-bt-timings query
to read the current timings and set them.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Tue Oct 22, 2019 11:20 am

This was submitted by mistake, see the next post please :)
Last edited by cr1cr1 on Tue Oct 22, 2019 11:49 am, edited 1 time in total.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Unable to request buffers: Cannot allocate memory (12)

Tue Oct 22, 2019 11:48 am

Hello,

TL;DR: Getting "Unable to request buffers: Cannot allocate memory (12)." when running yavta or fswebcam

========================================================================

Ran:

Code: Select all

root@pi3:~# v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums

CEA-861 Header
  IT Formats Underscanned: yes
  Audio:                   yes
  YCbCr 4:4:4:             no
  YCbCr 4:2:2:             no

HDMI Vendor-Specific Data Block
  Physical Address:        3.0.0.0
  YCbCr 4:4:4 Deep Color:  no
  30-bit:                  no
  36-bit:                  no
  48-bit:                  no

CEA-861 Video Capability Descriptor
  RGB Quantization Range:  yes
  YCC Quantization Range:  no
  PT:                      Supports both over- and underscan
  IT:                      Supports both over- and underscan
  CE:                      Supports both over- and underscan

Code: Select all

root@pi3:~# v4l2-ctl --set-dv-bt-timings query --verbose
VIDIOC_QUERYCAP: ok
VIDIOC_QUERY_DV_TIMINGS: ok
        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148500000 Hz (60.00 frames per second)
        Horizontal frontporch: 0
        Horizontal sync: 280
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 45
        Vertical backporch: 0
        Standards:
        Flags:
VIDIOC_S_DV_TIMINGS: ok
BT timings set

Code: Select all

root@pi3:~# ./yavta/yavta --capture=60 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0
We're encoding to file.h264
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi' (driver 'unicam') is a video capture (without mplanes) device.
stride is 0
stride is now 1280
Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
Framerate is 60
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x15b9fb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1920, height: 1088, (0,0,1920,1080) pixel aspect ratio: 0/0, frame rate: 0/0
buffers num: 3(opt 1, min 1), size: 4177920(opt 4177920, min: 4177920), align: 0
Created pool of length 3, size 0
Enable encoder....
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 3 buffers of size 3133440 for encode/render
Writing data to file.h264
Create pool of 8 buffers of size 262144
Sent buffer 0x15c3d58
Sent buffer 0x15c3f30
Sent buffer 0x15c4108
Sent buffer 0x15c42e0
Sent buffer 0x15c44b8
Sent buffer 0x15c4690
Sent buffer 0x15c4868
Sent buffer 0x15c4a40
Unable to request buffers: Cannot allocate memory (12).
========================================================================

System information:

Code: Select all

root@pi3:~# lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 9.11 (stretch)
Release:        9.11
Codename:       stretch

Code: Select all

root@pi3:~# grep '^[^#]' /boot/config.txt
dtparam=spi=on
dtparam=audio=on
start_x=1
gpu_mem=128
dtoverlay=tc358743
cma=96M

Code: Select all

root@pi3:~# vcgencmd version
Oct 21 2019 16:52:13
Copyright (c) 2012 Broadcom
version 509fb1bcb9511d963439429724a6f6dfb8251107 (tainted) (release) (start_x)

Code: Select all

root@pi3:~# uname -a
Linux pi3 4.19.80-v7+ #1274 SMP Mon Oct 21 16:23:10 BST 2019 armv7l GNU/Linux

Code: Select all

root@pi3:~# v4l2-ctl --log-status

Status Log:

   [ 1894.774862] unicam 3f801000.csi: =================  START STATUS  =================
   [ 1894.776553] tc358743 0-000f: -----Chip status-----
   [ 1894.777196] tc358743 0-000f: Chip ID: 0x00
   [ 1894.777813] tc358743 0-000f: Chip revision: 0x00
   [ 1894.777823] tc358743 0-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
   [ 1894.777829] tc358743 0-000f: Sleep mode: off
   [ 1894.777835] tc358743 0-000f: Cable detected (+5V power): yes
   [ 1894.778365] tc358743 0-000f: DDC lines enabled: yes
   [ 1894.778890] tc358743 0-000f: Hotplug enabled: yes
   [ 1894.779510] tc358743 0-000f: CEC enabled: no
   [ 1894.779515] tc358743 0-000f: -----Signal status-----
   [ 1894.779521] tc358743 0-000f: TMDS signal detected: yes
   [ 1894.779528] tc358743 0-000f: Stable sync signal: yes
   [ 1894.779533] tc358743 0-000f: PHY PLL locked: yes
   [ 1894.779539] tc358743 0-000f: PHY DE detected: yes
   [ 1894.786625] tc358743 0-000f: Detected format: 1920x1080p60.0 (2200x1125)
   [ 1894.786638] tc358743 0-000f: horizontal: fp = 0, -sync = 280, bp = 0
   [ 1894.786646] tc358743 0-000f: vertical: fp = 0, -sync = 45, bp = 0
   [ 1894.786653] tc358743 0-000f: pixelclock: 148500000
   [ 1894.786662] tc358743 0-000f: flags (0x0):
   [ 1894.786669] tc358743 0-000f: standards (0x0):
   [ 1894.786680] tc358743 0-000f: Configured format: 1920x1080p60.0 (2200x1125)
   [ 1894.786687] tc358743 0-000f: horizontal: fp = 0, -sync = 280, bp = 0
   [ 1894.786695] tc358743 0-000f: vertical: fp = 0, -sync = 45, bp = 0
   [ 1894.786701] tc358743 0-000f: pixelclock: 148500000
   [ 1894.786708] tc358743 0-000f: flags (0x0):
   [ 1894.786715] tc358743 0-000f: standards (0x0):
   [ 1894.786721] tc358743 0-000f: -----CSI-TX status-----
   [ 1894.786727] tc358743 0-000f: Lanes needed: 4
   [ 1894.786733] tc358743 0-000f: Lanes in use: 4
   [ 1894.787356] tc358743 0-000f: Waiting for particular sync signal: no
   [ 1894.787971] tc358743 0-000f: Transmit mode: no
   [ 1894.788596] tc358743 0-000f: Receive mode: no
   [ 1894.789210] tc358743 0-000f: Stopped: no
   [ 1894.789216] tc358743 0-000f: Color space: RGB 888 24-bit
   [ 1894.790258] tc358743 0-000f: -----HDMI status-----
   [ 1894.790270] tc358743 0-000f: HDCP encrypted content: no
   [ 1894.790278] tc358743 0-000f: Input color space: RGB limited range
   [ 1894.791562] tc358743 0-000f: AV Mute: off
   [ 1894.792764] tc358743 0-000f: Deep color mode: 8-bits per channel
   [ 1894.795271] tc358743 0-000f: HDMI infoframe: Auxiliary Video Information (AVI), version 2, length 13
   [ 1894.795281] tc358743 0-000f:     colorspace: RGB
   [ 1894.795290] tc358743 0-000f:     scan mode: No Data
   [ 1894.795298] tc358743 0-000f:     colorimetry: ITU709
   [ 1894.795320] tc358743 0-000f:     picture aspect: 16:9
   [ 1894.795330] tc358743 0-000f:     active aspect: Same as Picture
   [ 1894.795339] tc358743 0-000f:     itc: No Data
   [ 1894.795349] tc358743 0-000f:     extended colorimetry: xvYCC 601
   [ 1894.795358] tc358743 0-000f:     quantization range: Default
   [ 1894.795367] tc358743 0-000f:     nups: Unknown Non-uniform Scaling
   [ 1894.795375] tc358743 0-000f:     video code: 16
   [ 1894.795384] tc358743 0-000f:     ycc quantization range: Limited
   [ 1894.795393] tc358743 0-000f:     hdmi content type: Graphics
   [ 1894.795402] tc358743 0-000f:     pixel repeat: 0
   [ 1894.795412] tc358743 0-000f:     bar top 0, bottom 0, left 0, right 0
   [ 1894.795419] unicam 3f801000.csi: -----Receiver status-----
   [ 1894.795428] unicam 3f801000.csi: V4L2 width/height:   1920x1080
   [ 1894.795435] unicam 3f801000.csi: Mediabus format:     0000100a
   [ 1894.795446] unicam 3f801000.csi: V4L2 format:         RGB3
   [ 1894.795454] unicam 3f801000.csi: Unpacking/packing:   0 / 0
   [ 1894.795459] unicam 3f801000.csi: ----Live data----
   [ 1894.795466] unicam 3f801000.csi: Programmed stride:      0
   [ 1894.795472] unicam 3f801000.csi: Detected resolution: 0x0
   [ 1894.795478] unicam 3f801000.csi: Write pointer:       00000000
   [ 1894.795485] unicam 3f801000.csi: ==================  END STATUS  ==================
========================================================================

Hardware:

- Raspberry PI:

Code: Select all

Hardware        : BCM2835
Revision        : a020d3
Serial          : 00000000a4f720f8
Model           : Raspberry Pi 3 Model B Plus Rev 1.3
- Capture board: Lusya Upgraded version Raspberry Pi HDMI Adapter Board HDMI interface to CSI-2 TC358743XBG for 3B 3B+ ZERO G11-011 (https://www.aliexpress.com/item/4000152180240.html)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Unable to request buffers: Cannot allocate memory (12)

Tue Oct 22, 2019 12:11 pm

cr1cr1 wrote:
Tue Oct 22, 2019 11:48 am

Code: Select all

root@pi3:~# grep '^[^#]' /boot/config.txt
dtparam=spi=on
dtparam=audio=on
start_x=1
gpu_mem=128
dtoverlay=tc358743
cma=96M
cma=96M goes in /boot/cmdline.txt (with no added carriage returns), not in config.txt.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Re: Unable to request buffers: Cannot allocate memory (12)

Tue Oct 22, 2019 9:51 pm

That's right, sorry to have missed the trivial thing - after reading for a long time the many posts here it became a bit harder to keep up with all the details.

Running ./yavta/yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0 now works.

I have tried directly connecting a source (like a laptop) and works with the "native" resolution of 1280x720 - which is great for my purpose of running Hyperion to control some LEDs based on the video input.

Reading previous posts in this thread related to Hyperion, I have managed to take snapshots and start the service (after removing PAL/NTSC format spec):

Code: Select all

hyperion-v4l2 --device /dev/video0 --input 0 --width -1 --height -1 --size-decimator 1 --frame-decimator 2 --red-threshold 0.0 --green-threshold 0.0 --blue-threshold 0.0 --screenshot
It is amazing the difference of the clean picture coming from the HDMI capture board compared to the old solution of having a converter to analog video and capture it back to Raspberry Pi. Clean picture translates into LEDs turned off completely and no flickering, great black borders detection and more.


However, records only black frames or the image is broken when I use a splitter. Seems to be interlaced, but I am not sure.
This device is downscaling 4k@60Hz to a stubborn 1080p@60Hz. Is needed for obvious reason: have the HDMI video stream to the TV and also to the capture board and Raspberry to be used by Hyperion that controls the LEDs on the back of the TV.

Image

If I will manage to fix the above problem, eventually, will use udev rules to:

Code: Select all

- v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums
- v4l2-ctl --set-dv-bt-timings query
- v4l2-ctl -v pixelformat=UYVY
to automate changes in the device, I imagine will be triggered when HDMI is connected, etc.

All this is quite new to me, so there is more to dig up.

Thanks 6by9 for the great work and explanations, and the patience you have showed in all these posts.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Wed Oct 23, 2019 8:52 am

Most cheap splitters I've encountered will amend the edid to advertise the subset of modes supported by both displays. None of them support scaling.

1080p60 exceeds the bandwidth available over 2 csi2 lanes, so won't work on a standard Pi, only the compute module. The driver should complain on that and not allow streaming to start. Confirm what mode the bridge is actually detecting via "v4l2-ctl - - query-detected-timings" (from memory - may have a typo).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Thu Oct 24, 2019 8:58 am

There is a :

Code: Select all

root@pi3:~# v4l2-ctl --query-dv-timings
VIDIOC_QUERY_DV_TIMINGS: failed: Link has been severed
        Active width: 0
        Active height: 0
        Total width: 0
        Total height: 0
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 0 Hz
        Horizontal frontporch: 0
        Horizontal sync: 0
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 0
        Vertical backporch: 0
        Standards:
        Flags:
After loading one of your edid files:

Code: Select all

v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums
runing again:

Code: Select all

root@pi3:~# v4l2-ctl --query-dv-timings
        Active width: 1366
        Active height: 768
        Total width: 1792
        Total height: 798
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 85800960 Hz (60.00 frames per second)
        Horizontal frontporch: 0
        Horizontal sync: 426
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 30
        Vertical backporch: 0
        Standards:
        Flags:
This captures correctly the input.

If I switch to another video source, say a 4k, the splitter will downscale the output for Pi, and if I run again:

Code: Select all

root@pi3:/tmp# v4l2-ctl --query-dv-timings
        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148500000 Hz (60.00 frames per second)
        Horizontal frontporch: 0
        Horizontal sync: 280
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 45
        Vertical backporch: 0
        Standards:
        Flags:
This is expected, but as you have stated, capturing 1080@60Hz will not work, all programs failing with VIDIOC_STREAMON ERROR 22, Invalid argument

If I force the timings to let's say 1366@60hz again:

Code: Select all

root@pi3:/tmp# v4l2-ctl --list-dv-timings -k | grep 136
        47:     1360x768p60.02
        48:     1360x768p119.97 reduced blanking
        49:     1366x768p59.79
        50:     1366x768p60.00 reduced blanking

root@pi3:/tmp# v4l2-ctl --set-dv-bt-timings index=50
BT timings set
will record a green or black screen.

When setting 1920x1080p50.00:

Code: Select all

root@pi3:/tmp# v4l2-ctl --list-dv-timings -k | grep 1080
        8:      1920x1080p24.00 framerate can be reduced by 1/1.001, CE-video
        9:      1920x1080p25.00 CE-video
        10:     1920x1080p30.00 framerate can be reduced by 1/1.001, CE-video
        11:     1920x1080p50.00 CE-video
        12:     1920x1080p60.00 framerate can be reduced by 1/1.001, CE-video

root@pi3:/tmp# v4l2-ctl --set-dv-bt-timings index=11
BT timings set
will complain:

Code: Select all

root@pi3:/tmp# hyperion-v4l2 --device /dev/video0 --input 0 --width -1 --height -1 --size-decimator 1 --frame-decimator 2 --red-threshold 0.0 --green-threshold 0.0 --blue-threshold 0.0 --screenshot
hyperion-v4l2:
        version   : V1.03.5 (GitHub-66bef6b/fb413cd-1566231780
        build time: Aug 25 2019 10:39:29
V4L2GRABBER INFO: width=1920 height=1080
V4L2GRABBER INFO: pixel format=UYVY
V4L2GRABBER INFO: signal threshold set to: {0,0,0}
V4L2GRABBER INFO: started
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200

Code: Select all


root@pi3:~# ./yavta/yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0
We're encoding to /tmp/file.mp4
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi' (driver 'unicam') is a video capture (without mplanes) device.
stride is 0
stride is now 1280
Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
Framerate is 60
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x156afb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1920, height: 1088, (0,0,1920,1080) pixel aspect ratio: 0/0, frame rate: 0/0
buffers num: 4(opt 1, min 1), size: 4177920(opt 4177920, min: 4177920), align: 0
Created pool of length 4, size 0
Enable encoder....
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 3 buffers of size 3133440 for encode/render
Writing data to /tmp/file.mp4
Create pool of 8 buffers of size 262144
Sent buffer 0x1574f38
Sent buffer 0x1575110
Sent buffer 0x15752e8
Sent buffer 0x15754c0
Sent buffer 0x1575698
Sent buffer 0x1575870
Sent buffer 0x1575a48
Sent buffer 0x1575c20
4 buffers requested, V4L2 returned 4 bufs.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x70904000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 323584
Exported buffer 0 to dmabuf 8, vcsm handle 323584
Linking V4L2 buffer index 0 ptr 0x1576940 to MMAL header 0x15714c8. mmal->data 0xC0000006
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70508000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 327680
Exported buffer 1 to dmabuf 9, vcsm handle 327680
Linking V4L2 buffer index 1 ptr 0x15769b0 to MMAL header 0x15716a0. mmal->data 0xC0000005
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7010c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 331776
Exported buffer 2 to dmabuf 10, vcsm handle 331776
Linking V4L2 buffer index 2 ptr 0x1576a20 to MMAL header 0x1571878. mmal->data 0xC0000004
length: 4177920 offset: 12533760 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x6fd10000.
Importing DMABUF 11 into VCSM...
...done. vcsm_handle 335872
Exported buffer 3 to dmabuf 11, vcsm handle 335872
Linking V4L2 buffer index 3 ptr 0x1576a90 to MMAL header 0x1571a50. mmal->data 0xC0000003
Unable to start streaming: Invalid argument (22).
Releasing vcsm handle 323584
Closing dma_buf 8
Releasing vcsm handle 327680
Closing dma_buf 9
Releasing vcsm handle 331776
Closing dma_buf 10
Releasing vcsm handle 335872
Closing dma_buf 11
4 buffers released.

I have also noticed that when I force something on Pi, will affect the resolution on the TV (the other output of the splitter) :(

So, perhaps I need a splitter where I can manually set an EDID to something like 1080@50Hz or something lower (I have seen in the past some models while looking for not the chepest but still a good one).

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Thu Oct 24, 2019 10:22 am

cr1cr1 wrote:
Thu Oct 24, 2019 8:58 am

Code: Select all

root@pi3:~# v4l2-ctl --query-dv-timings
        Active width: 1366
        Active height: 768
        Total width: 1792
        Total height: 798
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 85800960 Hz (60.00 frames per second)
This captures correctly the input.
Good. That is as expected.
cr1cr1 wrote:If I switch to another video source, say a 4k, the splitter will downscale the output for Pi, and if I run again:

Code: Select all

root@pi3:/tmp# v4l2-ctl --query-dv-timings
        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148500000 Hz (60.00 frames per second)
This is expected, but as you have stated, capturing 1080@60Hz will not work, all programs failing with VIDIOC_STREAMON ERROR 22, Invalid argument
Again good. That is the system doing what it is meant to. 1080p60 produces too much data to squeeze down the link, therefore it is deliberately failed to avoid image corruption.
cr1cr1 wrote:If I force the timings to let's say 1366@60hz again:

Code: Select all

root@pi3:/tmp# v4l2-ctl --list-dv-timings -k | grep 136
        47:     1360x768p60.02
        48:     1360x768p119.97 reduced blanking
        49:     1366x768p59.79
        50:     1366x768p60.00 reduced blanking

root@pi3:/tmp# v4l2-ctl --set-dv-bt-timings index=50
BT timings set
will record a green or black screen.
That's inherent. Telling the receiver that it's 1366x768 when it isn't will result in corrupted data. It'd be the similar to remapping a webserver onto port 22 (SSH) and wondering why it doesn't work.
cr1cr1 wrote:When setting 1920x1080p50.00:

Code: Select all

root@pi3:/tmp# v4l2-ctl --list-dv-timings -k | grep 1080
        8:      1920x1080p24.00 framerate can be reduced by 1/1.001, CE-video
        9:      1920x1080p25.00 CE-video
        10:     1920x1080p30.00 framerate can be reduced by 1/1.001, CE-video
        11:     1920x1080p50.00 CE-video
        12:     1920x1080p60.00 framerate can be reduced by 1/1.001, CE-video

root@pi3:/tmp# v4l2-ctl --set-dv-bt-timings index=11
BT timings set
will complain:

Code: Select all

root@pi3:/tmp# hyperion-v4l2 --device /dev/video0 --input 0 --width -1 --height -1 --size-decimator 1 --frame-decimator 2 --red-threshold 0.0 --green-threshold 0.0 --blue-threshold 0.0 --screenshot
hyperion-v4l2:
        version   : V1.03.5 (GitHub-66bef6b/fb413cd-1566231780
        build time: Aug 25 2019 10:39:29
V4L2GRABBER INFO: width=1920 height=1080
V4L2GRABBER INFO: pixel format=UYVY
V4L2GRABBER INFO: signal threshold set to: {0,0,0}
V4L2GRABBER INFO: started
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
That's an annoying one that I'm in the process of dropping.
MMAL and much of the hardware acceleration requires images that have the stride aligned to a multiple of 32, and the height aligned to a multiple of 16. 1080 is not a multiple of 16, therefore the buffer size advertised through g_fmt (sizeimage) is aligned up to 1088 lines (4177920 bytes). I thought the V4L2 buffer bytesused field got set to the same as sizeimage - indeed it does https://github.com/raspberrypi/linux/bl ... am.c#L1045

The most sensible thing to do as a client is to ensure that the buffer contains at least enough bytes for the bit it is going to process, ie >= rather than ==. Hyperion doesn't https://github.com/hyperion-project/hyp ... r.cpp#L654
The error message is incorrect as the frame isn't too small, it's too big in this case.
cr1cr1 wrote:

Code: Select all

root@pi3:~# ./yavta/yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0
Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
Framerate is 60 <<<<<<<<<<<
<snip>
Unable to start streaming: Invalid argument (22).
yavta will always set the timings to those detected, hence it thinks the framerate is 60fps, and streamon fails.
cr1cr1 wrote:I have also noticed that when I force something on Pi, will affect the resolution on the TV (the other output of the splitter) :(

So, perhaps I need a splitter where I can manually set an EDID to something like 1080@50Hz or something lower (I have seen in the past some models while looking for not the chepest but still a good one).
Using --set-dv-bt-timings shouldn't tell the source anything, it only sets up the timings and resolution that the bridge chip is expecting.
Setting the EDID should pulse the hotplug line so that the source rereads it and changes mode accordingly, but that 's about the only command I'd expect to change things.

What splitter are you using? As I've said, I'm not aware of any at the cheaper end of the range (ie sub £200) that actually scale the image data. They typically combine the EDIDs and advertise the subset to the source. The source will then switch down to a lower resolution, and the splitter will feed that to all outputs.

It may be possible to tweak the CSI2 link frequency out of spec to carry 1080p60 on 2 lanes. I suspect the CSI2 receiver will be happy, but I don't know about the Toshiba bridge chip. Toshiba provide a spreadsheet to compute all the required parameters, but it validates the settings, and complains should the CSI speed/lane exceed the spec maximum. It's not a path I've investigated as we generally want to work within the specification of devices, same as I don't normally overclock Pis as the behaviour is not necessarily predictable.
Doing the rough numbers, you need a CSI2 speed/lane of at least 1067Mb/s, whilst we're currently running at 972Mb/s. If you have some basic C skills, then it's not a huge job to try it out.
https://github.com/raspberrypi/linux/bl ... 43.c#L1978 increase the limit from 1Gb/s.
https://github.com/raspberrypi/linux/bl ... 43.c#L1994 move the default to the 972000000U settings (ideally you would want to add a new case for your new speed).
https://github.com/raspberrypi/linux/bl ... ay.dts#L36 increase the link frequency (this is half the data rate as CSI2 transfers data on each edge of the clock).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Fri Oct 25, 2019 1:05 am

6by9 wrote:
Thu Oct 24, 2019 10:22 am
That's inherent. Telling the receiver that it's 1366x768 when it isn't will result in corrupted data. It'd be the similar to remapping a webserver onto port 22 (SSH) and wondering why it doesn't work.
I have naively thought that the "pulse" you said below would trigger the splitter to adjust itself, but I guess is not that... smart.

I have used cheap splitters that would advertise the lowest resolution, like the one you have exemplified in another similar thread (https://www.raspberrypi.org/forums/view ... 8#p1341785)

Now I am using a fancier one called: UltraHD HDMI 2.0 Splitter
Going with something more expensive defeats (for me) the purpose of using those LEDs.
It becomes more expensive than buying an actual Philips Ambilight TV that has everything integrated :). But I realize most people will use such modules for more interesting things, like actually capturing video from camcoders and such.

Or maybe get a Pi4? :)))

My whole setup is:

Code: Select all

+--------+   +---------+   +----------+    +---------------+   1080@60p
| Laptop |   | Android |   |  RaspPI  +<---+    Toshiba    <------------+
+----+---+   |   TV    |   +----+-----+    | Capture Board |            |
     |       +----+----+        |          +---------------+            |
     |            |             |                                       |
     |1080@60p    |2160@60p     |1080@60p                               |
     v            v             v                              +--------+-------+  up to   +----------------+
+----+--------------------------+-----+      up to 2160        |  UltraHD HDMI  | 2160@60p |      4k TV     |
| TESmart HDMI KVM|Switch 4K@60Hz 4x1 +----------------------->+  2.0 Splitter  +---------->                |
+-------------------------------------+  depending on srouce   +----------------+          +----------------+
- TESmart HDMI KVM-Switch 4K@60Hz 4x1 (https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1)
- UltraHD HDMI 2.0 Splitter (https://www.amazon.co.uk/gp/product/B07 ... UTF8&psc=1)

In the next post I will put the outcome of your suggestions.
Last edited by cr1cr1 on Fri Oct 25, 2019 2:06 am, edited 1 time in total.

cr1cr1
Posts: 6
Joined: Tue Oct 22, 2019 11:14 am

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Fri Oct 25, 2019 1:23 am

Followed your instructions, bot for the moment did not make it work... very tired will try again in the weekend. I have used my amazing highscool C skills :)

So far, I get corrupted image when going 1080@60p

What I did:
  • Used https://raw.githubusercontent.com/notro ... rpi-source to get the kernel source
  • Changed drivers/media/i2c/tc358743.c:

    Code: Select all

    bps_pr_lane > 1100000000U
    
    added:

    Code: Select all

    case 1067000000U:
            state->pdata.lineinitcnt = 0x1b58;
            state->pdata.lptxtimecnt = 0x007;
            /* tclk-preparecnt: 6, tclk-zerocnt: 40 */
            state->pdata.tclk_headercnt = 0x2806;
            state->pdata.tclk_trailcnt = 0x00;
            /* ths-preparecnt: 6, ths-zerocnt: 8 */
            state->pdata.ths_headercnt = 0x0806;
            state->pdata.twakeup = 0x4268;
            state->pdata.tclk_postcnt = 0x008;
            state->pdata.ths_trailcnt = 0x5;
            state->pdata.hstxvregcnt = 0;
            break;
    
    Maybe here those values from the pdata structure need to be increased. This is chinese to me :)
  • Ran in drivers/media/i2c make -C /lib/modules/$(uname -r)/build M=$(pwd) modules
  • Copied tc358743.ko to /lib/modules/$(uname -r)/kernel/drivers/media/i2c/
  • Edited arch/arm/boot/dts/overlays/tc358743-overlay.dts with /bits/ 64 <533500000>;
  • Compile the DTS: dtc -I dts -O dtb -o /boot/overlays/tc358743.dtbo tc358743-overlay.dts
  • Reboot
  • v4l2-ctl --set-edid=file=`readlink -f ~/1080P60EDID.txt` --fix-edid-checksums
  • v4l2-ctl --set-dv-bt-timings query
  • v4l2-ctl -v pixelformat=UYVY
  • ./yavta/yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0
    Using Pi itself as hdmi video source, I've got 1280x720@60p, blank screen - I guess because th eplitter got confused
  • Forced 1080@60p in /boot/config.txt (thinking that the old HDMI to analogue NTSC always presents itself as 1080@60p):

    Code: Select all

    hdmi_group=1
    hdmi_mode=16
    
  • Reboot and loaded again EDID, set timing, pixelformat, ran yavta.
  • Image is there but corrupted and some strange messages:

    Code: Select all

    We're encoding to /tmp/file.mp4
    Device /dev/video0 opened.
    Device `unicam' on `platform:unicam 3f801000.csi' (driver 'unicam') is a video capture (without mplanes) device.
    stride is 0
    stride is now 1280
    Video format set: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
    QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
    Framerate is 60
    Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
    vc.ril.isp:in:0(UYVY)(0x1b9dfb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1920, height: 1088, (0,0,1920,1080) pixel aspect ratio: 0/0, frame rate: 0/0
    buffers num: 4(opt 1, min 1), size: 4177920(opt 4177920, min: 4177920), align: 0
    Created pool of length 4, size 0
    Enable encoder....
    Create pool of 3 buffers of size 0 for render
    Create pool of 3 buffers of size 0 for encode ip
    Create pool of 3 buffers of size 3133440 for encode/render
    Writing data to /tmp/file.mp4
    Create pool of 8 buffers of size 262144
    Sent buffer 0x1ba7f38
    Sent buffer 0x1ba8110
    Sent buffer 0x1ba82e8
    Sent buffer 0x1ba84c0
    Sent buffer 0x1ba8698
    Sent buffer 0x1ba8870
    Sent buffer 0x1ba8a48
    Sent buffer 0x1ba8c20
    4 buffers requested, V4L2 returned 4 bufs.
    length: 4177920 offset: 0 timestamp type/source: mono/EoF
    Buffer 0/0 mapped at address 0x70904000.
    Importing DMABUF 8 into VCSM...
    ...done. vcsm_handle 598016
    Exported buffer 0 to dmabuf 8, vcsm handle 598016
    Linking V4L2 buffer index 0 ptr 0x1ba9940 to MMAL header 0x1ba44c8. mmal->data 0xC0000003
    length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
    Buffer 1/0 mapped at address 0x70508000.
    Importing DMABUF 9 into VCSM...
    ...done. vcsm_handle 602112
    Exported buffer 1 to dmabuf 9, vcsm handle 602112
    Linking V4L2 buffer index 1 ptr 0x1ba99b0 to MMAL header 0x1ba46a0. mmal->data 0xC0000004
    length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
    Buffer 2/0 mapped at address 0x7010c000.
    Importing DMABUF 10 into VCSM...
    ...done. vcsm_handle 606208
    Exported buffer 2 to dmabuf 10, vcsm handle 606208
    Linking V4L2 buffer index 2 ptr 0x1ba9a20 to MMAL header 0x1ba4878. mmal->data 0xC0000005
    length: 4177920 offset: 12533760 timestamp type/source: mono/EoF
    Buffer 3/0 mapped at address 0x6fd10000.
    Importing DMABUF 11 into VCSM...
    ...done. vcsm_handle 610304
    Exported buffer 3 to dmabuf 11, vcsm handle 610304
    Linking V4L2 buffer index 3 ptr 0x1ba9a90 to MMAL header 0x1ba4a50. mmal->data 0xC0000006
    0 (0) [-] none 0 4177920 B 5736.333039 5736.346874 -20000.000 fps ts mono/EoF
    1 (1) [-] none 1 4177920 B 5736.346847 5736.363542 72.422 fps ts mono/EoF
    2 (2) [-] none 2 4177920 B 5736.363513 5736.380234 60.002 fps ts mono/EoF
    3 (3) [-] none 3 4177920 B 5736.380180 5736.396875 59.999 fps ts mono/EoF
    4 (0) [-] none 4 4177920 B 5736.396849 5736.413613 59.992 fps ts mono/EoF
    5 (1) [-] none 5 4177920 B 5736.413514 5736.430270 60.006 fps ts mono/EoF
    6 (2) [-] none 6 4177920 B 5736.430184 5736.446923 59.988 fps ts mono/EoF
    7 (3) [-] none 7 4177920 B 5736.446846 5736.463551 60.017 fps ts mono/EoF
    8 (0) [-] none 8 4177920 B 5736.463521 5736.480271 59.970 fps ts mono/EoF
    9 (1) [-] none 9 4177920 B 5736.480182 5736.496890 60.020 fps ts mono/EoF
    10 (2) [-] none 10 4177920 B 5736.496848 5736.513661 60.002 fps ts mono/EoF
    11 (3) [-] none 11 4177920 B 5736.513529 5736.530322 59.948 fps ts mono/EoF
    12 (0) [-] none 12 4177920 B 5736.530188 5736.546998 60.028 fps ts mono/EoF
    13 (1) [-] none 13 4177920 B 5736.546858 5736.563579 59.988 fps ts mono/EoF
    14 (2) [-] none 14 4177920 B 5736.580192 5736.580292 29.999 fps ts mono/EoF
    DROPPED FRAME - 213819 and 247153, delta 33334
    15 (3) [-] none 15 4177920 B 0.000000 5736.596879 -0.001 fps ts mono/EoF
    16 (0) [-] none 16 4177920 B 5736.596846 5736.613565 0.001 fps ts mono/EoF
    DROPPED FRAME - -1441365743 and 263807, delta 1441629550
    17 (1) [-] none 17 4177920 B 5736.613514 5736.630376 59.995 fps ts mono/EoF
    .................SNIP..................
    Captured 300 frames in 7.213874 seconds (41.586527 fps, 173745182.776997 B/s).
    Total number of frames dropped 136
    Releasing vcsm handle 598016
    Closing dma_buf 8
    Releasing vcsm handle 602112
    Closing dma_buf 9
    Releasing vcsm handle 606208
    Closing dma_buf 10
    Releasing vcsm handle 610304
    Closing dma_buf 11
    4 buffers released.
    Failed to find matching V4L2 buffer for mmal buffer 0x1ba4878
    
Q: how to check the proper clock/new speed is there, other than yavta not failing with code 22 anymore ?

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sat Nov 23, 2019 8:35 pm

hello everybody. It's nice thread.

@cr1cr1 any progress to make it working with hyperion?

I would like to do same thing.

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sun Nov 24, 2019 3:14 pm

Some details about my try:

source 1920x1080@50 > splitter > raspbian
v4l2-ctl --set-edid=file=/home/pi/Downloads/yavta/1080P50EDID.txt --fix-edid-checksums
v4l2-ctl --query-dv-timings
v4l2-ctl --set-dv-bt-timings index=11

./yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0 => it's working as expected

but get hyperion screenshot error:
sudo hyperion-v4l2 --width 320 --height 180 --screenshot
hyperion-v4l2:
version : V1.03.5 (GitHub-66bef6b/fb413cd-1566231780
build time: Aug 25 2019 10:39:29
V4L2GRABBER INFO: width=1920 height=1080
V4L2GRABBER INFO: pixel format=UYVY
V4L2GRABBER INFO: signal threshold set to: {0,0,0}
V4L2GRABBER INFO: started
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sun Nov 24, 2019 3:32 pm

ellisium wrote:
Sun Nov 24, 2019 3:14 pm
Some details about my try:

source 1920x1080@50 > splitter > raspbian
v4l2-ctl --set-edid=file=/home/pi/Downloads/yavta/1080P50EDID.txt --fix-edid-checksums
v4l2-ctl --query-dv-timings
v4l2-ctl --set-dv-bt-timings index=11

./yavta --capture=300 -n 4 --encode-to=/tmp/file.mp4 -f UYVY -m -T /dev/video0 => it's working as expected

but get hyperion screenshot error:
sudo hyperion-v4l2 --width 320 --height 180 --screenshot
hyperion-v4l2:
version : V1.03.5 (GitHub-66bef6b/fb413cd-1566231780
build time: Aug 25 2019 10:39:29
V4L2GRABBER INFO: width=1920 height=1080
V4L2GRABBER INFO: pixel format=UYVY
V4L2GRABBER INFO: signal threshold set to: {0,0,0}
V4L2GRABBER INFO: started
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
V4L2GRABBER ERROR: Frame too small: 4177920 != 4147200
That's an issue in hyperion that I've already referenced.
https://github.com/hyperion-project/hyp ... r.cpp#L654 wants to be <, not != (assuming I've got the two parameters the right way around)

Latest versions of v4l2-ctl also allow you to do "v4l2-ctl --set-dv-bt-timings query" to avoid having to look up resolutions and timings.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sun Nov 24, 2019 6:46 pm

Thx very much!
So I have to rebuild hyperion after fixing the issue that you referenced? Or will it befixed in futur hyperion version?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Fri Nov 29, 2019 9:38 am

ellisium wrote:
Sun Nov 24, 2019 6:46 pm
Thx very much!
So I have to rebuild hyperion after fixing the issue that you referenced? Or will it befixed in futur hyperion version?
I haven't done any work on hyperion, and nor do I really intend to. I simply searched for the error message and have made comment as to why it is failing. I'll leave it up to those who actually work on the project to make any changes they see fit based on those comments.
You may wish to create an issue on https://github.com/hyperion-project/hyperion/issues to draw this conversation to their attention - they're unlikely to be following the Pi forums themselves.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Thu Dec 05, 2019 1:37 pm

thx it's now working as expected following your advice.

Just another question relative to HDMI-CEC, did you try some tests on this point?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7572
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Thu Dec 05, 2019 1:43 pm

ellisium wrote:
Thu Dec 05, 2019 1:37 pm
Just another question relative to HDMI-CEC, did you try some tests on this point?
CEC via the TC358743, or CEC out the HDMI output of the Pi?

The whole TC358743 driver is provided by mainline Linux, mainly developed and maintained by Cisco for some of their Videophones. Hans Verkuil tends to look after CEC there, and is generally a stickler for the detail.
CEC through the HDMI output is used by things like LibreElec/Kodi.

In both cases it's not something I've really experimented with. What specifically are you trying to do? There are several CEC utilities in the v4l-utils repo https://git.linuxtv.org/v4l-utils.git/tree/utils
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sat Dec 07, 2019 10:10 am

Hello,

My installation:
mi box android TV > splitter > hdmi input raspberry > arduino IR (trigger projector power, home theater amp) + relay (trigger power amp)
Before to switch on android TV, I used kodi on osmc controlled via yatse through node.js proxy to listen commands.
However Yatse can't command android applications so I can't use it anymore. I can only use android remote but I didn't find easy way to implement node.js proxy.
I would like to listen hdmi commands sent from android tv through this hdmi board on raspbian. by example, press power button on remote, receive power command then forward it to trigger projector and amps

About Hans Verkuil, I found an interesting pdf talking about HDMI CEC but only noted at the end work in progress about implementation of this board.

ellisium
Posts: 10
Joined: Sat Nov 23, 2019 8:29 pm

Re: HDMI to CSI-2 via TC358743 on kernel 4.1

Sat Dec 07, 2019 12:01 pm

After few searchs, I checked /dev folder and surprising no /dev/cec0 listed. Driver is not CEC enable by default?

Return to “Graphics, sound and multimedia”