HDMI to CSI-2 via TC358743 on kernel 4.1

[6by9]

0. Is there a way to edit EDID data and try to force 1080p30 (not 50 or 60) or 720p60? so the device will know that 1080 is simply not possible. It works perfectly with a computer when I set 1080p 25 or 30Gz

Yes. You want to edit the EDID to designate a different native resolution. At a very simplistic level, if taking the EDID I had listed

Code: Select all

00ffffffffffff005262888800888888
1c150103800000780aEE91A3544C9926
0F505400000001010101010101010101
010101010101011d007251d01e206e28
5500c48e2100001e8c0ad08a20e02d10
103e9600138e2100001e000000fc0054
6f73686962612d4832430a20000000FD
003b3d0f2e0f1e0a2020202020200100
020321434e
          841303021211012021223c
3d3e1f
      2309070766030c00300080E300
7F8c0ad08a20e02d10103e9600c48e21
0000188c0ad08a20e02d10103e960013
8e210000188c0aa01451f01600267c43
00138e21000098000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

then the bit separated out is the list of VIC values advertised. See https://en.wikipedia.org/wiki/Extended_ ... _Version_3 for a list of the defined VIC numbers.
The top bit is used to denote the native mode, hence 04 (1280x720@60fps) is defined as native.
Change the "84" to "04", and change the "22" almost at the end of that line to "a2", and you should get a default of 1080P30. (Don't insert the spaces I've done above for clarity).
Use "edid-decode < file.txt" to check the content of the EDID file first before downloading it to confirm your change is valid (ignore checksum errors).

1. Is there a way to capture with same results but without yavta? Meaning right from GStreamer, maybe v4l2src? I seem to be able to run pipeline but can't decode it on the client. There is no need for OMX encoding, yavta already encoded video data with hardware acceleration, right?

v4l2src doesn't subscribe to the resolution change events or set any of the timings, therefore you will have to do those manually. After that then yes v4l2src should be able to capture the raw data fine. You'll then need to convert it to I420, and encode it. yavta is doing all of that for you.

I don't know if it is related but performance downgrades over time, it works perfectly for a few minutes and then getting worse. Still, CPUs are around ~15% and it seems to be enough memory for everything. GPU memory is set to 128

What gets worse? What format are you encoding? BGR3 will be more resource intensive than UYVY.

I have been profiling the encode pipeline and the input of the encoder is maxing out one of the VPU cores when I'm trying to push 1080P60 through it (CM3 with B102). There is an approach I can take which will remove most of that load and push it back into the ISP component, but it's a modest chunk of work that I don't know when I'll get around to doing. 1080P30 should be OK.

2. Is it hard to implement dynamic resolution change in yavta? when I switch from UI to video or back I got the full blue (sometimes black) screen and have to restart everything

Not totally trivial, but plausible.
I've just pushed updates to yavta that detect the SOURCE_CHANGE event as I had it as boilerplate from another project. It still needs to tear everything down, reconfigure it, reallocate the buffers, and then start it all up again. All the code is there, but probably needs restructuring to make it available. You've got all the code so it's there if you want to experiment

[6by9]

Pull request created to get this merged into the main Pi kernel - https://github.com/raspberrypi/linux/pull/2513
Please note that I have changed the branch name in my repo - the old branches will be deleted in a couple of days to avoid confusion.

[ialpert]

Wow, that is an extensive replay! Thank you for getting back so quickly.

The top bit is used to denote the native mode, hence 04 (1280x720@60fps) is defined as native.
Change the "84" to "04", and change the "22" almost at the end of that line to "a2", and you should get a default of 1080P30. (Don't insert the spaces I've done above for clarity).
Use "edid-decode < file.txt" to check the content of the EDID file first before downloading it to confirm your change is valid (ignore checksum errors).

I will try that and get back to you with results!

I have been profiling the encode pipeline and the input of the encoder is maxing out one of the VPU cores when I'm trying to push 1080P60 through it (CM3 with B102).

