Home

Products
Blog
Downloads
Community
Help
Forums
Education
Projects
Open Search Input
Quick Start GuideForum FAQAbout
About us
Contact us
Technical, help and resource documents
Trademark rules

Search

LoginRegister
Board indexProjectsGraphics, sound and multimedia
HDMI to CSI-2 via TC358743 on kernel 4.1
Post Reply

Search this topic…

696 posts
Page 28 of 28
1
…
24
25
26
27
28
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Thu Jun 11, 2020 9:29 am

cpetku wrote: ↑
Wed Jun 10, 2020 8:48 pm
I know this is an old thread, but the issue described in 2016 is still relevant.

Was there ever a workaround when using the CSI input and video formats such as
480p/576p whereby the width of the image is not divisible by 32? The only possible
solution I have found in this thread would appear to be to change the width to 1440
then attempt to scale the resultant image back to its native format for display on
the HDMI Output of the PI.

My focus is to use the PI to control a TI HDMI/LVDS bridge (like samsonx) as a

method to prove out all functions of the TI Bridge. I have created a custom HAT for
the PI using the UH940 and verified functionality at 1920x1080@25 and 720P. However
I can't demonstrate the lower resolutions due to what I believe has been stated as
a Hardware limitation of the GPU (e.g., fixed stride length). Can this be confirmed
(HW limitation) or is it a driver issue that requires me to recompile the kernel?
Don't get confused between stride (sometimes called pitch), and active image width.

Stride MUST be a multiple of 16 bytes for the CSI2 receiver, and 32 bytes for the
ISP input. Hardware restriction.

The active image within that buffer can be almost any width you like, although
subsampled YUV formats such as YUV 4:2:2 and 4:2:0 get a bit odd if it's not an
even number of pixels.

V4L2 allows you to specify the stride via the bytesperline field of the format, vs
the width in width.
MMAL allows you to specify the stride via the width field, with the active width
being crop.width.

720x576 would need bytesperline set to 736 if using V4L2 and V4L2_PIX_FMT_YUV420.
(bcm2835-unicam would at one point allow you to select 720 as it only wants a
multiple of 16 bytes, but that's been increased to 32 to match the ISP and avoid a
world of pain in having to set it manually).

Within MMAL you normally use the template

Code: Select all

