jwpalermo
Posts: 12
Joined: Fri Jun 15, 2018 1:58 am

Using TC358743 on the Auvidea B101 with RPi 3b

Sat Jul 14, 2018 7:18 pm

I'm trying to use an RPi 3b with the Auvidea B101 to take in HDMI output from a security camera. The security camera produces [email protected] and I'm feeding its analog output through a TVI to HDMI converter to produce HDMI. All I really want to do is take images from it on command, so video streaming is more than I need.

Note that 6By9 has merged driver changes into the RPi kernel which provides support for the TC358743. See the end of this thread (currently page 17) for details: viewtopic.php?f=38&t=120702&start=400

I'm trying to use 6By9's changes.

1) I updated my kernel and updated the config.txt with dtoverlay=tc358743.

2) I update the EDID with: v4l2-ctl --set-edid=file=1080P30EDID.txt --fix-edid-checksums

Note that this is 1080P30EDID.txt:

00ffffffffffff005262888800888888
1c150103800000780aEE91A3544C9926
0F505400000001010101010101010101
010101010101011d007251d01e206e28
5500c48e2100001e8c0ad08a20e02d10
103e9600138e2100001e000000fc0054
6f73686962612d4832430a20000000FD
003b3d0f2e0f1e0a2020202020200100
020321434e041303021211012021a23c
3d3e1f2309070766030c00300080E300
7F8c0ad08a20e02d10103e9600c48e21
0000188c0ad08a20e02d10103e960013
8e210000188c0aa01451f01600267c43
00138e21000098000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000

Note also that I edited it with a regular text editor. Not sure if this is ok.

3) Note that v4l2-ctl --query-dv-timings produces output that doesn't look good:

VIDIOC_QUERY_DV_TIMINGS: failed: Link has been severed
Active width: 0
Active height: 0
Total width: 0
Total height: 0
Frame format: progressive
Polarities: -vsync -hsync
Pixelclock: 0 Hz
Horizontal frontporch: 0
Horizontal sync: 0
Horizontal backporch: 0
Vertical frontporch: 0
Vertical sync: 0
Vertical backporch: 0
Standards:
Flags:

I'm not sure if this is a problem.

4) I cloned and built yavta: https://github.com/6by9/yavta

5) I tried to capture video with:

./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0

it produces a lot of output:

