6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 27, 2017 10:23 am

RichShumaker wrote:As I always seem to start these thread posts THANKS 6by9 for all you do.

Now I have a simple question, does the HDMI to CSI workflow work currently?
I read thru a lot of the posts and I was just looking for a simple, "yes it works do this" and I was having a hard time finding that.
Is there a Wiki or place with more details on setup and usage?

Thanks everyone for all the hard work getting this going.
I had dropped External Video Inputs into the Pi using the GPU several years ago so I am excited that it has been active for as long as it has.
Yes it works for most of the resolutions tried between 720x576@50 to 1920x1080@30, although some only in UYVY mode and some only in RGB24 mode. It's all related to the HDMI vs CSI timings. Please remember that interlaced resolutions are not supported.
I have it working in the same way as half of raspi_tc358743.c in that it can route the images through to the display. For the sake of completeness I'm just adding H264 encoding as well so it is the same as raspi_tc358743.c, as well as handling some of the V4L2 setup to make it a little more user friendly.

No, I haven't written up a how-to because it is still in a state of flux as it is being reviewed upstream. If you want to be involved in testing it then please email me and I'll add you to the list and send out instructions. As mentioned in my response to auvidea, things vary based on which Pi variant you are using, and I haven't finnessed the nice way of handling that.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Tue Jun 27, 2017 6:43 pm

Perfect and Thanks.
I am not a good beta tester as I am an advanced user.
Also I don't own the product yet as it is pricey for something that I can't plug and play with.
I just bought a USB3 HDMi video encoder for less than the cost of the HDMI 103 board.
Which is basically how I would use this as a video encoder for production.

I appreciate and have benefited greatly from all the work you do and all the people in the community do.
I have used the RasPi cameras since it was first released as a User.
That is why I gravitated towards RPi_Cam_Web_Interface as it works for me and is easy to deploy over and over.
That is what I would use with this as well unless it didn't work for some reason.
I love testing weird formats with RPiCWI, like 42 frames per second. I seem to love that frame rate.
I have a V1 camera and I know the limitations of the GPU to 1080p encoding.

Here is a video of me testing different cameras, 3 Pi's and 1 NDI from an Android Cell Phone.
https://youtu.be/_vzl0lU5k5I
My goal has always been to use the Pi as a Motion Capture Rig or as I call it Reverse 360 cam.
I built a 360 cam with Pi's and then figured out I don't want that.
I need to film the subject in 360 not the world in 360 and I think it is the greatest downfall of the current state of 360 video recording / VR stuff.

Side note NDI is a NewTek open standard for using Ethernet to send a Broadcast Video & Audio signal.
It is amazingly fast and works really really well. Don't let my crappy video fool you it is awesome.
The ARM SDK is not a full blown SDK from what I know. Not sure if you could adapt it to a Pi.
I know that the GPU has a blob with codecs(which is what I consider NDI a Compression Decompression Format) that can be unlocked BUT this codec is too new and I know it is not in the blob.
I would ask to add it except I know that is not really an option.

Thanks again and have an awesome day.
I have a feeling I will be purchasing one of these later this year to experiment with.

Rich Shumaker
Rich Shumaker

carlos.rodriguez
Posts: 5
Joined: Wed Jun 28, 2017 12:30 pm

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

Wed Jun 28, 2017 4:02 pm

Hello,

I've been trying to use a B101 board from Auvidea connected to a GoPro Hero 5 to get the video feed on a Raspberry Pi 3 without success. The raspivid command works OK when the B101 is connected to my laptop via HDMI but does not when connected to the camera.

I don't know if it's a problem with the camera not supporting the EDID provided by the B101 board.

When launching raspivid I get the following error:

Code: Select all

mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates
vcdb log msg:

Code: Select all

070300.683: camsubs: Looking for camera 0: i2c_port = 0, led gpio = 134, power enable gpio = 133
070301.402: camsubs: Camera not found
070301.438: camsubs: Looking for camera 0: i2c_port = 0, led gpio = 134, power enable gpio = 133
070302.156: camsubs: Camera not found
070302.193: camsubs: Looking for camera 0: i2c_port = 0, led gpio = 134, power enable gpio = 133
070302.719: camsubs: Camera found OK
070308.148: gpioman: gpioman_get_pin_num: pin CAMERA_LED not defined
vcdbg log assert (start_debug=1 in config.txt)