Any chance you can share branch you are building it from? If it is going to be public i mean.
I have B102 and CM3 and would like to try it -- bought B102 by mistake and then bought CM3 to try it, but as you know it did not work out of the box for me. Same as PRI 3B+ and B101. You mention I need to add device tree and recompile. I'm going to purchase RPI Zero W to get the whole family and try both B102 and B101 there...

What gets worse? What format are you encoding? BGR3 will be more resource intensive than UYVY.

I got no strong preference, just need a video record of what is going on + some screenshots when needed. When I'm running yavta it gives a preview to the display that is connected to RPI. So the image is very responsive and smooth over initial minutes, then after about 10 mins it becomes less smooth, so I just sought yavta is not designed to run for a long period of times and more to experiment with. I tried ffmpeg and GStreamer and decided to experiment with GStreamer more as it looks more performant to me.

All the code is there, but probably needs restructuring to make it available. You've got all the code so it's there if you want to experiment

I wish I could, but I'm just a weak (hardly) user there. Please excuse my English

[6by9]

I have been profiling the encode pipeline and the input of the encoder is maxing out one of the VPU cores when I'm trying to push 1080P60 through it (CM3 with B102).

Any chance you can share branch you are building it from? If it is going to be public i mean.
I have B102 and CM3 and would like to try it -- bought B102 by mistake and then bought CM3 to try it, but as you know it did not work out of the box for me. Same as PRI 3B+ and B101. You mention I need to add device tree and recompile. I'm going to purchase RPI Zero W to get the whole family and try both B102 and B101 there...

If you check out the new branch, then the tc358743-fast overlay has gained a parameter called 4lane, so "dtoverlay=tc358743-fast,4lane=on" on a CM1 or CM3 CAM1 should enable the B102 to use all 4 lanes. Preview works at 1080P60 in either BGR3 or UYVY, but encode is currently the bottleneck even with a significant overclock. Removing the preview helps, but still really only hits about 56fps.
The firmware updates will be released when ready - being closed source it makes little sense to give details of what's happening.

What gets worse? What format are you encoding? BGR3 will be more resource intensive than UYVY.

I got no strong preference, just need a video record of what is going on + some screenshots when needed. When I'm running yavta it gives a preview to the display that is connected to RPI. So the image is very responsive and smooth over initial minutes, then after about 10 mins it becomes less smooth, so I just sought yavta is not designed to run for a long period of times and more to experiment with. I tried ffmpeg and GStreamer and decided to experiment with GStreamer more as it looks more performant to me.

I'd be suspicious that the output from yavta wasn't being consumed in a timely manner. The video encoder has a 2-3MB output FIFO, so that will gradually fill in that case. Yavta itself should keep running at 1080P30 quite happily forever.
Currently neither ffmpeg nor GStreamer have sensible handling for this device, nor nice handling for the format conversion or codecs, hence why yavta is doing so much plumbing. Whilst I have some changes pending for the codec side, I doubt the input side will change, so having something making up a pipeline in the way yavta is doing is likely to give better results.

[ialpert]

The firmware updates will be released when ready - being closed source it makes little sense to give details of what's happening.

I just meant that modified Linux device tree for CM3, not firmware itself. I got a fork of your branch merged with RPI 4.14 so I will try to rebuild it on CM3 and check that 4 lanes param.

Just need to build own bcm2710-rpi-cm3.dtb and add some params about B102?

Currently neither ffmpeg nor GStreamer have sensible handling for this device, nor nice handling for the format conversion or codecs, hence why yavta is doing so much plumbing. Whilst I have some changes pending for the codec side, I doubt the input side will change, so having something making up a pipeline in the way yavta is doing is likely to give better results.

One option I was going to try is to push output from yavta over the network to desktop and do all the processing there, but I guess it will be too much traffic? especially for WIFI on RPI3