We're encoding to file.h264
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) 640x480 (stride 1280) field none buffer size 614400
Video format: UYVY (59565955) 640x480 (stride 1280) field none buffer size 614400
Unable to get frame rate: Inappropriate ioctl for device (25).
vc.ril.isp:in:0(UYVY)(0x160ffb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 640, height: 480, (0,0,640,480) pixel aspect ratio: 0/0, frame rate: 0/0 buffers num: 3(opt 1, min 1), size: 614400(opt 614400, min: 614400), 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 460800 for encode/render
Writing data to file.h264
Create pool of 8 buffers of size 262144
Sent buffer 0x161a158Sent buffer 0x161a330Sent buffer 0x161a508Sent buffer 0x161a6e0Sent buffer 0x161a8b8Sent buffer 0x161aa90Sent buffer 0x161ac68Sent buffer 0x161ae403 buffers requested.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x72553000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 73728
Exported buffer 0 to dmabuf 8, vcsm handle 73728
Linking V4L2 buffer index 0 ptr 0x161bb58 to MMAL header 0x16164c0. mmal->data 0xC0000003
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x7236a000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 77824
Exported buffer 1 to dmabuf 9, vcsm handle 77824
Linking V4L2 buffer index 1 ptr 0x161bbc8 to MMAL header 0x1616698. mmal->data 0xC0000004
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x722d4000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 81920
Exported buffer 2 to dmabuf 10, vcsm handle 81920
Linking V4L2 buffer index 2 ptr 0x161bc38 to MMAL header 0x1616870. mmal->data 0xC0000005
select timeout

The file.h264 only has 27 bytes, so clearly it didn't work. One notable question that comes to mind is why the video format is set to 640x480. I suppose this is default for yavta? I also tried setting -s 1920x1080, but the output seemed the same.

I would appreciate any debugging help! Thanks!

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Sun Jul 15, 2018 8:37 am

27 bytes are the header bytes of the H264 stream. Those get generated based on resolution, colour space, and a few other parameters before the first frame is required.
The output resolution is driven almost solely by the DV_TIMINGS settings. You can't ask for a resolution other than the one set via the timings. The only parameters you should be able to change are the bytesperline and pixelformat (RGB3 or UYVY).

Editing the EDID in a text editor is fine. I would use the edid-decode app (in the Raspbian repos, or https://git.linuxtv.org/edid-decode.git/) to validate that your EDID describes what you think it does.
It sounds like the source isn't finding a mode that it likes. Try it with the 1080P50 EDID first and see what it detects/selects. yavta will get you nowhere until you solve getting the timings detected correctly.

It may be worth picking up a cheap HDMI splitter so that you can see whether the camera is producing a sensible output when feeding the B101. I picked one up on eBay for around £10.
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.

jwpalermo
Posts: 12
Joined: Fri Jun 15, 2018 1:58 am

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Mon Jul 16, 2018 12:06 am

@6By9 Thanks for your reply.

I confirmed that the output of my camera is sensible by plugging it into a monitor. @6By9 is this what you meant for me to test? I'm assuming that you recommended an HDMI splitter because it would make it more convenient to test this (i.e. have the RPi output and camera output available simultaneously without swapping cables), but that the HDMI splitter is not strictly necessary.

Using edid-decode I found the following differences between the decoded 1080P30 and 1080P50 edid files:

Code: Select all

diff decoding_1080P30.txt decoding_1080P50.txt 
50c50
<     VIC   4 [email protected] 16:9  HorFreq: 45000 Hz Clock: 74.250 MHz
---
>     VIC   4 [email protected] 16:9 (native) HorFreq: 45000 Hz Clock: 74.250 MHz
59c59
<     VIC  34 [email protected] 16:9 (native) HorFreq: 33750 Hz Clock: 74.250 MHz
---
>     VIC  34 [email protected] 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
Given that the decoded 1080P30 file says: "[email protected] 16:9 (native)", I suppose it looks right, but this is the first EDID decoding I've ever looked at so I'm not sure.

Upon setting the 1080P30EDID.txt file, I get the following output:

Code: Select all

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

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

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

Upon inspecting the dv-timings I see:

Code: Select all

        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148500000 Hz ()
        Horizontal frontporch: 0
        Horizontal sync: 280
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 45
        Vertical backporch: 0
        Standards: 
        Flags: 

Not sure why it says "60.00 frames per second"...

Then when I try the previous yavta command I see:

Code: Select all

We're encoding to file.h264
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)(0x2aafb0)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
Writing data to file.h264
Create pool of 8 buffers of size 262144
Sent buffer 0x2b5158Sent buffer 0x2b5330Sent buffer 0x2b5508Sent buffer 0x2b56e0Sent buffer 0x2b58b8Sent buffer 0x2b5a90Sent buffer 0x2b5c68Sent buffer 0x2b5e40Unable to request buffers: Cannot allocate memory (12).

I wonder if it's because the frame rate is set at 60fps? Then again, I'm not sure why that would be since I set the EDID to have a native 30FPS (unless I'm misunderstanding the EDID).

I would appreciate any help! Thanks

For reference, here's the EDID decoding for 1080P30EDID.txt:

Code: Select all

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   52 62 88 88 00 88 88 88 1c 15
version:         01 03
basic params:    80 00 00 78 0a
chroma info:     ee 91 a3 54 4c 99 26 0f 50 54
established:     00 00 00
standard:        01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:    01 1d 00 72 51 d0 1e 20 6e 28 55 00 c4 8e 21 00 00 1e
descriptor 2:    8c 0a d0 8a 20 e0 2d 10 10 3e 96 00 13 8e 21 00 00 1e
descriptor 3:    00 00 00 fc 00 54 6f 73 68 69 62 61 2d 48 32 43 0a 20
descriptor 4:    00 00 00 fd 00 3b 3d 0f 2e 0f 1e 0a 20 20 20 20 20 20
extensions:      01
checksum:        00

EDID version: 1.3
Manufacturer: TSB Model 8888 Serial Number 2290649088
Made in week 28 of 2011
Digital display
Image size is variable
Gamma: 2.20
RGB color display
First detailed timing is preferred timing
Display x,y Chromaticity:
  Red:   0.6396, 0.3300
  Green: 0.2998, 0.5996
  Blue:  0.1503, 0.0595
  White: 0.3125, 0.3291
Established timings supported:
Standard timings supported:
Detailed mode: Clock 74.250 MHz, 708 mm x 398 mm
               1280 1390 1430 1650 hborder 0
                720  725  730  750 vborder 0
               +hsync +vsync 
               VertFreq: 60 Hz, HorFreq: 45000 Hz
Detailed mode: Clock 27.000 MHz, 531 mm x 398 mm
                720  736  798  858 hborder 0
                480  489  495  525 vborder 0
               +hsync +vsync 
               VertFreq: 59 Hz, HorFreq: 31468 Hz
Monitor name: Toshiba-H2C
Monitor ranges (invalid): 59-61Hz V, 15-46kHz H, max dotclock 150MHz
Has 1 extension blocks
Checksum: 0x0 (should be 0x4f)

CTA extension block
Extension version: 3
29 bytes of CTA data
  Video data block
    VIC   4 [email protected] 16:9  HorFreq: 45000 Hz Clock: 74.250 MHz
    VIC  19 [email protected] 16:9  HorFreq: 37500 Hz Clock: 74.250 MHz
    VIC   3 [email protected] 16:9  HorFreq: 31469 Hz Clock: 27.000 MHz
    VIC   2 [email protected] 4:3  HorFreq: 31469 Hz Clock: 27.000 MHz
    VIC  18 [email protected] 16:9  HorFreq: 31250 Hz Clock: 27.000 MHz
    VIC  17 [email protected] 4:3  HorFreq: 31250 Hz Clock: 27.000 MHz
    VIC   1 [email protected] 4:3  HorFreq: 31469 Hz Clock: 25.175 MHz
    VIC  32 [email protected] 16:9  HorFreq: 27000 Hz Clock: 74.250 MHz
    VIC  33 [email protected] 16:9  HorFreq: 28125 Hz Clock: 74.250 MHz
    VIC  34 [email protected] 16:9 (native) HorFreq: 33750 Hz Clock: 74.250 MHz
    VIC  60 [email protected] 16:9  HorFreq: 18000 Hz Clock: 59.400 MHz
    VIC  61 [email protected] 16:9  HorFreq: 18750 Hz Clock: 74.250 MHz
    VIC  62 [email protected] 16:9  HorFreq: 22500 Hz Clock: 74.250 MHz
    VIC  31 [email protected] 16:9  HorFreq: 56250 Hz Clock: 148.500 MHz
  Audio data block
    Linear PCM, max channels 2
      Supported sample rates (kHz): 48 44.1 32
      Supported sample sizes (bits): 24 20 16
  Vendor-specific data block, OUI 000c03 (HDMI)
    Source physical address 3.0.0.0
    Supports_AI
  Extended tag: Video capability data block
    YCbCr quantization: No Data (0)
    RGB quantization: Selectable (via AVI Q) (1)
    PT scan behaviour: Support both over- and underscan (3)
    IT scan behaviour: Support both over- and underscan (3)
    CE scan behaviour: Support both over- and underscan (3)
Basic audio support
3 native detailed modes
Detailed mode: Clock 27.000 MHz, 708 mm x 398 mm
                720  736  798  858 hborder 0
                480  489  495  525 vborder 0
               -hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 31468 Hz
Detailed mode: Clock 27.000 MHz, 531 mm x 398 mm
                720  736  798  858 hborder 0
                480  489  495  525 vborder 0
               -hsync -vsync 
               VertFreq: 59 Hz, HorFreq: 31468 Hz
Detailed mode: Clock 27.000 MHz, 531 mm x 398 mm
               1440 1478 1602 1716 hborder 0
                240  244  247  262 vborder 0
               -hsync -vsync interlaced 
               VertFreq: 60 Hz, HorFreq: 15734 Hz
Checksum: 0x0 (should be 0x28)

EDID block does not conform at all!
	Block has broken checksum
	Detailed blocks filled with garbage
	Range descriptor contains garbage
CTA extension block does not conform
	Block has broken checksum

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Mon Jul 16, 2018 1:32 pm

jwpalermo wrote:
Mon Jul 16, 2018 12:06 am
@6By9 Thanks for your reply.

I confirmed that the output of my camera is sensible by plugging it into a monitor. @6By9 is this what you meant for me to test? I'm assuming that you recommended an HDMI splitter because it would make it more convenient to test this (i.e. have the RPi output and camera output available simultaneously without swapping cables), but that the HDMI splitter is not strictly necessary.
No.
The splitter should merge the EDIDs from the monitor and B101 and put out a combined EDID. You can therefore verify that the source is putting something sensible out.
HDMI has a hotplug line, and when that is asserted it will reread the EDID of the new device and choose a mode based on that, so when plugged in to your monitor the source may choose something totally different to the B101.
jwpalermo wrote:Using edid-decode I found the following differences between the decoded 1080P30 and 1080P50 edid files:

Code: Select all

diff decoding_1080P30.txt decoding_1080P50.txt 
50c50
<     VIC   4 [email protected] 16:9  HorFreq: 45000 Hz Clock: 74.250 MHz
---
>     VIC   4 [email protected] 16:9 (native) HorFreq: 45000 Hz Clock: 74.250 MHz
59c59
<     VIC  34 [email protected] 16:9 (native) HorFreq: 33750 Hz Clock: 74.250 MHz
---
>     VIC  34 [email protected] 16:9  HorFreq: 33750 Hz Clock: 74.250 MHz
Given that the decoded 1080P30 file says: "[email protected] 16:9 (native)", I suppose it looks right, but this is the first EDID decoding I've ever looked at so I'm not sure.

Upon setting the 1080P30EDID.txt file, I get the following output:

Code: Select all

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

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

CEA-861 Video Capability Descriptor
  RGB Quantization Range:  yes
  YCC Quantization Range:  no
  PT:                      Supports both over- and underscan
  IT:                      Supports both over- and underscan
  CE:                      Supports both over- and underscan
Yes, it's pretty much the same for all EDID files if you're only changing the supported resolutions.
jwpalermo wrote:Upon inspecting the dv-timings I see:

Code: Select all

        Active width: 1920
        Active height: 1080
        Total width: 2200
        Total height: 1125
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 148500000 Hz ()
        Horizontal frontporch: 0
        Horizontal sync: 280
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 45
        Vertical backporch: 0
        Standards: 
        Flags: 

Not sure why it says "60.00 frames per second"...
Somethings been clipped off your quote then, as I only see "Pixelclock: 148500000 Hz ()".
The numbers sound right for 1080P60 though.
jwpalermo wrote:Then when I try the previous yavta command I see:

Code: Select all

We're encoding to file.h264
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)(0x2aafb0)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
Writing data to file.h264
Create pool of 8 buffers of size 262144
Sent buffer 0x2b5158Sent buffer 0x2b5330Sent buffer 0x2b5508Sent buffer 0x2b56e0Sent buffer 0x2b58b8Sent buffer 0x2b5a90Sent buffer 0x2b5c68Sent buffer 0x2b5e40Unable to request buffers: Cannot allocate memory (12).
I wonder if it's because the frame rate is set at 60fps? Then again, I'm not sure why that would be since I set the EDID to have a native 30FPS (unless I'm misunderstanding the EDID).
1080P60 won't work except on a CM/CM3 with 4 lanes. The data rate is too high for the 2 lanes of CSI2 avaiable on a standard Pi.

Ah, I may have missed a bit in my instructions. The video buffers are allocated from a special memory area called CMA (Contiguous Memory Allocator). You need to edit /boot/cmdline.txt to add/edit "cma=32M" to increase the allocation from the default 8MB.
cmdline.txt must remain as one line - anything on a second line will be ignored.
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.

jwpalermo
Posts: 12
Joined: Fri Jun 15, 2018 1:58 am

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Tue Jul 17, 2018 1:13 am

@6By9 Thanks for you help.

So by HDMI splitter you must mean a 1-in multi-out device. For some reason I thought you meant a multi-in 1-out (which I understand now is an HDMI switcher, not an HDMI splitter)... Ok I'll feed the camera output into the HDMI splitter, then feed the 2 outputs from the splitter into my monitor and the B101. Just ordered the splitter.

The cutoff part of dv-timings showed:

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:

I added "cma=32M" to /boot/cmdline.txt, and rebooted.

I tried to set my EDID for 1080P30 again, but I get the same result where it gets set to 60FPS.

When I run the same yavta command, it ran for quite awhile longer and seems to produce more output, but as I expected given your comment about the problem with 60FPS, it doesn't work:

Code: Select all

h264 -f UYVY -m -T /dev/video0
We're encoding to file.h264
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) 640x480 (stride 1280) field none buffer size 614400
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)(0x18c7fb0)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
Writing data to file.h264
Create pool of 8 buffers of size 262144
Sent buffer 0x18d2158Sent buffer 0x18d2330Sent buffer 0x18d2508Sent buffer 0x18d26e0Sent buffer 0x18d28b8Sent buffer 0x18d2a90Sent buffer 0x18d2c68Sent buffer 0x18d2e403 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x70a04000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 73728
Exported buffer 0 to dmabuf 8, vcsm handle 73728
Linking V4L2 buffer index 0 ptr 0x18d3b58 to MMAL header 0x18ce4c0. mmal->data 0xC0000003
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70608000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 77824
Exported buffer 1 to dmabuf 9, vcsm handle 77824
Linking V4L2 buffer index 1 ptr 0x18d3bc8 to MMAL header 0x18ce698. mmal->data 0xC0000004
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7020c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 81920
Exported buffer 2 to dmabuf 10, vcsm handle 81920
Linking V4L2 buffer index 2 ptr 0x18d3c38 to MMAL header 0x18ce870. mmal->data 0xC0000005
Unable to start streaming: Invalid argument (22).
Releasing vcsm handle 73728
Closing dma_buf 8
Releasing vcsm handle 77824
Closing dma_buf 9
Releasing vcsm handle 81920
Closing dma_buf 10
3 buffers released.
@6By9 How do you suppose I can lower the FPS settings? That would seem to be the key here.