Code: Select all

2418380.321: assert( num_modes > 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::open_camera_driver line 736 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2423390.115: assert( retcode == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::open_camera_peripheral line 618 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2423390.157: assert( success == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::cdi_camera_change_state line 1370 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2423390.214: assert( *retcode == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::cdi_camera_open line 595 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2423445.678: assert( retcode == 0 ) failed; ../../../../../middleware/openmaxil/components/camera.c::load_and_open_cdi line 11983 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2423445.746: assert( id->cdi!=NULL && id->cdi_handle!=NULL ) failed; ../../../../../middleware/openmaxil/components/camera.c::open_camplus line 11330 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2434281.360: assert( num_modes > 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::open_camera_driver line 736 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2439284.304: assert( retcode == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::open_camera_peripheral line 618 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2439284.348: assert( success == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::cdi_camera_change_state line 1370 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2439284.404: assert( *retcode == 0 ) failed; ../../../../../middleware/camplus/cdi/cdi_camera.c::cdi_camera_open line 595 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2439351.939: assert( retcode == 0 ) failed; ../../../../../middleware/openmaxil/components/camera.c::load_and_open_cdi line 11983 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
----------------
2439352.009: assert( id->cdi!=NULL && id->cdi_handle!=NULL ) failed; ../../../../../middleware/openmaxil/components/camera.c::open_camplus line 11330 rev 9469ea3
vcdbg_ctx_get_dump_stack: dump_stack failed
I also tried compiling raspivid and raspi_tc358743 from https://github.com/6by9/userland/tree/hdmi_in_hack. Same error with this version of raspivid.
raspi_tc358743 gives the following output but does nothing:

Code: Select all

Filename is test_encode.h264
Playing back indefinitely
Do any of you know how could I get this setup to work? I don't know what else to try...

Thanks in advance!

Carlos

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Wed Jun 28, 2017 6:30 pm

First I am new to this so I don't know the in's and out's of the software.
I do know AV troubleshooting.

From an AV troubleshooting point of view I would change the settings on the GoPro and see if 'any' resolutions work like 720p or Standard Def.
Also I would try a converter box not to make a conversion but to see if I could 'inject' what the signal needs to be recognized.

I have had 'issues' with many devices not synchronizing because the signal was 'off' even if it was ever so slightly.
Specifically my Black Magic Design Capture Card would not recognize my GoPro via HDMI, then I sent it through an HDMI to SDI box as the card also has SDI.
Then it worked no problem.

Hope that helps.

Rich Shumaker
Rich Shumaker

carlos.rodriguez
Posts: 5
Joined: Wed Jun 28, 2017 12:30 pm

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

Thu Jun 29, 2017 4:01 pm

Thanks Rich Shumaker. I am trying to find a video receiver with only 720p but all my TVs here have at least 1080p so I can't test if the GoPro is able to ouput 720p video.

I am trying the raspi_tc358743 binary with my laptop (which works well when running raspivid) but I get another error:

./camera_i2c && ./build/bin/raspi_tc358743

Code: Select all

mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: rx_cfg.data_lanes = 1
mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable isp....
mmal: Enable splitter....
mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: Selected Sub 720p registers
mmal: Waiting to detect signal...
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 09
mmal: no_sync read 8F
mmal: no_signal read 8F
mmal: Signal reported
mmal: First playthrough, Goto Loop
mmal: VI_STATUS to select cfg.data_lanes: 12
mmal: rx_cfg.data_lanes = 2
mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable isp....
mmal: Enable splitter....
mmal: VI_STATUS to select cfg.data_lanes: 12
mmal: Selected 720p+ registers
mmal: Waiting to detect signal...
mmal: no_sync read 8F
mmal: no_signal read 8F
mmal: Signal reported
mmal: Signal is 1280 x 720, frm_interval 166, so 60 fps
mmal: Frame w x h is 1650 x 750
mmal: output: buffer size is 2764800 bytes, num 3
mmal: Create connection rawcam output to isp input....
mmal: Setting isp output port format
mmal: Create connection isp output to splitter input....
mmal: Create connection splitter output to render input....
mmal: Create connection splitter output2 to encoder input....
mmal: Enable encoder....
mmal: Enable connection[0]...
mmal: buffer size is 2764800 bytes, num 3
mmal: Enable connection[1]...
mmal: buffer size is 1382400 bytes, num 1
mmal: Enable connection[2]...
mmal: buffer size is 1382400 bytes, num 1
mmal: Enable connection[3]...
mmal: buffer size is 1382400 bytes, num 1
mmal: Create pool of 8 buffers of size 65536
mmal: Sent buffer 0x1ce1b08
mmal: Sent buffer 0x1ce1ce0
mmal: Sent buffer 0x1ce1eb8
mmal: Sent buffer 0x1ce2090
mmal: Sent buffer 0x1ce2268
mmal: Sent buffer 0x1ce2440
mmal: Buffer 0x1ce1b08 returned, filled 27, timestamp 0, flags 0024
mmal: Sent buffer 0x1ce2618
mmal: Sent buffer 0x1ce27f0
mmal: All done. Start streaming...
mmal: View!
mmal: Sleeping until you ctrl+c me!
mmal: Buffer 0x1ce1ce0 returned, filled 263, timestamp 990573536, flags 000C
mmal: Buffer 0x1ce1eb8 returned, filled 36, timestamp 990601789, flags 0004
mmal: Buffer 0x1ce2090 returned, filled 36, timestamp 990635115, flags 0004
mmal: Buffer 0x1ce2268 returned, filled 36, timestamp 990668449, flags 0004
mmal: Buffer 0x1ce2440 returned, filled 36, timestamp 990701790, flags 0004
mmal: Buffer 0x1ce2618 returned, filled 36, timestamp 990735117, flags 0004
mmal: Buffer 0x1ce27f0 returned, filled 36, timestamp 990768451, flags 0004
mmal: Buffer 0x1ce1b08 returned, filled 36, timestamp 990801785, flags 0004
assertion failure:/home/pi/hdmi_in_hack/interface/mmal/core/mmal_queue.c:49:mmal_queue_sanity_check():buffer != q
For a really short time I get to see like a flash of my laptop desktop in the preview window.

What can be causing this assertion failure in mmal_queue_sanity_check?

Thanks,

Carlos

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 29, 2017 4:25 pm

Sorry not enough time to reply in detail now.
carlos.rodriguez wrote:What can be causing this assertion failure in mmal_queue_sanity_check?
A mmal_queue uses a singlely linked list to queue up buffers. mmal_queue_sanity_check checks that the buffer about to be added to the queue isn't already there, as adding it would create a circular reference in the list, and "bad things" then happen.

Your buffer sizes look a bit odd - 27 bytes is the H264 header bytes, 263 bytes with flags 0x0C is the I-frame, and then multiple 36 byte packets as P-frames - those are tiny for encoded data. Has the encode bitrate got turned right down somehow? I can't remember whether that is on the command line or not. Have a quick look at the source code as it should be obvious.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Fri Jun 30, 2017 12:42 am

carlos.rodriguez wrote:Thanks Rich Shumaker. I am trying to find a video receiver with only 720p but all my TVs here have at least 1080p so I can't test if the GoPro is able to ouput 720p video.

Thanks,

Carlos
6 by 9 already answered with something much better.
I just wanted to let you know that most modern screens that do 1080p also do 720p. You should be able to set your GoPro to 720p and then direct connect to a 1080p screen and it will see the signal and show you 720p.

It is the reverse that seldom happens that a Standard Definition Screen can show a 1080p signal.

Have a great day.

Rich Shumaker
Rich Shumaker

carlos.rodriguez
Posts: 5
Joined: Wed Jun 28, 2017 12:30 pm

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

Fri Jun 30, 2017 9:36 am

6by9 wrote:Your buffer sizes look a bit odd - 27 bytes is the H264 header bytes, 263 bytes with flags 0x0C is the I-frame, and then multiple 36 byte packets as P-frames - those are tiny for encoded data. Has the encode bitrate got turned right down somehow? I can't remember whether that is on the command line or not. Have a quick look at the source code as it should be obvious.
Thanks, I tried modifying raspi_tc358743.c doubling the bitrate value (from 17000000 to 34000000) and the errors are gone! I get 1080p25 from my laptop but a few glitches appear in the video from time to time.

Code: Select all

encoder_output->format->bitrate = 34000000;
RichShumaker wrote: I just wanted to let you know that most modern screens that do 1080p also do 720p. You should be able to set your GoPro to 720p and then direct connect to a 1080p screen and it will see the signal and show you 720p.
The problem is that the GoPro Hero 5 has no setting to change the output video format. It is supposed to be selected automatically based on the EDID received. Even if I set to record in 720p30 I still get an HDMI out signal at 1080p60. I will try and contact GoPro support for more information.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 30, 2017 9:46 am

carlos.rodriguez wrote:
6by9 wrote:Your buffer sizes look a bit odd - 27 bytes is the H264 header bytes, 263 bytes with flags 0x0C is the I-frame, and then multiple 36 byte packets as P-frames - those are tiny for encoded data. Has the encode bitrate got turned right down somehow? I can't remember whether that is on the command line or not. Have a quick look at the source code as it should be obvious.
Thanks, I tried modifying raspi_tc358743.c doubling the bitrate value (from 17000000 to 34000000) and the errors are gone! I get 1080p25 from my laptop but a few glitches appear in the video from time to time.

Code: Select all

encoder_output->format->bitrate = 34000000;
That's a bit bizarre. It possibly means that the frame rate value being set is wrong. If given a framerate then bitrate control assumes the frame rate is as defined and divides up bits accordingly. If fps is set to 0 then it works off the frame timestamps (which should all be valid and correct).
It'd be useful to know what bitrate is actually being produced with your 34Mbit/s value (which technically is beyond what the codec can produce!)
carlos.rodriguez wrote:
RichShumaker wrote: I just wanted to let you know that most modern screens that do 1080p also do 720p. You should be able to set your GoPro to 720p and then direct connect to a 1080p screen and it will see the signal and show you 720p.
The problem is that the GoPro Hero 5 has no setting to change the output video format. It is supposed to be selected automatically based on the EDID received. Even if I set to record in 720p30 I still get an HDMI out signal at 1080p60. I will try and contact GoPro support for more information.
The EDID advertises the supported resolutions and framerates, and raspi_tc358743 goes up to 1080P30 with a native/recommended resolution of 720P60. The GoPro should be reading that and selecting an appropriate mode. Your logging would imply that that is working based on the logging:

Code: Select all

mmal: Signal reported
mmal: Signal is 1280 x 720, frm_interval 166, so 60 fps
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

carlos.rodriguez
Posts: 5
Joined: Wed Jun 28, 2017 12:30 pm

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

Fri Jun 30, 2017 10:06 am

6by9 wrote:The EDID advertises the supported resolutions and framerates, and raspi_tc358743 goes up to 1080P30 with a native/recommended resolution of 720P60. The GoPro should be reading that and selecting an appropriate mode. Your logging would imply that that is working based on the logging:

Code: Select all

mmal: Signal reported
mmal: Signal is 1280 x 720, frm_interval 166, so 60 fps
That log was when connecting to my laptop. When connected to the GoPro I get no screen and the raspi_tc358743 command returns the following:

Code: Select all

mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: rx_cfg.data_lanes = 1
mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable isp....
mmal: Enable splitter....
mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: Selected Sub 720p registers
mmal: Waiting to detect signal...
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: Signal reported
mmal: First playthrough, Goto Loop
mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: rx_cfg.data_lanes = 1
mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable isp....
mmal: Enable splitter....
mmal: VI_STATUS to select cfg.data_lanes: 0
mmal: Selected Sub 720p registers
mmal: Waiting to detect signal...
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: no_sync read 01
mmal: Signal reported
mmal: Signal is 0 x 0, frm_interval 0, so 0 fps
mmal: Frame w x h is 0 x 0
mmal: mmal_vc_port_info_set: failed to set port info (3:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x1359ba0 (EINVAL)
mmal: output: Failed port_format_commit

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 30, 2017 10:29 am

carlos.rodriguez wrote:
6by9 wrote:The EDID advertises the supported resolutions and framerates, and raspi_tc358743 goes up to 1080P30 with a native/recommended resolution of 720P60. The GoPro should be reading that and selecting an appropriate mode. Your logging would imply that that is working based on the logging:

Code: Select all

mmal: Signal reported
mmal: Signal is 1280 x 720, frm_interval 166, so 60 fps
That log was when connecting to my laptop. When connected to the GoPro I get no screen and the raspi_tc358743 command returns the following:
Ah, OK.
raspi_tc358743 gives up after 5 seconds of waiting for a signal and just tried to run (it's not meant to be a polished app!).
Whilst the data sheet isn't public, http://elixir.free-electrons.com/linux/ ... egs.h#L313 gives the relevant bit meanings. It got copied for https://github.com/6by9/userland/blob/h ... 743_regs.h
Repeatedly getting 0x01 just DDC5V means that the GoPro isn't really attempting to connect. It's just possible that the GoPro is trying to enforce HDCP when it isn't supported but either the chip or code, but I don't know.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Fri Jun 30, 2017 2:40 pm

RichShumaker wrote: I just wanted to let you know that most modern screens that do 1080p also do 720p. You should be able to set your GoPro to 720p and then direct connect to a 1080p screen and it will see the signal and show you 720p.
The problem is that the GoPro Hero 5 has no setting to change the output video format. It is supposed to be selected automatically based on the EDID received. Even if I set to record in 720p30 I still get an HDMI out signal at 1080p60. I will try and contact GoPro support for more information.
That is weird for sure.
The issue you describe definitely seems like you are trying to give the RasPi a signal it doesn't like.
I have had similar issue with Capture devices. If I try to feed X to certain devices it doesn't like it. X being a resolution usually 60P and not 30P(or 60i).
GoPro has a LOT of resolutions and here is the chart - https://gopro.com/help/articles/Block/A ... O5-Session
It seems weird that the record resolution is different then the resolution out the HDMI and that is something I would say GoPro would need to answer.
Mic Bergsma is my Go to Guy for GoPro Tips and Tricks here is a video of his that might help as well, https://youtu.be/QYzvQpnYSK0
I also found this GoPro thread that discusses HMDI out on the Hero 5 - https://community.gopro.com/t5/Cameras/ ... 227/page/2#
It is your exact issue. If the GoPro is sending a 60p signal and not a 30p or 60i signal the RasPi won't lock on.
60p is considered 3G and 60i is considered 1.5G in Broadcast terms. The RasPi is only rated to 30p(60i).
I am not sure if the RasPi can handle the interlace but I don't see why it couldn't. I just know that 60p is beyond the capabilities of the RasPi at this time.

The only other option and it is silly is to convert the signal with a signal converter(downscaler or Scan Converter I think it what they are called) that will cost more than the RasPi with the add on board though. They run between $300 and $3000 depending on the features you need.

Good Luck and I hope it works because I want to use a RasPi Capture device with my GoPro someday.

Rich Shumaker
Rich Shumaker

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 30, 2017 3:10 pm

RichShumaker wrote:It is your exact issue. If the GoPro is sending a 60p signal and not a 30p or 60i signal the RasPi won't lock on.
60p is considered 3G and 60i is considered 1.5G in Broadcast terms. The RasPi is only rated to 30p(60i).
I am not sure if the RasPi can handle the interlace but I don't see why it couldn't. I just know that 60p is beyond the capabilities of the RasPi at this time.
The Toshiba TC358743 HDMI to CSI-2 chip will cope up to 1080P60, but 2 lanes of CSI-2 won't.

Interlaced video has multiple issues:
- The two fields come in with different packet IDs, but handling that nicely to a user app with the correct signalling is not trivial. Obviously getting fields reversed is next to useless.
- The H264 encoder is progressive only, up to 1080P30 (a bit higher with overclocking).
- The TC358743 can only handle interlaced as RGB888 or YUV444, so 50% extra data over YUV422.
Last edited by 6by9 on Fri Jun 30, 2017 3:51 pm, edited 1 time in total.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Fri Jun 30, 2017 3:21 pm

6by9 wrote:
RichShumaker wrote:It is your exact issue. If the GoPro is sending a 60p signal and not a 30p or 60i signal the RasPi won't lock on.
60p is considered 3G and 60i is considered 1.5G in Broadcast terms. The RasPi is only rated to 30p(60i).
I am not sure if the RasPi can handle the interlace but I don't see why it couldn't. I just know that 60p is beyond the capabilities of the RasPi at this time.
The Toshiba TC358743 HDMI to CSI-2 chip will cope up to 1080P60, but 2 lanes of CSI-2 won't.

Interlaced video has multiple issues:
- The two fields come in with different packet IDs, but handling that nicely to a user app with the correct signalling is not trivial. Obviously getting fields reversed is next to useless. - The H264 encoder is progressive only, up to 1080P30 (a bit higher with overclocking).
- The TC358743 can only handle interlaced as RGB888 or YUV444, so 50% extra data over YUV422.
I apologize as I understand interlace all too jaggedly well and I should have known it was not 'simple'.
That is good to hear the RasPi can handle up to 60p with the 4 lane CSI. Can the GPU encode 60p?
This leads us back to the start which is I think the GoPro is sending 60p and the RasPi wants 30p and therefore can't lock onto the signal.

As I said I would attempt to lower the GoPro signal as low as it will go, so 480p I think is what it is called. Basically either Standard Definition PAL/NTSC signal size.
If the Raspberry Pi works with that then I would slowly raise it to 720p then 1080p - The P stands for Progressive and it is necessary for the Pi to see the signal properly based on what 6 by 9 just said.

Thanks 6 by 9 for all the help.

Rich Shumaker
Rich Shumaker

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jun 30, 2017 3:59 pm

RichShumaker wrote:That is good to hear the RasPi can handle up to 60p with the 4 lane CSI. Can the GPU encode 60p?
Not 1080P60. I'd already stated "The H264 encoder is progressive only, up to 1080P30 (a bit higher with overclocking)."
RichShumaker wrote:This leads us back to the start which is I think the GoPro is sending 60p and the RasPi wants 30p and therefore can't lock onto the signal.
No, it seems to be sending nothing.
The raspi_tc358743 app starts by polling the TC358743 (which can support 1080P60) for the HDMI timing and mode information for the source. The TC358743 is reporting back "no sync", so this is all well before the Pi has got involved in trying to set up receivers.
The only bit the Pi has got involved in is sending the TC358743 an EDID to use, and that is only advertising modes

Code: Select all

1
2
3
4 (preferred/native)
17
18
19
32
33
34
60
Look them up on https://en.wikipedia.org/wiki/Extended_ ... _Version_3
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Fri Jun 30, 2017 4:40 pm

Thanks 6 by 9 for the clarification.
I will be reading up on EDID.

If a device sends no EDID can the signal be 'locked' on'?
The reason I ask is that you can strip the EDID out.
So what happens if a signal that is not proper is sent to the RasPi?
Let's say a 4K signal is sent to it?

Oh and if it is the case that the RasPi sees nothing in this situation that would lead me to say bad cable.
Have you attempted to use a known good cable? Meaning testing the cable and GoPro outside the RasPi setup?

Thanks again for the help and I am off to read up on EDID.

Rich Shumaker
Rich Shumaker

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Fri Jun 30, 2017 4:45 pm

RichShumaker wrote: Oh and if it is the case that the RasPi sees nothing in this situation that would lead me to say bad cable.
Have you attempted to use a known good cable? Meaning testing the cable and GoPro outside the RasPi setup?


Rich Shumaker
Oh and I should have also asked have you gotten this unit to work with any other inputs besides the GoPro?
From my experiences with the camera when I have seated my CSI cable incorrectly it has caused errors when you try to view the live image.
I am guessing we would be seeing errors but I was not sure as I stated I don't own one of these yet.

Thanks again.

Rich Shumaker
Rich Shumaker

RpiName
Posts: 628
Joined: Sat Jul 06, 2013 3:14 am

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

Sat Jul 01, 2017 7:11 pm

The TC358743 chip is supported by UV4L now. This is the news:

https://www.linux-projects.org/2017/07/ ... -tc358743/

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Sun Jul 02, 2017 7:32 am

RpiName wrote:The TC358743 chip is supported by UV4L now. This is the news:

https://www.linux-projects.org/2017/07/ ... -tc358743/
Thanks for sharing this.

Looks like it is RasPi 3 only right now or did I misread that?
I wonder how high up the resolution chart it can go in the real world?

Wow this is pretty cool and I am excited to see what can be done.

Rich Shumaker
Rich Shumaker

RpiName
Posts: 628
Joined: Sat Jul 06, 2013 3:14 am

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

Sun Jul 02, 2017 8:48 am

RichShumaker wrote:I wonder how high up the resolution chart it can go in the real world?
Tested on rpi3 for now but can it can work with other other rpis (including the pi zeros) by tweaking a config file (more about this will probably be written in a tutorial). Any resolution (with auto scale) any encoding (planar yuvs, packed rgbs, mjpeg, h264) any fps (depending on the source) up to the hardware limits is supported by the driver.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Sun Jul 02, 2017 1:56 pm

RpiName wrote:
RichShumaker wrote:I wonder how high up the resolution chart it can go in the real world?
Tested on rpi3 for now but can it can work with other other rpis (including the pi zeros) by tweaking a config file (more about this will probably be written in a tutorial). Any resolution (with auto scale) any encoding (planar yuvs, packed rgbs, mjpeg, h264) any fps (depending on the source) up to the hardware limits is supported by the driver.
Two Words, WOOHOO & AWESOME. I know you are probably thinking WooHoo isn't that actually 2 words, heheh.
Thanks for that awesome news it made my day.

Rich Shumaker
Rich Shumaker

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4604
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 Jul 02, 2017 3:51 pm

RichShumaker wrote:
RpiName wrote:
RichShumaker wrote:I wonder how high up the resolution chart it can go in the real world?
Tested on rpi3 for now but can it can work with other other rpis (including the pi zeros) by tweaking a config file (more about this will probably be written in a tutorial). Any resolution (with auto scale) any encoding (planar yuvs, packed rgbs, mjpeg, h264) any fps (depending on the source) up to the hardware limits is supported by the driver.
Two Words, WOOHOO & AWESOME. I know you are probably thinking WooHoo isn't that actually 2 words, heheh.
Thanks for that awesome news it made my day.
No disrespect to UV4L2, but this is NOT using any upstream kernel code. It is a closed source userspace library.
It's also using the rawcam component that is known to have a bug that leads to locking up the Gpu.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
RichShumaker
Posts: 147
Joined: Tue Jul 31, 2012 4:16 pm
Location: Sunny Southern CA near downtown LA
Contact: Website

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

Sun Jul 02, 2017 4:57 pm

6by9 wrote: No disrespect to UV4L2, but this is NOT using any upstream kernel code. It is a closed source userspace library.
It's also using the rawcam component that is known to have a bug that leads to locking up the Gpu.
Dagnabit I was doing a happy dance.
I do have to say THANK YOU to 6by9 for pointing this out as it would have made me mad to run into that Bug when trying this out.

So basic question, what is the best way to 'stream' the TC358743 using the Pi?

Thanks again.
Rich Shumaker
Rich Shumaker

RpiName
Posts: 628
Joined: Sat Jul 06, 2013 3:14 am

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

Sun Jul 02, 2017 5:02 pm

6by9 wrote:No disrespect to UV4L2, but this is NOT using any upstream kernel code. It is a closed source userspace library.
It's also using the rawcam component that is known to have a bug that leads to locking up the Gpu.
As far as I can tell, the firmware code is as closed as UV4L. You are right in saying that it is not using the upstream kernel code. In facts, almost everything runs in userspace, accessing the GPU whenever possible. UV4L is NOT a library. It consists of a series of Video4Linux2 userspace drivers (you can NOT tell there is a difference from kernel drivers from the user perspective) that you can use with any third-party applications and other extensions. We always promptly fix any problems that the users may find in any module of UV4L. As to the rawcam component locking up the GPU, we possibly understood when this problem would happen and eventually found a working solution (indeed it was a nightmare to get the pipelines up and running properly). The hope is that any known problems with the GPU will also be fixed as soon as possible or at least that the rawcam component won't change for the worse in the future, which should be the case according to what you said in another post (point 3):
rawcam will remain supported as it is a useful tool in avoiding having to push everything into the kernel. (Fixing the double-free issue is on my list too).
viewtopic.php?f=44&t=179163&p=1166579&h ... m#p1166579

many thanks for your help.

carlos.rodriguez
Posts: 5
Joined: Wed Jun 28, 2017 12:30 pm

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

Wed Jul 05, 2017 1:53 pm

Hello,

First of all, I've "solved" my issue with the GoPro Hero 5 and the B101 board. I don't know the reason but if I connect an HDMI switch between the GoPro and the board everything works great. (link to the switch used: http://www.tecknet.co.uk/hdmi03.html). No need to power the switch with the MicroUSB included.
I've been sniffing EDID data and the switch does not change it so the issue is not there. I also tried with a GoPro Hero 3 and it works fine without the need of the switch. Anyway, I can live with that.

The problem I am facing now is with 1080p25 resolution. I get a lot of glitches in the video even in the preview window (which I guess is in raw format because when the encoding format is wrong I still get the preview to show up). I've uploaded a screenshot of the issue: https://ibb.co/krJg2v . I've tried at different bitrates and fps. Has any of you managed to get 1080p25 video out of the B101?

Thanks.

Carlos

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: No registered users and 9 guests