With modified 1080 it stuck as follows:

Code: Select all

We're encoding to -
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (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)(0x1135fb0)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: 0Created 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
'd(�+@<��<H��(�\�

Perhaps Framerate is 60 is something not possible for that setup.

But on a bright side, for modified 720 it gets what I asked for, device thinks that 720 is the best of abilities and it works automatically.

Thank you again for all your hard work!

[6by9]

One option I was going to try is to push output from yavta over the network to desktop and do all the processing there, but I guess it will be too much traffic? especially for WIFI on RPI3

Yavta will be spitting out H264 encoded data, so should be fine for sending over Wifi. Your GStreamer pipe is doing very little to the data itself. Annoyingly it does lose all timestamping information, although that is really only relevant if you're storing in a container.

With modified 1080 it stuck as follows:

Code: Select all

We're encoding to -
Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (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)(0x1135fb0)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: 0Created 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
'd(�+@<��<H��(�\�

Perhaps Framerate is 60 is something not possible for that setup.

But on a bright side, for modified 720 it gets what I asked for, device thinks that 720 is the best of abilities and it works automatically.

1080P60 is well above the specified codec capabilities, but you should be able to render it to the screen. Try without the -E parameter and it should display OK. 1080P60 will fail on anything other than a CM1/3 as it needs 3 CSI2 lanes, even with the higher link frequency.

As I said, I am looking at a tweak to the ISP component that will reduce the VPU loading and may allow encoding 1080P60 - we'll just have to wait and see how it falls out as there may well be other bottlenecks in there.

The simplest tests I'm doing are with a Pi as the source, as it is then trivial to use

Code: Select all

tvservice -e "CEA <mode> HDMI"

to switch between HDMI modes. Please do test with any sources you can - there are a couple that I think may have issues, though it is generally the esoteric ones, or very low resolutions.

[ialpert]

1080P60 is well above the specified codec capabilities, but you should be able to render it to the screen. Try without the -E parameter and it should display OK. 1080P60 will fail on anything other than a CM1/3 as it needs 3 CSI2 lanes, even with the higher link frequency.

WIthout -E I sometimes got a blank screen, sometimes it is some image but very disordered like Hz are wrong. Wanted to try it on CM3, pulled updates from your branch but still has that error I mentioned before...

Code: Select all

 tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed

I saw you added some configs to CM3 so thought it should work now.


Can you please take a quick look at setup to confirm that is how it should be?


Thank you

[6by9]

1080P60 is well above the specified codec capabilities, but you should be able to render it to the screen. Try without the -E parameter and it should display OK. 1080P60 will fail on anything other than a CM1/3 as it needs 3 CSI2 lanes, even with the higher link frequency.

WIthout -E I sometimes got a blank screen, sometimes it is some image but very disordered like Hz are wrong. Wanted to try it on CM3, pulled updates from your branch but still has that error I mentioned before...

Code: Select all

 tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed

I saw you added some configs to CM3 so thought it should work now.


Can you please take a quick look at setup to confirm that is how it should be?


Thank you

CD1_SDA and SCL need to go to GPIOs 28&29, not 0&1.
There's some magic in the device tree of my new branch that will expose GPIOs 0&1 as i2c-0, and GPIOs 28&29 as i2c-4, with the kernel controlling the pinmuxing to switch between the two as required. If using i2cdetect you therefore need to use -y 4. The same is true for the normal Pi variants - i2c-0 is GPIOs 0&1 on the 40pin header, and i2c-4 is the camera and display connectors.

[ialpert]

I tried again with re-attached SDA and SDL as you suggested (Whatever is on 2 and 3 stays there?)




GPIO LED on another side of B102 is off, while on RPI3 it is GREEN after running gpio remapping script


i2cdetect -y 4

Code: Select all

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- UU
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

vcgencmd get_camera

Code: Select all

supported=1 detected=0

Freshly build yavta and userland