Your help is much appreciated.

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Tue Jul 17, 2018 9:19 am

HDMI splitter eg https://www.ebay.co.uk/itm/2160p-1-IN-2 ... 2496109965 or many similar ones on eBay. The one I have is an older version which only does 1080P and is powered from a USB socket. Not that it matters here, but they often don't support ARC or CEC.
Splitting an HDMI stream is actually fairly involved, particularly if HDCP (copy protection) is involved. The keys are per device, so the stream has to be decrypted, split, and re-encrypted.

Code: Select all

Unable to start streaming: Invalid argument (22).
That's the error I was expecting. If you check in dmesg then I'd expect the message

Code: Select all

Device has requested 3 data lanes, which is >2 configured in DT
Choosing a mode is totally down to the source. You can try hacking out all the extra EDID modes leaving only 1080P30 to reduce the choices it has, or there may be menu options to select the mode.
There is nothing compelling the source to choose any particular mode, except the expectation that should the EDID not advertise it then the sink may not be able to cope with it. As an example, on a Pi you can use "tvservice -e " to choose any mode you fancy irrespective of the EDID.

Your original post said the camera produced 1080P30. How had you determined that? It seems strange that if it is only 1080P30 that the DVI output is 1080P60, unless the camera is separated from the receiver/display via eg ethernet.