output->format->es->video.crop.width = WIDTH;
output->format->es->video.crop.height = HEIGHT;
output->format->es->video.width = VCOS_ALIGN_UP(WIDTH, 32);
output->format->es->video.height = HEIGHT;
(Some components require an alignment of 16 on the height as well, but the ISP
doesn't).
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.
cpetku
Posts: 2
Joined: Sun Apr 19, 2020 11:45 am
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Thu Jun 11, 2020 2:42 pm

Thank you for the reply (and the support you've previously given to the community).

The issue I'm struggling with is the 720 wide formats requiring 732 bytes. I
believe your answer is this is a Firmware limitation imposed in the CSI interface
to make sure the resultant image can be processed by the ISP which has a Hardware
limitation. I'm fine with that answer assuming I am stating it correctly since the
final product will be based upon a different embedded microprocessor.

My focus is simply to define a method to demonstrate functionality of the TI

chipset I have selected for a product since TI does not provide or recommend any
specific platform for this purpose. The Raspberry PI is a flexible/low-cost
platform with great community support even for someone who was not exposed to MMAL
until a couple of months ago. Pages 5-12(?) of this thread were sufficient to
persuade me to develop around the PI as a test platform for this project.

I am using a Quantum Data 760B pattern generator to provide various video formats
to the DS90UH929 and receiving them as BGR24 encoding on the CSI bus of the linked
DS90UH940. Like others, I had to get around the x 32 multiple by setting my width
to 1440 to avoid screen tearing when using 720x480/576 wide video formats . In the
case of 720x480(P) or 720x576(P) I crop the image to 720x 240/288 and resize (via
ISP) to the native format. This is quite lossy but allows demonstrating 480P/576P
connectivity of the TI DS90UH929.

An interesting note is when testing with 480i/576i, the video appears to be

reported by the TI chipset as 1440 x 240/288 and resizing to 720x480/576 using the
ISP results in the correct image which so far appears lossless.

My only other issue has been related to ALSA under-runs occasionally locking up the
sound system when changing video formats, but that will deserve it's own thread...
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Thu Jun 11, 2020 2:59 pm

cpetku wrote: ↑
Thu Jun 11, 2020 2:42 pm
Thank you for the reply (and the support you've previously given to the community).

The issue I'm struggling with is the 720 wide formats requiring 732 bytes. I
believe your answer is this is a Firmware limitation imposed in the CSI interface
to make sure the resultant image can be processed by the ISP which has a Hardware
limitation. I'm fine with that answer assuming I am stating it correctly since the
final product will be based upon a different embedded microprocessor.

My focus is simply to define a method to demonstrate functionality of the TI

chipset I have selected for a product since TI does not provide or recommend any
specific platform for this purpose. The Raspberry PI is a flexible/low-cost
platform with great community support even for someone who was not exposed to MMAL
until a couple of months ago. Pages 5-12(?) of this thread were sufficient to
persuade me to develop around the PI as a test platform for this project.

I am using a Quantum Data 760B pattern generator to provide various video formats
to the DS90UH929 and receiving them as BGR24 encoding on the CSI bus of the linked
DS90UH940. Like others, I had to get around the x 32 multiple by setting my width
to 1440 to avoid screen tearing when using 720x480/576 wide video formats . In the
case of 720x480(P) or 720x576(P) I crop the image to 720x 240/288 and resize (via
ISP) to the native format. This is quite lossy but allows demonstrating 480P/576P
connectivity of the TI DS90UH929.
In which case you're doing something very wrong. Please start a new thread with
more complete details of how you are using the CSI2 receiver (V4L2 or MMAL), and
what you're attempting to achieve.
Are you processing the frame in software, passing it to some other subsystem (ie
codec), or throwing it in the bin?
cpetku wrote:
An interesting note is when testing with 480i/576i, the video appears to be
reported by the TI chipset as 1440 x 240/288 and resizing to 720x480/576 using the
ISP results in the correct image which so far appears lossless.

My only other issue has been related to ALSA under-runs occasionally locking up the
sound system when changing video formats, but that will deserve it's own thread...
Seeing as this thread is entitled "HDMI to CSI-2 via TC358743 on kernel 4.1",
discussion of ay other chip ought to be on another thread.

Interlaced video is a funny that isn't handled well by any chip I've encountered.
ADV728x uses the line number in the frame start/end to denote the field.
TC358743 sends the two fields with different CSI data type values.

Either way each field will be 720x240/288. You ought to be deinterlacing two fields
to convert to a progressive frame.
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.
User837489239
Posts: 8
Joined: Thu Jun 11, 2020 9:21 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Thu Jun 11, 2020 10:00 pm

Hello,

I would like to say that 6by9 made excellent work.

I have a question.
I use Chineese module "HDMI to CSI-2 TC358743 chip". It uses only 2 lanes, so from
what I read in thread it cannot pass 1080P 60Hz RGB24 on CSI, but it can 1080P 30Hz
RGB24.

My HDMI source input need to be 1080P 60Hz RGB24, but there are only 2 lanes. Is it
possible to configure, that HDMI input will be "1080P 60Hz RGB24", but through CSI
it will be passed only "1080P 30Hz RGB24" (so half frames will be skipped)?
If I set 30Hz using "v4l2-ctl --set-dv-bt-timings", while hdmi input is 60Hz, then
frames looks "overlapped", there are parts of different frames in one frame, which
is obvious. Is there way to do this? So that Toshiba chip will accept 60Hz hdmi
input, but will pass through CSI 30Hz.

Thank you.
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Fri Jun 12, 2020 7:58 am

User837489239 wrote: ↑
Thu Jun 11, 2020 10:00 pm
I use Chineese module "HDMI to CSI-2 TC358743 chip". It uses only 2 lanes, so from
what I read in thread it cannot pass 1080P 60Hz RGB24 on CSI, but it can 1080P 30Hz
RGB24.

My HDMI source input need to be 1080P 60Hz RGB24, but there are only 2 lanes. Is it
possible to configure, that HDMI input will be "1080P 60Hz RGB24", but through CSI
it will be passed only "1080P 30Hz RGB24" (so half frames will be skipped)?
If I set 30Hz using "v4l2-ctl --set-dv-bt-timings", while hdmi input is 60Hz, then
frames looks "overlapped", there are parts of different frames in one frame, which
is obvious. Is there way to do this? So that Toshiba chip will accept 60Hz hdmi
input, but will pass through CSI 30Hz.
As has been stated multiple times (although I know this is a long thread), no.

To read out at 50% of the speed of the input (in 1080p60, out 1080p30) would
require at least a half frame buffer in the chip. This chip has around a 512 pixel
buffer.
There's a very slim possibility that you could overclock the CSI2 side of the
TC358743 beyond the quoted max of 1Gbit/s/lane, but I doubt it will work. I have a
spreadsheet from Toshiba of the permitted parameters in loads of cases, and at the
moment I can't get it to be happy with 1080p50. We're already running at 972Mbit/s
for 1080p50 YCbCr4:2:2. A linear scaling would say we need 1166Mbit/s for 1080p60,
which just isn't plausible.

Note that the chip will convert RGB on the HDMI side to YCbCr4:2:2 on the CSI side,
so it doesn't matter which your HDMI source is producing. Once in memory, dropping
every other frame is easy.
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.
User837489239
Posts: 8
Joined: Thu Jun 11, 2020 9:21 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Fri Jun 12, 2020 9:21 am

Thank you for your response.

So in order to take HDMI Input 1080p60, and pass through CSI lane only that much it
will get through (1 Gbit/s), (which would result in dropped frames), it would
require overclocking.

By the way, I have noticed that when on hdmi source pixels are RGB(255,255,255)
(white color), then after I receive it through V4l2 driver using BGR24 mode, then
these pixels are RGB(254,254,254). Is it caused by Toshiba chip converting it, to
YCbCr4:2:2 on the middle, as you stated in your post?
Does it look like this:?
Code: Select all

[Toshiba chip] Software using V4L2 driver

HDMI Input (RGB24) -> YCbCr4:2:2 -> BGR24 (who converts from
YCbCr4:2:2 to BGR24?)
My question is, who converts from YCbCr4:2:2 to BGR24 (once I choose BGR24 in V4L2
options)?

Thank you for your time 6by9 Engineer.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Fri Jun 12, 2020 10:10 am

User837489239 wrote: ↑
Fri Jun 12, 2020 9:21 am
So in order to take HDMI Input 1080p60, and pass through CSI lane only that much it
will get through (1 Gbit/s), (which would result in dropped frames), it would
require overclocking.
It would be operating outside the specified parameters, and may not be possible.
And you have zero chance of receiving 1080p60 RGB over the CSI2 link - that would
be clocking things at twice their specified max speed.
User837489239 wrote:
By the way, I have noticed that when on hdmi source pixels are RGB(255,255,255)
(white color), then after I receive it through V4l2 driver using BGR24 mode, then
these pixels are RGB(254,254,254). Is it caused by Toshiba chip converting it, to
YCbCr4:2:2 on the middle, as you stated in your post?
Does it look like this:?
Code: Select all

[Toshiba chip] Software using V4L2 driver

HDMI Input (RGB24) -> YCbCr4:2:2 -> BGR24 (who converts from
YCbCr4:2:2 to BGR24?)
My question is, who converts from YCbCr4:2:2 to BGR24 (once I choose BGR24 in V4L2
options)?
There are no conversions on the Pi side as standard.
If you ask the V4L2 driver to produce BGR24 then it asks the TC358743 to output
RGB.
If you ask the V4L2 driver to produce UYVY then it asks the TC358743 to convert to
YCbCr4:2:2.
Conversion matrices where required are pretty much hardcoded inside the chip.

I must admit I did notice something slightly odd in the driver in that it leaves
VOUTCOLORMODE at MASK_VOUTCOLORMODE_AUTO always, when setting it to
MASK_VOUTCOLORMODE_THROUGH would seem more appropriate. Minor detail though.

You do have the funny with HDMI as to whether it uses full or limited range
signalling, and that potentially could result in rounding errors.
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.
User837489239
Posts: 8
Joined: Thu Jun 11, 2020 9:21 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Fri Jun 12, 2020 10:49 am

If my HDMI to CSI-2 module would have 22 PIN connector, and used 4 lanes. Then I
would need Raspberry PI Zero, right? (it looks that only this version of Raspberry
has 22 PIN connector)
Would Raspberry Pi zero, handle RGB 1080P60 to memory buffer? I don't need to
output them on hdmi, nor encode, just process (not heavy, almost 0% CPU) some of
frames.
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Fri Jun 12, 2020 10:57 am

User837489239 wrote: ↑
Fri Jun 12, 2020 10:49 am
If my HDMI to CSI-2 module would have 22 PIN connector, and used 4 lanes. Then I
would need Raspberry PI Zero, right? (it looks that only this version of Raspberry
has 22 PIN connector)
Would Raspberry Pi zero, handle RGB 1080P60 to memory buffer? I don't need to
output them on hdmi, nor encode, just process (not heavy, almost 0% CPU) some of
frames.
No, whilst the Pi0 uses the 22pin connector it only wires up 2 data lanes.
If you want 4 lanes then you have to use the compute module.
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.
User837489239
Posts: 8
Joined: Thu Jun 11, 2020 9:21 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Sat Jun 13, 2020 11:41 am

Let's say I have raspberry compute module and hdmi to csi-2 module with 22 pin
connector with 4 lanes.

What will happen if hdmi input is more than 1080p60? For example 1080p144? How
TC358743 chip will handle it? It will drop frames to 60hz, and it will work?

Thanks in advance for answer.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Sat Jun 13, 2020 11:58 am

User837489239 wrote: ↑
Sat Jun 13, 2020 11:41 am
Let's say I have raspberry compute module and hdmi to csi-2 module with 22 pin
connector with 4 lanes.

What will happen if hdmi input is more than 1080p60? For example 1080p144? How
TC358743 chip will handle it? It will drop frames to 60hz, and it will work?
Read the spec sheet for the chip
Feature : HDMI® 1.4 to MIPI® CSI-2℠ 1.01 / HDMI® Video format: Up to FHD (1920 x
1080, 60 fps, 24 bpp)
What would a monitor that stated it supported up to 1080p60 do if you fed it
1080p144?

I've already stated that there is no support for dropping from 1080p60 to 1080p30
as it requires a full frame buffer, so why would it be any different with 1080p144?

There is a TC358840 that does up to 4k30 (which is still a lower data rate at
6.18Gbit/s than 1080p144 at 8Gbit/s), but that requires 2 4lane interfaces, and the
Pi SoC doesn't offer that. There's also no Linux driver for it that I'm aware of.
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.
globalc
Posts: 11
Joined: Sat May 09, 2020 12:34 am
Contact: Website
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Sun Jun 14, 2020 3:24 am
In case someone eyes the H2C-RPI-B01, I also finally got around to solder the 4
wires which were rumoured/expected to provide audio grabbing from the HDMI stream,
that still does not work for me. Maybe I have not properly soldered it, or
connected incorrectly, but there is also one further report that connecting these
did not provide audio grabbing,
https://twitter.com/mzyy94/status/1265179392965177344 (Japanese tweet).
The pin details are at https://fluxcoil.net/hardwarerelated/ra ... dmi_stream.

As many were here aiming at low latency streaming, let me share that
https://github.com/pikvm/ustreamer which I just got aware of provides the lowest
latency with theH2C-RPI-B01 board . Also, it's the first time I got such low
latency with the kernel driver, not using the firmware driver.
User837489239
Posts: 8
Joined: Thu Jun 11, 2020 9:21 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Sun Jun 14, 2020 10:25 pm

Could you explain me one thing? Was searching whole thread but didn't find answer
for it.

When I load EDID provided in this thread (EDID1080P60.txt), I get timings which one
of them is following:
Code: Select all

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:
From all timings its the only one for 1080p60. But it has total width/height
2200x1125. and pixel clock seems to be calculated from total size. 2200 * 1125 * 60
= 148500000 Hz

How this mode is supposed to work? Toshiba chip handles max 1080P60, so 2200x1125
60Hz exceeds it. Or I misunderstood something here?
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Mon Jun 15, 2020 6:39 am

User837489239 wrote: ↑
Sun Jun 14, 2020 10:25 pm
Could you explain me one thing? Was searching whole thread but didn't find answer
for it.

When I load EDID provided in this thread (EDID1080P60.txt), I get timings which one
of them is following:
Code: Select all

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:
From all timings its the only one for 1080p60. But it has total width/height
2200x1125. and pixel clock seems to be calculated from total size. 2200 * 1125 * 60
= 148500000 Hz

How this mode is supposed to work? Toshiba chip handles max 1080P60, so 2200x1125
60Hz exceeds it. Or I misunderstood something here?
The Toshiba chip only needs to process the active pixels, not the blanking ones.
Active width/height is shown as 1920x1080.

All video modes include blanking pixels used as part of the frame synchronisation -
it dates back to when a CRT took time to scan back to the start of the next
line/frame. As described in the DRM/KMS header, you get the front porch, sync
pulse, and back porch in both horizontal and vertical directions.

For 1080p60:
- horizontally the front porch is 88 pixels, sync pulse 44 pixels, and back porch
148 pixels. Add that to the 1920 active pixels and you get 2200 pixels.
- vertically the front porch is 4 lines, sync pulse 5 lines, and back porch 36
lines. Add that to the 1080 active lines and you get 1125 lines.
You'll often find that lower frame rate versions of the same resolution use the
same pixel clock, but increase the horizontal blanking period. eg 1080p50 uses the
same numbers as 1080p60, but with a front porch of 528 pixels. Total size 2640x1125
at 148.5MHz gives 50Hz.

CSI2 also has blanking periods, but they are expressed in a totally different way.

And there is absolutely no point in loading EDID1080p60.txt if you don't have a

B102 or other device with 4 lanes connected - you're telling your HDMI source that
it's fine to produce 1080p60, when there's no way for it to send that data down the
2 lanes.
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.
Lowen_Na
Posts: 4
Joined: Tue May 26, 2020 12:22 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Tue Jun 16, 2020 3:17 am

globalc wrote: ↑
Sun Jun 14, 2020 3:24 am
In case someone eyes the H2C-RPI-B01, I also finally got around to solder the 4
wires which were rumoured/expected to provide audio grabbing from the HDMI stream,
that still does not work for me. Maybe I have not properly soldered it, or
connected incorrectly, but there is also one further report that connecting these
did not provide audio grabbing,
https://twitter.com/mzyy94/status/1265179392965177344 (Japanese tweet).
The pin details are at https://fluxcoil.net/hardwarerelated/ra ... dmi_stream.

As many were here aiming at low latency streaming, let me share that
https://github.com/pikvm/ustreamer which I just got aware of provides the lowest
latency with theH2C-RPI-B01 board . Also, it's the first time I got such low
latency with the kernel driver, not using the firmware driver.
I just tried this and I am getting sub half second latency on a 1080p stream, but
frame rates are not great and even if you use the OMX encoding, CPU usages is 15%
or so on all 4 cores of a Pi 4. Still, better results than I have gotten from many
other set ups.
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Tue Jun 16, 2020 5:20 pm

globalc wrote: ↑
Sun Jun 14, 2020 3:24 am
In case someone eyes the H2C-RPI-B01, I also finally got around to solder the 4
wires which were rumoured/expected to provide audio grabbing from the HDMI stream,
that still does not work for me. Maybe I have not properly soldered it, or
connected incorrectly, but there is also one further report that connecting these
did not provide audio grabbing,
https://twitter.com/mzyy94/status/1265179392965177344 (Japanese tweet).
The pin details are at https://fluxcoil.net/hardwarerelated/ra ... dmi_stream.

As many were here aiming at low latency streaming, let me share that
https://github.com/pikvm/ustreamer which I just got aware of provides the lowest
latency with theH2C-RPI-B01 board . Also, it's the first time I got such low
latency with the kernel driver, not using the firmware driver.
I've just tried and failed to get audio on either a H2C-XCBRPIO or no-brand 18810-1
board, both picked up off eBay for around £30-35 each. Both are capturing video
fine (only testing 720p50, but it proves the point)

I've asked GStreamer to record 20secs of audio, and I get a 3sec wav file. If I ask
it to mux the video too, then it plays the video back at high speed. So it would
appear not to be producing a usable clock signal.

Exactly the same setup with an Auvidea B101 works perfectly.

Putting a logic analyser on the I2S lines and it all looks reasonable in how
they're wiggling. One guess is that they've connected VDDIO2 (which powers those
lines) to 1.8V instead of 3.3V, and therefore the Pi is struggling to see the
signals. I need a scope to confirm that, and I don't have one at home.

Analysing the traces, the clocks are low. OSCK should be at 256fs, so with
fs=48kHz, that's 12.28MHz. I'm seeing 1.71MHz. SCK is around 430kHz.
Comparing to the B101, SCK is at around 3MHz. 48kHz, 2 channels, each 32bits wide =
3.072MHz - close enough for me. My analyser only goes up to 24Msamples/sec, so not
good enough to see 12.28MHz sensibly.

There is some external circuitry around the TC358743 for the audio PLL - it's quite
possible they've messed that up and no one has ever tested it. It also has an
independent power rail, so another potential place for things to be wrong.

Sorry, unless someone can

- find a contact for the manufacturer and get them to check it (I'm prepared to
help them if they make contact)
- or fancies doing a reverse engineer on this board around the audio PLL pins.
then I think these eBay boards are going to be video only.
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.
globalc
Posts: 11
Joined: Sat May 09, 2020 12:34 am
Contact: Website
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Tue Jun 16, 2020 10:10 pm

6by9 wrote: ↑
Tue Jun 16, 2020 5:20 pm
[..]
Sorry, unless someone can
- find a contact for the manufacturer and get them to check it (I'm prepared to
help them if they make contact)
- or fancies doing a reverse engineer on this board around the audio PLL pins.
then I think these eBay boards are going to be video only.
Awesome, thanks. Carrying together my parts of contact with the manufacturer:
- When a Chinese colleague kindly approached them for me via a chat, they said 没测
过音频，但芯片的 audio 部分信号都连接到 2.54 的 header 上了 and 这是原文
- The colleague translated to "He said that they haven't tested audio. but the
signal of the audio part on the chip is connected on the header of 2.54"
- The sense I was making from that, together with the forum: on the 2x5 contact
field, one needs to connect 4 points to the Raspi. But we did not test it.

Anyway, I ordered an adapter for direct HDMI-usb (mentioned here,

https://twitter.com/Ascii211/status/1268631069051453448 ) for playing/testing sound
grabbing.
nema.arpit
Posts: 1
Joined: Fri Jun 19, 2020 10:10 am
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Fri Jun 19, 2020 10:22 am

Can someone confirm if the Auvidea B101 works with pi zero?

As soon as I plug in the B101 using a camera module cable (which came with the
Vilros Pi 0 kit), the pi shuts off/ fails to power on, and some components on the
underside of the B101 heat up.
Lowen_Na
Posts: 4
Joined: Tue May 26, 2020 12:22 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Sun Jun 21, 2020 2:48 am

nema.arpit wrote: ↑
Fri Jun 19, 2020 10:22 am
Can someone confirm if the Auvidea B101 works with pi zero?
As soon as I plug in the B101 using a camera module cable (which came with the
Vilros Pi 0 kit), the pi shuts off/ fails to power on, and some components on the
underside of the B101 heat up.
I don't have the proper ribbon cable to test, but I can confirm that the Auvidea
B102 works with a Pi Zero.
danyex
Posts: 11
Joined: Tue Aug 04, 2020 3:48 pm
Re: HDMI to CSI-2 via TC358743 on kernel 4.1
Quote
Tue Aug 04, 2020 3:56 pm

hello, i hope someone can help me..

i bought the raspberry pi zero wh 1 week ago and also bought this module:
https://www.youtube.com/watch?v=L5qbZPrpPp0 (geekworm HDMI to CSI-2 Module with
Toshiba TC358743XBG chip)

i tried to get this thing to run 5 hours now.. i only ever got an jpg screenshot
from my pc screen, but wasnt able to get a live video feed

i think because i tried to use different things from different sites etc. it should
be better if i just reset my raspberry pi zero and start again..

now i get my first error again.. 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.

could someone please tell me step by step what i should do to make this work? i saw
somewhere, that you have to connect wires? in the video above are no wires
connected.. and many people say that "raspivideo" is not working.. but in the video
it is? i am so confused

thank you very much!

edit:
i can get live video feed now from my pc - but its like 2-3 fps max
6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9181
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
Quote
Wed Aug 05, 2020 7:30 am

danyex wrote: ↑
Tue Aug 04, 2020 3:56 pm
i bought the raspberry pi zero wh 1 week ago and also bought this module:
https://www.youtube.com/watch?v=L5qbZPrpPp0 (geekworm HDMI to CSI-2 Module with
Toshiba TC358743XBG chip)

i tried to get this thing to run 5 hours now.. i only ever got an jpg screenshot
from my pc screen, but wasnt able to get a live video feed

i think because i tried to use different things from different sites etc. it should
be better if i just reset my raspberry pi zero and start again..

now i get my first error again.. 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.

could someone please tell me step by step what i should do to make this work? i saw
somewhere, that you have to connect wires? in the video above are no wires
connected.. and many people say that "raspivideo" is not working.. but in the video
it is? i am so confused
I've made a new sticky with the install instructions.
viewtopic.php?f=38&t=281972
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.
Display posts from previous:
Sort by
Post Reply696 posts
Page 28 of 28
1
…
24
25
26
27
28
Return to “Graphics, sound and multimedia”

Jump to
Board indexAll times are UTCDelete cookies
ABOUT US
About us
Our team
Governance
Safeguarding
Our supporters
Jobs
Contact us
SUPPORT
Help
Documentation
Projects
Training
Downloads
Research
FAQ
SIGN UP TO OUR NEWSLETTER
Your email here
SUBSCRIBE
Like Raspberry Pi on Facebook
Follow Raspberry Pi on Twitter
Check out what we’re having for lunch on Instagram
Subscribe to the Raspberry Pi YouTube channel
RASPBERRY PI FOUNDATION
UK REGISTERED CHARITY 1129409

Accessibility Privacy Cookies Trademark rules and brand guidelines