./yavta --capture=1000 -n 3 -f UYVY -m -T /dev/video0

Code: Select all

Device /dev/video0 opened.
Device `unicam' on `platform:unicam 3f801000.csi1' (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
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
Unable to get frame rate: Inappropriate ioctl for device (25).
vc.ril.isp:in:0(UYVY)(0x125efb0)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: 0Created pool of length 3, size 0
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 3133440 for encode/render
3 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x72616000.
Importing DMABUF 6 into VCSM...
...done. vcsm_handle 1122304
Exported buffer 0 to dmabuf 6, vcsm handle 1122304
Linking V4L2 buffer index 0 ptr 0x1264ed0 to MMAL header 0x1263070. mmal->data 0xC0000002
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x7221a000.
Importing DMABUF 7 into VCSM...
...done. vcsm_handle 1126400
Exported buffer 1 to dmabuf 7, vcsm handle 1126400
Linking V4L2 buffer index 1 ptr 0x1264f40 to MMAL header 0x1263248. mmal->data 0xC0000003
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x71e1e000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 1130496
Exported buffer 2 to dmabuf 8, vcsm handle 1130496
Linking V4L2 buffer index 2 ptr 0x1264fb0 to MMAL header 0x1263420. mmal->data 0xC0000004
select timeout

dmesg

Code: Select all

[ 2266.573291] tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed
[ 2266.573688] tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed
[ 2267.613307] tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed
[ 2267.613702] tc358743 4-000f: i2c_rd: reading register 0x14 from 0xf failed

I tried with Ubuntu/Dell and couple of other devices I have

[6by9]

Ignore "vcgencmd get_camera" - it has zero relevance (alongside raspivid etc).
The LED is just wired to one of the GPIO lines that normally control the power to the camera module, as detailed in https://auvidea.com/download/manual/B10 ... ce_1.4.pdf page 6. The V4L2 driver doesn't bother to waggle that GPIO, so the LED won't change state. Connect CAM1_IO1 to 3V3 and you'll see the LED come on.

Identify where the I2C issue is before going any further. Remove the "dtoverlay=tc358743" line. Reboot. Use i2cdetect to find the board responding on 0F. You appear to have exactly the same wiring as I do for all lines that are actually useful, so it should respond on i2c-4.

[ialpert]

It works!

I did clean up for the system, and I almost positive to blame leftovers of uv4l, especially init script that does GPIO remapping just like i2_camera.sh

As you suggested I removed overlay and got 0F on 4, then tried tc358743 that was asking like usual PRI3 and finally put dtoverlay=tc358743-fast,4lane=on back to get clear 1080 image. WIthout EDID it just crashes, but otherwise works perfectly with and without encoding.

Dave, there are 2 questions left that bother me if you have some time:

1. How did you manage to do reset procedure without using any of 8 pins for rev4, and only with 22 pin camera wire?
It seems to work fine after you restart yavta any number of times, not only once.

2. Will yavta be the official way to use TC358743 with Raspberry after your branch got merged?
Or there will be some instructions how to deal with /dev/video0 directly or userland apps?


Thank you so much for your help again! I check your new version of yavta that reports a change of the source.

[6by9]

1. How did you manage to do reset procedure without using any of 8 pins for rev4, and only with 22 pin camera wire?
It seems to work fine after you restart yavta any number of times, not only once.

The firmware and raspi_tc358743 have no presence between runs, so they fully reinitialise the chip every time. Something in there is wrong.
The kernel is persistent, therefore the init process gets done once, EDIDs don't have to downloaded every time, and generally life is easier.

2. Will yavta be the official way to use TC358743 with Raspberry after your branch got merged?
Or there will be some instructions how to deal with /dev/video0 directly or userland apps?

V4L2 is the official mechanism. yavta (Yet Another V4L2 Test App) is purely an example of that, and I've extended it to do the useful bits for TC358743.