You could test the rig out using a Pi as the source where you can set the modes explicitly, and it will also abide by the EDID (It doesn't hot plug therefore the B101 must be setup with the EDID before you boot the Pi acting as a source).
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.

jwpalermo
Posts: 12
Joined: Fri Jun 15, 2018 1:58 am

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Sat Jul 21, 2018 4:28 pm

@6by9 - I just realized why my source is reading [email protected] While my camera is [email protected], it's feeding into a TVI to HDMI converter which is outputting at [email protected]

Given that this is the situation, is it possible to still get this setup to run with an RPi3? You noted in a previous post that: "1080P60 won't work except on a CM/CM3 with 4 lanes. The data rate is too high for the 2 lanes of CSI2 avaiable on a standard Pi." However, while it isn't possible to take in 60FPS, could the TC358743 sample at a lower rate from a 60FPS source? Truth be told, all I really want to do is take pictures with this camera. If I could get even 0.1 FPS, that would be great.

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Sun Jul 22, 2018 7:48 am

Not possible.
The chip has a 512 pixel fifo to cover differences in hdmi and csi data rates.
At 1080p60 you have pixels coming in at 148.5MHz. At 16bpp yuv422 that's 2.37Gbps, hence over the 2Gbps that 2 lanes can carry. (3.56Gbps if running 24bpp rgb)
There is no way to arrange a 512 pixel fifo to store enough of the image to handle such a mismatch in data rates and give a full frame. I guess you could drop every other line, but I don't believe you'll be able to convince the chip to so 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.

jwpalermo
Posts: 12
Joined: Fri Jun 15, 2018 1:58 am

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Sun Jul 22, 2018 12:32 pm

I see. Thanks for the direct answer. What about 720P at 60FPS? That should be possible right?

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Sun Jul 22, 2018 12:56 pm

720p60 uyvy should work. Rgb will still take it over the 1944Maps limit of the csi2 setup.
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.

ahmed mosad
Posts: 16
Joined: Sun Jun 03, 2018 10:41 pm

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Thu Aug 16, 2018 5:32 am

hi my friend i can't to run the b101
please this are the steps i followed :
1- i burned this image : 2018-04-18-raspbian-stretch.img
2- i added "cma=32M" to boot/config.txt
3-

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
cma=32M
dtparam=audio=on
start_x=1
gpu_mem=128
enable_uart=1
dtoverlay=w1-gpio


4- i updated the raspberry pi using this commands

Code: Select all

sudo apt-get update
sudo apt-get upgrade
sudo rpi-update
5- after the updating its my kernel :

Code: Select all

Linux raspberrypi 4.14.61-v7+ #1133 SMP Fri Aug 10 11:04:43 BST 2018 armv7l GNU/Linux
6-then i added this lines to boot/config.txt

Code: Select all

dtoverlay=tc358743
dtoverlay=tc358743-audio
7-so the final boot/gonfig.txt

Code: Select all

# For more options and information see
# http://rpf.io/configtxt
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on

# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
cma=32M
dtparam=audio=on
start_x=1
gpu_mem=128
dtoverlay=tc358743
enable_uart=1
dtoverlay=w1-gpio
dtoverlay=tc358743-audio
8-after running raspivid -t 0
i recieved this message
Image


9-its my hardware connections
Image

10-now its my raspberry pi 3 connection the HDMI input : Xbox 360 the HDMI output: TV
Image


please help me

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

Re: Using TC358743 on the Auvidea B101 with RPi 3b

Thu Aug 16, 2018 9:42 am

ahmed mosad wrote:
Thu Aug 16, 2018 5:32 am
hi my friend i can't to run the b101
Please don't double post - viewtopic.php?f=38&t=120702&start=400#p1353508
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.

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: No registered users and 3 guests