GStreamer and ffmpeg should work if you've preloaded the EDID and set the timings, however they don't have an easy hardware accelerated conversion from UYVY or BGR3 to something more useful. I suspect that yavta is likely to be the only way to get close to 1080P50/60 purely as it is specific to the Pi and can use the mechanisms to avoid copying the data around the place too much.

Just to say the required wiring may change for the CM/CM3 as we're discussing how to provide sensible configurations to get to the camera without breaking existing configs. Some notes will be forthcoming, but please remember that the B101/102 are NOT RPT products, therefore full support really ought to come from them (unlikely to happen).

[ialpert]

B101/102 are NOT RPT products, therefore full support really ought to come from them (unlikely to happen).

About a month ago I filed a ticket with the company I bought B101 and B102 that B101 is not working as expected with Raspberi Pi3+, at least not "just works out of the box" as explained in https://auvidea.com/download/manual/B10 ... ce_1.4.pdf

the B101 is indeed compatible with the Raspberry Pi 3 B+ and should work without a problem.

It is possible that the customer is using a different operating system on his Raspberry, since the driver for the B101 is integrated in the official Raspbian or _NOOBS (New Out Of the Box Software)_ version that can be downloaded right from the raspberrypi.org homepage.

For the included wires you need to configure one of the Raspberry_s GPIO pins to be used as a reset, instructions on this can be found on page 4 of our technical reference manual (also applies to rev 4). The pinout for the Raspberry_s GPIOs can be found on lots of different sites: Raspberry Pi 3 GPIO

Thanks to 6by9 I feel a bit more educated now and I'm glad it works at least in some way.

[thehack904]

Afternoon,

There has been some serious work done in this thread. Thank you. I have read through this thread fully, several times. I am still having trouble with my B101 v.4 with RPi 3. It does not appear to be working. When I run raspivid -t 0, it seems to be querying the board because on my mac's it detects the new output as the toshiba monitor and then only allows up to 720 recommend. The first time I used it as the input for B101 it did give me the 1080 option, but has not since I updated with all new firmware. I have used two different mac's that act as input that are capable of 1080, another RPi 3 and Polaroid iD642 (Capable of 720 only). No video window pops up when I use raspivid -t 0, but my mac acts like another screen is now hooked up. I have run through all the steps I could find in this thread and compiled 6by9's code multiple times without any change. I have also tried to follow along samsonx's posts as well, but no change.

I have also run through https://www.linux-projects.org/uv4l/installation/ steps as well without any success. When I run uv4l --driver raspicam --auto-video_nr --width 640 --height 480 --encoding jpeg it notes that /dev/video0 is already in use and creates /dev/video1. But when I use dd if=/dev/video0 of=snapshot.jpeg bs=11M count=1 (on /dev/video0 or /dev/video1) no joy. It gives me a blank file.

I am at a loss and have been hitting my head against google for a week now in case I missed something. Any help would be greatly appreciated.

[ialpert]

Afternoon,

There has been some serious work done in this thread. Thank you. I have read through this thread fully, several times. I am still having trouble with my B101 v.4 with RPi 3. It does not appear to be working. When I run raspivid -t 0, it seems to be querying the board because on my mac's it detects the new output as the toshiba monitor and then only allows up to 720 recommend. The first time I used it as the input for B101 it did give me the 1080 option, but has not since I updated with all new firmware. I have used two different mac's that act as input that are capable of 1080, another RPi 3 and Polaroid iD642 (Capable of 720 only). No video window pops up when I use raspivid -t 0, but my mac acts like another screen is now hooked up. I have run through all the steps I could find in this thread and compiled 6by9's code multiple times without any change. I have also tried to follow along samsonx's posts as well, but no change.

I have also run through https://www.linux-projects.org/uv4l/installation/ steps as well without any success. When I run uv4l --driver raspicam --auto-video_nr --width 640 --height 480 --encoding jpeg it notes that /dev/video0 is already in use and creates /dev/video1. But when I use dd if=/dev/video0 of=snapshot.jpeg bs=11M count=1 (on /dev/video0 or /dev/video1) no joy. It gives me a blank file.

I am at a loss and have been hitting my head against google for a week now in case I missed something. Any help would be greatly appreciated.

UV4L worked great with another card I used https://lintestsystems.com/products/picapture-hd1 but that device has an issue with computer graphics (text) (I have B101, B102, and that HD1)

With B101 you can compile kernel and driver from this PR https://github.com/raspberrypi/linux/pull/2513 right on the device if you have RPI3 (not 3B+ but that might be also working by now) then use yavta app for preview and H264 output. I have not found any good steps to use FFmpeg or GStreamer with acceptable performance, only through yavta modified by 6by9 -- https://github.com/6by9/yavta

This steps helped me a lot: https://gist.github.com/maditnerd/01195 ... 1682f1727b

Also, EDID is an important step, but having Mac as input is more flexible than TV (I work with Roku) using http://displaymenu.milchimgemuesefach.de/ or analogs

[carlosgambato]

Hello,
I have a Raspberry Pi3 B+ with Raspbian Stretch with desktop kernel 4.14 and I bought a B101 rev 1.4 Auvidea board.
I installed your UV4L software and the drivers for B101 using this procedure that I found on your site:
https://www.linux-projects.org/uv4l/installation/
but it doesn't work: the software don't see the board (but the board is ok because I tested it).
I would like to know if the driver that I found on your site are compatible with Raspbian Stretch and Raspberry Pi3 B+ and, in this case, how could I solve this problem.
Thank you
Carlo

[RpiName]

I would like to know if the driver that I found on your site are compatible with Raspbian Stretch and Raspberry Pi3 B+ and, in this case, how could I solve this problem.

it should work. Exactly follow the instructions reported there.

[carlosgambato]

I tried, to install on the raspberry 3B and everything works, but on the 3B + the driver seems not to work

[ialpert]

I had issues with both 3 and 3B+ but would like to gjve it another try. Can you please share summary of the steps you performed on RPI 3?

Thanks!

[realies]

Has anyone attempted 1080P60 on 4 lanes yet?

[ialpert]

I tried 4 lanes with compute module 3 and driver by 6by9. Works great at 1080p60

[realies]

I tried 4 lanes with compute module 3 and driver by 6by9. Works great at 1080p60

Is this HDMI passthrough or coding h.264 at double the speed the encoder is rated for?

[ialpert]

Check the thread above, i did some experimenting with gstreamer (ffmpeg was ugly slow) its h264 raw from yavta (MMAL wrapper) that is (only?) hardware accelerated option with good perfeomance.

my idea was to stream/store video to cloud from CM/RPi. either way i faced low performance for encoding or too much data for wifi to handle. gstreamer over cable was ok but i did not invest more time there yet

[natxo]

Hello

I want to use raspi_tc358743 on a rpi3 b

cloned and compiled this
https://github.com/6by9/raspi_tc358743

put this line on config.txt i2c_vc=on

but im getting errors and no video.....

What im doing wrong? should i put another values on config.txt?

thank you

[jwpalermo]

Hi all,

I've been reading through this thread and I'm feeling out of my depth. I would greatly appreciate if someone could confirm or correct my understanding.

I'm trying to use the RPi 3 B with Auvidea B101 to get pictures or video from a security camera. I have several different security cameras to work with ranging from 720p@30fps to 1080p@30fps. My current understanding is that I need to 1) install 6By9's tc358743 drivers and then 2) use yavta to capture frames.

For 1) I intend to use: https://gist.github.com/maditnerd/01195 ... 1682f1727b

For 2) I expect that if I clone yavta (https://github.com/6by9/yavta), then capturing video can be done by running the command in the readme (./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0)

What about EDID? Will I have to set an EDID for 1080p@30fps? Is there anything else you would suggest to me?

Thanks!