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

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

Thu Nov 09, 2017 1:37 pm

madnerd wrote:
Thu Nov 09, 2017 12:25 pm
I added cma=128M to /boot/cmdline
Tried ffmpeg again and got errors in dmesg

Code: Select all

[video4linux2,v4l2 @ 0x1c7d230] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device
[video4linux2,v4l2 @ 0x1c7d230] Time per frame unknown
It is inappropriate, but should also be non-fatal.
VIDIOC_[G|S]_PARM are for camera modules and similar where userspace dictates the frame rate.
VIDIOC_[G|S]_STD are applicable for analogue capture devices where you say you want NTSC or PAL (or the flavours therein). (Also VIDIOC_QUERYSTD to get the detected input).
VIDIOC_[G|S]_DV_TIMINGS are applicable for HDMI type capture devices where you specify the full timings for the incoming image (also VIDIOC_QUERY_DV_TIMINGS to read the detected values)
madnerd wrote:

Code: Select all

[  216.319375] unicam 3f801000.csi1: dma_alloc_coherent of size 4177920 failed
I added cma=256M to /boot/cmdline
ffmpeg still doesn't works, but i've got no errors in dmesg
Strange. Check the first couple of lines of dmesg. You should have something like

Code: Select all

[    0.000000] cma: Reserved 128 MiB at 0x26c00000
If not, then look at the output of "cat /proc/cmdline", which should be similar to:

Code: Select all

bcm2708_fb.fbwidth=1824 bcm2708_fb.fbheight=984 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3dc00000 vc_mem.mem_size=0x3f000000  cma=128M dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/nfs nfsroot=192.168.x.x:/nfs/pi2 rw ip=dhcp rootwait elevator=deadline
Note that the cma=128M is present there.
There is a way to get the dtoverlay to set up the required CMA size, but that's probably not helpful as it is an absolute size rather than an increment.

Oh, /boot/cmdline.txt has to be one single line. Did you add it on a new line?
madnerd wrote:I tried to compile yavta but got an error

Code: Select all

 undefined reference to `vcsm_import_dmabuf'
I manage to compile it by putting this variable to MMAL_FALSE but I'm pretty sure it won't work without this.

Code: Select all

#define VCSM_IMPORT_DMABUF MMAL_FALSE
When I start yavta, it just freezes and no data is written in file.h264

Code: Select all

vc.ril.isp:in:0(UYVY)(0x1ac2fb0)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 3133440 for encode/render
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 8 buffers of size 262144
Sent buffer 0x1acd158Sent buffer 0x1acd330Sent buffer 0x1acd508Sent buffer 0x1acd6e0Sent buffer 0x1acd8b8Sent buffer 0x1acda90Sent buffer 0x1acdc68Sent buffer 0x1acde403 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x71204000.
Linking V4L2 buffer index 0 ptr 0x1acea70 to MMAL header 0x1ac94c0. mmal->data 0x71204000
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70e08000.
Linking V4L2 buffer index 1 ptr 0x1aceae0 to MMAL header 0x1ac9698. mmal->data 0x70E08000
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x70a0c000.
Linking V4L2 buffer index 2 ptr 0x1aceb50 to MMAL header 0x1ac9870. mmal->data 0x70A0C000
I must confess to not having tested the VCSM_IMPORT_DMABUF MMAL_FALSE path recently :( I've limited enthusiasm for ressurecting it without a very good reason, so probably ought to remove it.

To get the required vcsm functionality, clone and rebuild the latest userland repo ("git clone https://github.com/raspberrypi/userland.git", "cd userland", "./buildme". It'll need cmake and build-essentials). You'll also need the firmware to be from 8th Sept or later. The kernel branch you're building from already has the required kernel changes.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
madnerd
Posts: 10
Joined: Wed Nov 01, 2017 6:43 am
Location: Montpellier, France
Contact: Website Twitter

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

Thu Nov 09, 2017 10:58 pm

:D It works!

I put my scripts and screenshots on github.
https://github.com/maditnerd/tc358743

I cloned and built userland and I was able to compile yatva.

Code: Select all

 
 v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums 
 ./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0 
The camera worked, but the image had weird artefacts. :o

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
Framerate is 50
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x73efb0)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 3133440 for encode/render
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 8 buffers of size 262144
Sent buffer 0x749158Sent buffer 0x749330Sent buffer 0x749508Sent buffer 0x7496e0Sent buffer 0x7498b8Sent buffer 0x749a90Sent buffer 0x749c68Sent buffer 0x749e403 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x71104000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 811008
Exported buffer 0 to dmabuf 8, vcsm handle 811008
Linking V4L2 buffer index 0 ptr 0x74aa70 to MMAL header 0x7454c0. mmal->data 0xC000000C
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70d08000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 815104
Exported buffer 1 to dmabuf 9, vcsm handle 815104
Linking V4L2 buffer index 1 ptr 0x74aae0 to MMAL header 0x745698. mmal->data 0xC000000D
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7090c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 819200
Exported buffer 2 to dmabuf 10, vcsm handle 819200
Linking V4L2 buffer index 2 ptr 0x74ab50 to MMAL header 0x745870. mmal->data 0xC000000E
DROPPED FRAME - 113739 and 153737, delta 39998
DROPPED FRAME - 233736 and 273735, delta 39999
DROPPED FRAME - 333734 and 373733, delta 39999
DROPPED FRAME - 413734 and 453731, delta 39997
DROPPED FRAME - 493733 and 533730, delta 39997

Since the EDID seems to setup the recording, i decided to check it using EDID Editor
* In CEA/Video, I removed all entry and add 1920x1080p 25hz.
* I also changed H.Active Pixels and V Active Lines in VESA/DB1
https://github.com/maditnerd/tc358743/b ... stEDID.txt
I was pretty sure, it wouldn't works but, it turns out , yatva worked perfectly. :D

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
Framerate is 25
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x1cc2fb0)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 3133440 for encode/render
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 8 buffers of size 262144
Sent buffer 0x1ccd158Sent buffer 0x1ccd330Sent buffer 0x1ccd508Sent buffer 0x1ccd6e0Sent buffer 0x1ccd8b8Sent buffer 0x1ccda90Sent buffer 0x1ccdc68Sent buffer 0x1ccde403 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x71104000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 892928
Exported buffer 0 to dmabuf 8, vcsm handle 892928
Linking V4L2 buffer index 0 ptr 0x1ccea70 to MMAL header 0x1cc94c0. mmal->data 0xC000000C
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70d08000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 897024
Exported buffer 1 to dmabuf 9, vcsm handle 897024
Linking V4L2 buffer index 1 ptr 0x1cceae0 to MMAL header 0x1cc9698. mmal->data 0xC000000D
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7090c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 901120
Exported buffer 2 to dmabuf 10, vcsm handle 901120
Linking V4L2 buffer index 2 ptr 0x1cceb50 to MMAL header 0x1cc9870. mmal->data 0xC000000F
But I still didn't manage to use ffmpeg, I probably didn't use the correct arguments. :(
I'm trying to have an mp4 file at the end, as I want to be able to display it directly after the video was recorded.

Code: Select all

ffmpeg -y -f v4l2 -loglevel verbose -r 25 -i /dev/video0 -t 00:10:00 /home/pi/test/test.mp4

Code: Select all

[video4linux2,v4l2 @ 0x3815230] fd:3 capabilities:85200001 [video4linux2,v4l2 @ 0x3815230] Querying the device for the current frame size [video4linux2,v4l2 @ 0x3815230] Setting frame size to 1920x1080 [video4linux2,v4l2 @ 0x3815230] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device [video4linux2,v4l2 @ 0x3815230] Time per frame unknown [video4linux2,v4l2 @ 0x3815230] Dequeued v4l2 buffer contains 4177920 bytes, but 4147200 were expected. Flags: 0x00002001.
Input #0, video4linux2,v4l2, from '/dev/video0':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080 (0x0), 1000k tbr, 1000k tbn, 1000k tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help [video4linux2,v4l2 @ 0x3815230] Dequeued v4l2 buffer contains 4177920 bytes, but 4147200 were expected. Flags: 0x00002001.
/dev/video0: Invalid data found when processing input
No more output streams to write to, finishing.
Finishing stream 0:0 without any data written to it.
[graph 0 input from stream 0:0 @ 0x381a890] w:1920 h:1080 pixfmt:uyvy422 tb:1/25 fr:25/1 sar:0/1 sws_param:flags=2 [auto_scaler_0 @ 0x381bc00] w:iw h:ih flags:'bicubic' interl:0 [format @ 0x3819150] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format' [auto_scaler_0 @ 0x381bc00] w:1920 h:1080 fmt:uyvy422 sar:0/1 -> w:1920 h:1080 fmt:yuv422p sar:0/1 flags:0x4 [libx264 @ 0x3818120] using cpu capabilities: ARMv6 NEON [libx264 @ 0x3818120] profile High 4:2:2, level 4.0, 4:2:2 8-bit [libx264 @ 0x3818120] 264 - core 152 r2851 ba24899 - H.264/MPEG-4 AVC codec - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to '/u/test.mp4':
Metadata:
encoder         : Lavf58.1.100
Stream #0:0: Video: h264 (libx264), 1 reference frame (avc1 / 0x31637661), yuv422p, 1920x1080, q=-1--1, 25 fps, 12800 tbn, 25 tbc
Metadata:
encoder         : Lavc58.1.100 libx264
Side data:       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1 frame=    0 fps=0.0 q=0.0 Lsize=       0kB time=00:00:00.00 bitrate=N/A speed=   0x video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Input file #0 (/dev/video0):
Input stream #0:0 (video): 0 packets read (0 bytes); 0 frames decoded;
Total: 0 packets (0 bytes) demuxed
Output file #0 (/u/test.mp4):
Output stream #0:0 (video): 0 frames encoded; 0 packets muxed (0 bytes);
Total: 0 packets (0 bytes) muxed 

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

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

Fri Nov 10, 2017 11:18 am

madnerd wrote:
Thu Nov 09, 2017 10:58 pm
:D It works!
Good news
madnerd wrote:I put my scripts and screenshots on github.
https://github.com/maditnerd/tc358743

I cloned and built userland and I was able to compile yatva.

Code: Select all

 
 v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums 
 ./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0 
The camera worked, but the image had weird artefacts. :o
I've just been around that loop myself - it's a balancing act. I pushed an update to my kernel branch yesterday which I hope avoids it, but I haven't tested every combination.
You've got data coming in off the HDMI at 1 rate, and data going out to the Pi at either 972Mbit/s or 2x972 = 1944Mbit/s. The TC358743 has a FIFO internally to allow matching of those rates, and a trigger value is programmed in to the registers to say when it is safe to start reading out. It has a range of 0 to 511 pixels.

If the HDMI data rate is significantly slower than the CSI2 data rate then the FIFO trigger has to be set relatively high to avoid a FIFO underflow. Conversely if the HDMI data rate (ignoring blanking) is higher than the CSI2 rate then the FIFO can underflow.

The Linux driver has one fixed value that it programs into the register - https://github.com/6by9/linux/blob/unic ... 43.c#L1786. In the standard kernel it is set at 16, which means that very few modes work (1080P60 UYVY on 4 lanes, and 720P60 UYVY on 2 lanes). There has been discussion over this on the linux-media mailing list, and sadly no one has a relationship with Toshiba that allows them to release the formula for dynamically calculating the FIFO value. Various organisations have a spreadsheet from Toshiba, but all under NDAs :(

I did have 400 in there as that gave a small safety margin over the value required to get 1080p24, 25, and 30 to work, but that causes 1080P50 to go the other way and overflow. I've amended the patch to use 374 which seems to be good with all of those.
madnerd wrote:Since the EDID seems to setup the recording, i decided to check it using EDID Editor
The EDID tells the source what modes are supported by the sink. It's then up to the source to choose something appropriate.
You've done better than me in finding an EDID editor - I'd looked hard, found nothing, so was editing it by hand! Then again I was looking for a Linux app.
madnerd wrote:* In CEA/Video, I removed all entry and add 1920x1080p 25hz.
* I also changed H.Active Pixels and V Active Lines in VESA/DB1
https://github.com/maditnerd/tc358743/b ... stEDID.txt
I was pretty sure, it wouldn't works but, it turns out , yatva worked perfectly. :D
My modified version of yavta is set up to just adopt whatever mode it finds the V4L2 subsystem has detected, so should work in almost all cases.
madnerd wrote:But I still didn't manage to use ffmpeg, I probably didn't use the correct arguments. :(
I'm trying to have an mp4 file at the end, as I want to be able to display it directly after the video was recorded.

Code: Select all

ffmpeg -y -f v4l2 -loglevel verbose -r 25 -i /dev/video0 -t 00:10:00 /home/pi/test/test.mp4

Code: Select all

[video4linux2,v4l2 @ 0x3815230] fd:3 capabilities:85200001 [video4linux2,v4l2 @ 0x3815230] Querying the device for the current frame size [video4linux2,v4l2 @ 0x3815230] Setting frame size to 1920x1080 [video4linux2,v4l2 @ 0x3815230] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device [video4linux2,v4l2 @ 0x3815230] Time per frame unknown [video4linux2,v4l2 @ 0x3815230] Dequeued v4l2 buffer contains 4177920 bytes, but 4147200 were expected. Flags: 0x00002001.
Input #0, video4linux2,v4l2, from '/dev/video0':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080 (0x0), 1000k tbr, 1000k tbn, 1000k tbc
Stream mapping:
Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help [video4linux2,v4l2 @ 0x3815230] Dequeued v4l2 buffer contains 4177920 bytes, but 4147200 were expected. Flags: 0x00002001.
I think that line is the key, and was a subject that got discussed during the review of the driver.
Most of the other sections of the VideoCore hardware expect images to be padded to a stride (number of bytes per line) being a multiple of typically 32 bytes, and the height to be padded to a multiple of 16 lines. V4L2 allows you to set up the stride with these requirements, but not the height. From the review comments it was proposed that setting imagesize to be large enough for this padding was acceptable, but it looks like ffmpeg is stricter.
"Dequeued v4l2 buffer contains 4177920 (1920*1088*2) bytes, but 4147200 (1920*1080*2) were expected. Flags: 0x00002001."
IIRC This came up with GStreamer too as the standard V4L2 driver does a similar thing.
It's the check at https://github.com/FFmpeg/FFmpeg/blob/m ... 4l2.c#L536 that is failing, and it is then discarding the buffer.

Code: Select all

        if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
            av_log(ctx, AV_LOG_ERROR,
                   "Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n",
                   buf.bytesused, s->frame_size, buf.flags);
            enqueue_buffer(s, &buf);
            return AVERROR_INVALIDDATA;
        }
}
Either try 720P as 720 is a multiple of 16, or recompile ffmpeg with "buf.bytesused < s->frame_size" instead.
I need to send this patch set to the mailing list anyway, so I will query whether this really is allowed within the V4L2 API. It does seem that various client apps make the assumption that the bytesused will be the same as the buffer size.

Hmm, you've made me look now. I think if we amend the size at https://github.com/6by9/linux/blob/unic ... cam.c#L936 to read something like:

Code: Select all

	size = vb2_plane_size(vb, 0);
	if (size < dev->v_fmt.fmt.pix.sizeimage) {
		unicam_err(dev, "data will not fit into plane (%lu < %lu)\n",
			   vb2_plane_size(vb, 0), size);
		return -EINVAL;
	}

vb2_set_plane_payload(&buf->vb.vb2_buf, 0, size);
then the buffer that is allocated is big enough, but the number of bytes reported as used in each buffer is correct and should make things happy. I'll give it a go in a moment and see what I get.
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.

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

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

Fri Nov 10, 2017 1:28 pm

So the diff

Code: Select all

--- a/drivers/media/platform/bcm2835/bcm2835-unicam.c
+++ b/drivers/media/platform/bcm2835/bcm2835-unicam.c
@@ -933,7 +933,7 @@ static int unicam_buffer_prepare(struct vb2_buffer *vb)
        if (WARN_ON(!dev->fmt))
                return -EINVAL;
 
-       size = dev->v_fmt.fmt.pix.sizeimage;
+       size = dev->v_fmt.fmt.pix.bytesperline * dev->v_fmt.fmt.pix.height;
        if (vb2_plane_size(vb, 0) < size) {
                unicam_err(dev, "data will not fit into plane (%lu < %lu)\n",
                           vb2_plane_size(vb, 0), size);
makes ffmpeg happy, but ffmpeg itself is trying to encode on the CPU at least with the standard build of ffmpeg from Stretch. I'm on a Pi2 and it is managing about 0.9fps.

Code: Select all

pi@raspberrypi:~/yavta $ ffmpeg -y -f v4l2 -loglevel verbose -r 25 -i /dev/video0 -t 00:10:00 /home/pi/test.mp4
ffmpeg version 3.2.8-1~deb9u1 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --prefix=/usr --extra-version='1~deb9u1' --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libavresample   3.  1.  0 /  3.  1.  0
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
[video4linux2,v4l2 @ 0x1cd75c0] fd:3 capabilities:85200001
[video4linux2,v4l2 @ 0x1cd75c0] Querying the device for the current frame size
[video4linux2,v4l2 @ 0x1cd75c0] Setting frame size to 1920x1080
[video4linux2,v4l2 @ 0x1cd75c0] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device
[video4linux2,v4l2 @ 0x1cd75c0] Time per frame unknown
[video4linux2,v4l2 @ 0x1cd75c0] Stream #0: not enough frames to estimate rate; consider increasing probesize
Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, start: 4705.023181, bitrate: N/A
    Stream #0:0: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080, 1000k tbr, 1000k tbn, 1000k tbc
[graph 0 input from stream 0:0 @ 0x1ce3600] w:1920 h:1080 pixfmt:uyvy422 tb:1/25 fr:25/1 sar:0/1 sws_param:flags=2
[auto-inserted scaler 0 @ 0x1ce4260] w:iw h:ih flags:'bicubic' interl:0
[format @ 0x1ce41f0] auto-inserting filter 'auto-inserted scaler 0' between the filter 'Parsed_null_0' and the filter 'format'
[graph 0 input from stream 0:0 @ 0x1ce3600] TB:0.040000 FRAME_RATE:25.000000 SAMPLE_RATE:nan
[auto-inserted scaler 0 @ 0x1ce4260] w:1920 h:1080 fmt:uyvy422 sar:0/1 -> w:1920 h:1080 fmt:yuv422p sar:0/1 flags:0x4
No pixel format specified, yuv422p for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264 @ 0x1cda880] using cpu capabilities: ARMv6 NEON
[libx264 @ 0x1cda880] profile High 4:2:2, level 4.0, 4:2:2 8-bit
[libx264 @ 0x1cda880] 264 - core 148 r2748 97eaef2 - H.264/MPEG-4 AVC codec - Copyleft 2003-2016 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=6 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
Output #0, mp4, to '/home/pi/test.mp4':
  Metadata:
    encoder         : Lavf57.56.101
    Stream #0:0: Video: h264 (libx264), 1 reference frame ([33][0][0][0] / 0x0021), yuv422p, 1920x1080, q=-1--1, 25 fps, 12800 tbn, 25 tbc
    Metadata:
      encoder         : Lavc57.64.101 libx264
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> h264 (libx264))
Press [q] to stop, [?] for help
frame=  476 fps=0.9 q=-1.0 Lsize=   26370kB time=00:00:18.92 bitrate=11417.8kbits/s speed=0.0372x        
video:26365kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.020317%
Input file #0 (/dev/video0):
  Input stream #0:0 (video): 476 packets read (1974067200 bytes); 476 frames decoded; 
  Total: 476 packets (1974067200 bytes) demuxed
Output file #0 (/home/pi/test.mp4):
  Output stream #0:0 (video): 476 frames encoded; 476 packets muxed (26997756 bytes); 
  Total: 476 packets (26997756 bytes) muxed
[libx264 @ 0x1cda880] frame I:93    Avg QP:21.62  size:160668
[libx264 @ 0x1cda880] frame P:224   Avg QP:25.16  size: 42393
[libx264 @ 0x1cda880] frame B:159   Avg QP:26.35  size: 16094
[libx264 @ 0x1cda880] consecutive B-frames: 48.3% 15.5% 17.6% 18.5%
[libx264 @ 0x1cda880] mb I  I16..4: 10.2% 74.4% 15.4%
[libx264 @ 0x1cda880] mb P  I16..4:  6.5% 30.2%  3.5%  P16..4: 16.8%  4.3%  1.8%  0.0%  0.0%    skip:36.9%
[libx264 @ 0x1cda880] mb B  I16..4:  1.1%  4.7%  0.6%  B16..8: 20.2%  3.9%  0.7%  direct: 3.1%  skip:65.7%  L0:50.9% L1:44.3% BI: 4.8%
[libx264 @ 0x1cda880] 8x8 transform intra:74.7% inter:81.9%
[libx264 @ 0x1cda880] coded y,uvDC,uvAC intra: 63.3% 80.1% 38.1% inter: 11.5% 16.2% 0.6%
[libx264 @ 0x1cda880] i16 v,h,dc,p: 19% 27%  5% 49%
[libx264 @ 0x1cda880] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 17% 14%  6%  8%  9%  8%  8%  8%
[libx264 @ 0x1cda880] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 23% 16% 11%  7% 10% 10%  8%  8%  6%
[libx264 @ 0x1cda880] i8c dc,h,v,p: 44% 21% 24% 11%
[libx264 @ 0x1cda880] Weighted P-Frames: Y:3.6% UV:2.7%
[libx264 @ 0x1cda880] ref P L0: 65.3% 16.5% 14.3%  3.8%  0.0%
[libx264 @ 0x1cda880] ref B L0: 87.5% 10.7%  1.8%
[libx264 @ 0x1cda880] ref B L1: 97.0%  3.0%
[libx264 @ 0x1cda880] kb/s:11343.31
pi@raspberrypi:~/yavta $ 
I'll sort out the patch for the mailing list and ask the question then.
It feels like it is ffmpeg being too stringent in the checks it is doing, but I don't know if that is the correct interpretation. They accept bytesused being less than length quite happily for any compressed formats.
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.

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

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

Fri Nov 10, 2017 3:12 pm

I'm now recompiling ffmpeg with the --enable-omx-rpi flag set for hardware accelerated encoding, and will see how it performs with that. I suspect it will still struggle as it'll be doing a conversion from UYVY to YUV420P on the CPU, and whilst that isn't a taxing operation it is still a fair number of pixels to thrown around.
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.

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

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

Fri Nov 10, 2017 5:38 pm

So having rebuilt with

Code: Select all

git clone https://git.ffmpeg.org/ffmpeg.git
./configure --enable-mmal --enable-omx-rpi
make -j3
and waiting a fair while for it to compile (I know I could have disabled some of the CPU based codecs),

Code: Select all

./ffmpeg -y -f v4l2 -loglevel verbose -i /dev/video0 -r 60 -vcodec h264_omx -b:v 10000000  /home/pi/test.mp4
when fed a VGA60 input claims to manage about 48fps, but is dropping/duplicating a lot of frames.
Fed 1080P30 and it claims to achieve about 2 fps, but again duplicates frames.

TBH I don't think ffmpeg will be that performant because it can't offload that format conversion.
Further updates to yavta allow you to specify "-" as the target filename to use stdout and therefore supporting piping the data. It's horrid, and you do lose the timestamp information (so dropped frames and framerate are not conveyed correctly), but it does work:

Code: Select all

./yavta -f UYVY --capture=3000 -n 3 --encode-to=- -m -T /dev/video0 | ../ffmpeg/ffmpeg -i - -r 30 -vcodec copy file.mp4
(I've built ffmpeg locally but not installed it, hence the path to ffmpeg).

The better solution is to integrate ffmpeg/libavformat into the app. It's something I've been meaning to do for ages with raspivid, but there's the confusion as to whether libavcodec or ffmpeg is being shipped in various releases of Debian, and they have incompatible APIs (they forked).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
madnerd
Posts: 10
Joined: Wed Nov 01, 2017 6:43 am
Location: Montpellier, France
Contact: Website Twitter

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

Wed Nov 15, 2017 11:08 am

I applied the diff , recompiled the kernel and updated yavta.
I confirm ffmpeg is not really usable , even with omx_h264.

So I tried using yavta with ffmpeg, and noticed I have dropped frames.
I lost 3/5 seconds when I record a 5-minute video.

So I tried yavta alone, and realized I had dropped frames.

Code: Select all

DROPPED FRAME - 336031232 and 336511219, delta 479987
bytesused in buffer is 4147200
When frames dropped I noticed increased use of the CPU (I use rCPU to monitor cpu usage)
Image

I used my EDID file, to do this test.
I tried again 1080p50.txt but I had a lot more dropped frames and green lines artefact.

testEDID.txt

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) 640x480 (stride 1280) field none buffer size 614400
Framerate is 50
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x11cdfb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1920, height: 1088, (0,0,1920,1080) pixel aspect ratio: 0/0, frame rate: 0/0 buffers num: 4(opt 1, min 1), size: 4177920(opt 4177920, min: 4177920), align: 0Created pool of length 4, size 0
Enable encoder....
Create pool of 3 buffers of size 3133440 for encode/render
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 8 buffers of size 262144
Sent buffer 0x11d8478Sent buffer 0x11d8650Sent buffer 0x11d8828Sent buffer 0x11d8a00Sent buffer 0x11d8bd8Sent buffer 0x11d8db0Sent buffer 0x11d8f88Sent buffer 0x11d91604 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x71104000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 73728
Exported buffer 0 to dmabuf 8, vcsm handle 73728
Linking V4L2 buffer index 0 ptr 0x11d9d90 to MMAL header 0x11d44c8. mmal->data 0xC0000003
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70d08000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 77824
Exported buffer 1 to dmabuf 9, vcsm handle 77824
Linking V4L2 buffer index 1 ptr 0x11d9e00 to MMAL header 0x11d46a0. mmal->data 0xC0000004
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7090c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 81920
Exported buffer 2 to dmabuf 10, vcsm handle 81920
Linking V4L2 buffer index 2 ptr 0x11d9e70 to MMAL header 0x11d4878. mmal->data 0xC0000005
length: 4177920 offset: 12533760 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x70510000.
Importing DMABUF 11 into VCSM...
...done. vcsm_handle 86016
Exported buffer 3 to dmabuf 11, vcsm handle 86016
Linking V4L2 buffer index 3 ptr 0x11d9ee0 to MMAL header 0x11d4a50. mmal->data 0xC0000006
1080p50.txt

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
Framerate is 25
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x368fb0)type: video, fourcc: UYVY bitrate: 0, framed: 0 extra data: 0, (nil) width: 1920, height: 1088, (0,0,1920,1080) pixel aspect ratio: 0/0, frame rate: 0/0 buffers num: 4(opt 1, min 1), size: 4177920(opt 4177920, min: 4177920), align: 0Created pool of length 4, size 0
Enable encoder....
Create pool of 3 buffers of size 3133440 for encode/render
Create pool of 3 buffers of size 0 for render
Create pool of 3 buffers of size 0 for encode ip
Create pool of 8 buffers of size 262144
Sent buffer 0x373478Sent buffer 0x373650Sent buffer 0x373828Sent buffer 0x373a00Sent buffer 0x373bd8Sent buffer 0x373db0Sent buffer 0x373f88Sent buffer 0x3741604 buffers requested.
length: 4177920 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x71204000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 245760
Exported buffer 0 to dmabuf 8, vcsm handle 245760
Linking V4L2 buffer index 0 ptr 0x374d90 to MMAL header 0x36f4c8. mmal->data 0xC0000007
length: 4177920 offset: 4177920 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x70e08000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 249856
Exported buffer 1 to dmabuf 9, vcsm handle 249856
Linking V4L2 buffer index 1 ptr 0x374e00 to MMAL header 0x36f6a0. mmal->data 0xC0000006
length: 4177920 offset: 8355840 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x70a0c000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 253952
Exported buffer 2 to dmabuf 10, vcsm handle 253952
Linking V4L2 buffer index 2 ptr 0x374e70 to MMAL header 0x36f878. mmal->data 0xC0000005
length: 4177920 offset: 12533760 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0x70610000.
Importing DMABUF 11 into VCSM...
...done. vcsm_handle 258048
Exported buffer 3 to dmabuf 11, vcsm handle 258048
Linking V4L2 buffer index 3 ptr 0x374ee0 to MMAL header 0x36fa50. mmal->data 0xC0000008

I also tried to modify gpu_mem and cma to see if it makes any changes but it doesn't seem to affect the result.

/boot/config.txt

Code: Select all

dtparam=i2c_arm=on
gpu_mem=128
dtparam=i2c_vc
dtoverlay=tc358743-fast
/boot/cmdline.txt

Code: Select all

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=b0a6b5a9-02 rootfstype=ext4 elevator=deadline fsck.repair=yes cma=128M rootwait

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

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

Wed Nov 15, 2017 12:44 pm

1080P30 encode is what the codec block is specified for. 1080P50 on a stock Pi will drop frames as you are a fair way over the spec.
The green lines are artefacts of running out of SDRAM bandwidth, and under very high stress conditions some writes get dropped and we get green :-(
At your own risk you can overclock your Pi (it is likely to set the warranty bit in the OTP, so it would be obvious if you returned it!). Generally there aren't many issues due to overclocking assuming it is stable, and it should still throttle back if it overheats.
I'm overclocking my Pi2 with the following in /boot/config.txt

Code: Select all

over_voltage=5
gpu_freq=450
# sdram overclock
sdram_freq=500
sdram_schmoo=0x02000020
over_voltage_sdram_p=6
over_voltage_sdram_i=4
over_voltage_sdram_c=4
force_turbo=1
That is working for me at 1080P50 without artefacts or dropped frames. Your mileage may vary.

Very little is done on the ARM CPUs in this process, at least with regard touching the image data, so I'm surprised there is any significant increase in CPU activity.
What it may be is that the file system has hit the cache limit and is saving the data to SD card. As the data is being saved in the callback context that is blocking all MMAL IPCs, and that includes taking the buffers from V4L2 and passing them into MMAL. Ideally that ought to be rewritten so that the saving is done in a new thread and thus frees up the IPC thread to do what it needs to. Your 500ms does sound like an SD card write. I get some huge stalls (sometimes >20seconds!) when the file system saves data as it is going to an NFS share.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
madnerd
Posts: 10
Joined: Wed Nov 01, 2017 6:43 am
Location: Montpellier, France
Contact: Website Twitter

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

Thu Nov 16, 2017 5:04 pm

I tried to overclock the Raspberry Pi, but I still got dropped frames.

I decided to check if the issue was with the SD card and tried to record the video in /dev/shm.
I managed to have a mp4 video without dropped frames with yavta/ffmpeg :D

So the bottleneck seems to be the sd card.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

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

Thu Nov 16, 2017 5:07 pm

madnerd wrote: I tried to overclock the Raspberry Pi, but I still got dropped frames.

I decided to check if the issue was with the SD card and tried to record the video in /dev/shm.
I managed to have a mp4 video without dropped frames with yavta/ffmpeg :D

So the bottleneck seems to be the sd card.
Awesome. What class SD card as you using?

User avatar
madnerd
Posts: 10
Joined: Wed Nov 01, 2017 6:43 am
Location: Montpellier, France
Contact: Website Twitter

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

Thu Nov 16, 2017 5:13 pm

Awesome. What class SD card as you using?
SanDisk Class 10 Micro 8GB SDHC

doublehp
Posts: 71
Joined: Wed May 02, 2012 1:11 am

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

Sun Nov 26, 2017 11:40 am

Class is irrelevant; event U2 Cards able to stand 80MB/s write are labelled C10 (10MB/s certified write). Modern cards can stand up to 120MB/s (and much faster read); but what is the max capability of the rpi ?

If the rpi is hardware limited to something below 60MB/s, you can increase your write rate by using a USB storage, and building a raid0 block using SD+USB; this would add about 40MB/s to your max write rate.

Do we have an estimation when this will be usable ? I would like to use this to build a home made IP-KVM; so, I need 1080p. I had read dec-17/jan-18. I don't care about small artefacts; I will need to heavily compress the stream to feed it on the network; but I want to be able to interact with BIOS/EFI, and new machines use 1080p from the first splash screens.

Are CSI bridges stable at hardware level, or is the manufacturer still working on new versions ? Which model are you using ?
https://auvidea.com/product-category/csi2bridge/

Thanks.

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

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

Fri Dec 01, 2017 3:52 pm

madnerd wrote:
Thu Nov 16, 2017 5:04 pm
I tried to overclock the Raspberry Pi, but I still got dropped frames.

I decided to check if the issue was with the SD card and tried to record the video in /dev/shm.
I managed to have a mp4 video without dropped frames with yavta/ffmpeg :D

So the bottleneck seems to be the sd card.
I've updated my yavta fork to do the saving in a separate thread, so that should smooth out any blocking of the MMAL IPC thread context.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
madnerd
Posts: 10
Joined: Wed Nov 01, 2017 6:43 am
Location: Montpellier, France
Contact: Website Twitter

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

Wed Dec 13, 2017 11:31 am

Hi 6by9, thanks for the update.

I test the yavta new version, but I still got lost frames.

Code: Select all

v4l2-ctl --set-edid=file=/home/pi/testEDID.txt --fix-edid-checksums
/home/pi/yavta/yavta --capture=10000000 -n 3 --encode-to=/home/pi/test/file.h264 -f UYVY -m -T /dev/video0
10mn test
  • TEST 1 : 28s lost
  • TEST 2 : 1s lost
  • TEST 3 : 4s lost
  • TEST 4 : 0s lost
  • TEST 5 : 3s lost
Terminal output
https://gist.github.com/maditnerd/60bb4 ... 5fc09fedb6

I retest using yavta with ffmpeg on /dev/shm and had no issues.

Code: Select all

v4l2-ctl --set-edid=file=/home/pi/testEDID.txt --fix-edid-checksums
/home/pi/yavta/yavta -f UYVY --capture=100000 -n 3 --encode-to=- -m -T /dev/video0 | ffmpeg -y -r 25 -i - -vcodec copy /dev/shm/file.mp4
5mn test
  • TEST 1 : OK
  • TEST 2 : OK
  • TEST 3 : OK
  • TEST 4 : OK
  • TEST 5 : OK

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

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

Wed Dec 13, 2017 11:41 am

madnerd wrote:
Wed Dec 13, 2017 11:31 am
I retest using yavta with ffmpeg on /dev/shm and had no issues.

Code: Select all

v4l2-ctl --set-edid=file=/home/pi/testEDID.txt --fix-edid-checksums
/home/pi/yavta/yavta -f UYVY --capture=100000 -n 3 --encode-to=- -m -T /dev/video0 | ffmpeg -y -r 25 -i - -vcodec copy /dev/shm/file.mp4
5mn test
  • TEST 1 : OK
  • TEST 2 : OK
  • TEST 3 : OK
  • TEST 4 : OK
  • TEST 5 : OK
I've been trying to get 1080p50 running on a pi 1, and have had a rate of ~2% dropped frames, i wonder if using ffmpeg on shm will be the magic key, I'll try it out later.

Can i ask what build of ffmpeg you're using?

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

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

Wed Dec 13, 2017 11:54 am

Using ffmpeg just means the data gets written into a Linux pipe instead of writing to disk immediately.
I'm now a little confused as to why the last change to yavta isn't behaving as I was expecting. Someone's borrowed my TC358743 board for the moment, so I'll have to reclaim it to do any more testing.
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.

Orbital6
Posts: 138
Joined: Sat Aug 08, 2015 6:32 pm

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

Wed Dec 13, 2017 12:06 pm

6by9 wrote:
Wed Dec 13, 2017 11:54 am
Using ffmpeg just means the data gets written into a Linux pipe instead of writing to disk immediately.
I'm now a little confused as to why the last change to yavta isn't behaving as I was expecting. Someone's borrowed my TC358743 board for the moment, so I'll have to reclaim it to do any more testing.
So i'll give it a miss then given writing to dev null also had dropped frames.

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

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

Wed Dec 13, 2017 2:24 pm

Orbital6 wrote:
Wed Dec 13, 2017 12:06 pm
6by9 wrote:
Wed Dec 13, 2017 11:54 am
Using ffmpeg just means the data gets written into a Linux pipe instead of writing to disk immediately.
I'm now a little confused as to why the last change to yavta isn't behaving as I was expecting. Someone's borrowed my TC358743 board for the moment, so I'll have to reclaim it to do any more testing.
So i'll give it a miss then given writing to dev null also had dropped frames.
You're trying to squeeze 1080P50 out of a BCM2835. The H264 encode block on all the BCM283x chips is only specified to do 1080P30, so you're pushing the system well beyond the specified limits by overclocking it.

As I've said to you on email, there are one or two places that an improvement may be possible, although it may not be the bottleneck in your case.
There is still an image conversion being done on the VPU that could potentially be avoided, but doing so requires a fair amount of involved plumbing. It'd save a chunk of VPU time, and more significantly another lump of SDRAM bandwidth, and every little helps.
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.

pi_cam
Posts: 1
Joined: Sat Dec 16, 2017 10:39 am

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

Sun Dec 17, 2017 4:40 pm

hello,

Thanks madnerd and 6by9 for the job.

I have a pi3 with a B101 rev 4 module. I need to have a /dev/video0 for use the B101 like a webcam in a browser (webrtc streaming).
I compiled tc358743 driver with this process https://gist.github.com/maditnerd/01195 ... 1682f1727b but my camera don't work. My browser see the unicam video but no image are display. I trying with 2 camera.

Please, i need help.

Code: Select all

v4l2-ctl --list-devices
unicam (platform:unicam 3f801000.csi1):
	/dev/video0

lsmod
Module                  Size  Used by
fuse                  106496  3
rfcomm                 49152  6
cmac                   16384  1
bnep                   20480  2
hci_uart               24576  1
bluetooth             368640  28 hci_uart,bnep,rfcomm
ecdh_generic           28672  1 bluetooth
bcm2835_unicam         36864  0
videobuf2_dma_contig    20480  1 bcm2835_unicam
videobuf2_memops       16384  1 videobuf2_dma_contig
brcmfmac              233472  0
videobuf2_v4l2         24576  1 bcm2835_unicam
tc358743               36864  1
brcmutil               16384  1 brcmfmac
videobuf2_core         49152  2 bcm2835_unicam,videobuf2_v4l2
v4l2_dv_timings        32768  2 bcm2835_unicam,tc358743
cfg80211              569344  1 brcmfmac
v4l2_fwnode            16384  2 bcm2835_unicam,tc358743
snd_bcm2835            32768  1
v4l2_common            16384  2 bcm2835_unicam,tc358743
rfkill                 28672  6 bluetooth,cfg80211
snd_pcm                98304  1 snd_bcm2835
i2c_mux_pinctrl        16384  0
snd_timer              32768  1 snd_pcm
videodev              188416  5 bcm2835_unicam,v4l2_common,videobuf2_core,videobuf2_v4l2,tc358743
media                  32768  2 videodev,tc358743
i2c_mux                16384  1 i2c_mux_pinctrl
snd                    69632  5 snd_timer,snd_bcm2835,snd_pcm
i2c_bcm2835            16384  0
evdev                  24576  6
fixed                  16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
i2c_dev                16384  0
ip_tables              24576  0
x_tables               28672  1 ip_tables
ipv6                  430080  26
syslog when i boot and i launch v4l2-ctl --set-dv-bt-timing=index=8

Code: Select all

[Dec 17 16:04:33 raspberrypi kernel: [  348.111385] unicam 3f801000.csi1: =================  START STATUS  =================
Dec 17 16:04:33 raspberrypi kernel: [  348.114015] tc358743 4-000f: -----Chip status-----
Dec 17 16:04:33 raspberrypi kernel: [  348.114985] tc358743 4-000f: Chip ID: 0x00
Dec 17 16:04:33 raspberrypi kernel: [  348.115951] tc358743 4-000f: Chip revision: 0x00
Dec 17 16:04:33 raspberrypi kernel: [  348.115959] tc358743 4-000f: Reset: IR: 1, CEC: 1, CSI TX: 0, HDMI: 0
Dec 17 16:04:33 raspberrypi kernel: [  348.115965] tc358743 4-000f: Sleep mode: off
Dec 17 16:04:33 raspberrypi kernel: [  348.115970] tc358743 4-000f: Cable detected (+5V power): no
Dec 17 16:04:33 raspberrypi kernel: [  348.116790] tc358743 4-000f: DDC lines enabled: yes
Dec 17 16:04:33 raspberrypi kernel: [  348.117627] tc358743 4-000f: Hotplug enabled: no
Dec 17 16:04:33 raspberrypi kernel: [  348.118813] tc358743 4-000f: CEC enabled: no
Dec 17 16:04:33 raspberrypi kernel: [  348.118818] tc358743 4-000f: -----Signal status-----
Dec 17 16:04:33 raspberrypi kernel: [  348.118823] tc358743 4-000f: TMDS signal detected: no
Dec 17 16:04:33 raspberrypi kernel: [  348.118838] tc358743 4-000f: Stable sync signal: no
Dec 17 16:04:33 raspberrypi kernel: [  348.118856] tc358743 4-000f: PHY PLL locked: no
Dec 17 16:04:33 raspberrypi kernel: [  348.118868] tc358743 4-000f: PHY DE detected: no
Dec 17 16:04:33 raspberrypi kernel: [  348.119717] tc358743 4-000f: No video detected
Dec 17 16:04:33 raspberrypi kernel: [  348.119730] tc358743 4-000f: Configured format: 1920x1080p24.0 (2750x1125)
Dec 17 16:04:33 raspberrypi kernel: [  348.119743] tc358743 4-000f: horizontal: fp = 638, +sync = 44, bp = 148
Dec 17 16:04:33 raspberrypi kernel: [  348.119750] tc358743 4-000f: vertical: fp = 4, +sync = 5, bp = 36
Dec 17 16:04:33 raspberrypi kernel: [  348.119755] tc358743 4-000f: pixelclock: 74250000
Dec 17 16:04:33 raspberrypi kernel: [  348.119765] tc358743 4-000f: flags (0x92): CAN_REDUCE_FPS CE_VIDEO HAS_CEA861_VIC
Dec 17 16:04:33 raspberrypi kernel: [  348.119771] tc358743 4-000f: standards (0x1): CEA
Dec 17 16:04:33 raspberrypi kernel: [  348.119776] tc358743 4-000f: CEA-861 VIC: 0
Dec 17 16:04:33 raspberrypi kernel: [  348.119781] tc358743 4-000f: -----CSI-TX status-----
Dec 17 16:04:33 raspberrypi kernel: [  348.119788] tc358743 4-000f: Lanes needed: 1
Dec 17 16:04:33 raspberrypi kernel: [  348.119793] tc358743 4-000f: Lanes in use: 1
Dec 17 16:04:33 raspberrypi kernel: [  348.121377] tc358743 4-000f: Waiting for particular sync signal: no
Dec 17 16:04:33 raspberrypi kernel: [  348.122348] tc358743 4-000f: Transmit mode: no
Dec 17 16:04:33 raspberrypi kernel: [  348.123315] tc358743 4-000f: Receive mode: no
Dec 17 16:04:33 raspberrypi kernel: [  348.124280] tc358743 4-000f: Stopped: no
Dec 17 16:04:33 raspberrypi kernel: [  348.124286] tc358743 4-000f: Color space: YCbCr 422 16-bit
Dec 17 16:04:33 raspberrypi kernel: [  348.125106] tc358743 4-000f: -----DVI-D status-----
Dec 17 16:04:33 raspberrypi kernel: [  348.125111] tc358743 4-000f: HDCP encrypted content: no
Dec 17 16:04:33 raspberrypi kernel: [  348.125117] tc358743 4-000f: Input color space: RGB full range
Dec 17 16:04:33 raspberrypi kernel: [  348.125939] unicam 3f801000.csi1: -----Receiver status-----
Dec 17 16:04:33 raspberrypi kernel: [  348.125946] unicam 3f801000.csi1: V4L2 width/height:   1920x1080
Dec 17 16:04:33 raspberrypi kernel: [  348.125952] unicam 3f801000.csi1: Mediabus format:     0000200f
Dec 17 16:04:33 raspberrypi kernel: [  348.125958] unicam 3f801000.csi1: V4L2 format:         UYVY
Dec 17 16:04:33 raspberrypi kernel: [  348.125987] unicam 3f801000.csi1: Unpacking/packing:   0 / 0
Dec 17 16:04:33 raspberrypi kernel: [  348.125991] unicam 3f801000.csi1: ----Live data----
Dec 17 16:04:33 raspberrypi kernel: [  348.125997] unicam 3f801000.csi1: Programmed stride:     48
Dec 17 16:04:33 raspberrypi kernel: [  348.126003] unicam 3f801000.csi1: Detected resolution: 0x0
Dec 17 16:04:33 raspberrypi kernel: [  348.126008] unicam 3f801000.csi1: Write pointer:       ef10b000
Dec 17 16:04:33 raspberrypi kernel: [  348.126014] unicam 3f801000.csi1: ==================  END STATUS  ==================/code]

[code]v4l2-ctl --all
Driver Info (not using libv4l2):
	Driver name   : unicam
	Card type     : unicam
	Bus info      : platform:unicam 3f801000.csi1
	Driver version: 4.14.0
	Capabilities  : 0x85200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x05200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
Priority: 2
Video input : 0 (Camera 0: ok)
DV timings:
	Active width: 1920
	Active height: 1080
	Total width: 2750
	Total height: 1125
	Frame format: progressive
	Polarities: +vsync +hsync
	Pixelclock: 74250000 Hz (24.00 frames per second)
	Horizontal frontporch: 638
	Horizontal sync: 44
	Horizontal backporch: 148
	Vertical frontporch: 4
	Vertical sync: 5
	Vertical backporch: 36
	Standards: CEA-861
	Flags: framerate can be reduced by 1/1.001, CE-video
DV timings capabilities:
	Minimum Width: 1
	Maximum Width: 10000
	Minimum Height: 1
	Maximum Height: 10000
	Minimum PClock: 0
	Maximum PClock: 165000000
	Standards: CEA-861, DMT, CVT, GTF
	Capabilities: Progressive, Reduced Blanking, Custom Formats
Format Video Capture:
	Width/Height      : 1920/1080
	Pixel Format      : 'UYVY'
	Field             : None
	Bytes per Line    : 3840
	Size Image        : 4177920
	Colorspace        : SMPTE 170M
	Transfer Function : Default
	YCbCr/HSV Encoding: Default
	Quantization      : Default
	Flags             : 

User Controls

            audio_sampling_rate (int)    : min=0 max=768000 step=1 default=0 value=0 flags=read-only
                  audio_present (bool)   : default=0 value=0 flags=read-only

Digital Video Controls

                  power_present (bitmask): max=0x00000001 default=0x00000000 value=0x00000000 flags=read-only

Code: Select all

v4l2-compliance 
v4l2-compliance SHA   : not available

Driver Info:
	Driver name   : unicam
	Card type     : unicam
	Bus info      : platform:unicam 3f801000.csi1
	Driver version: 4.14.0
	Capabilities  : 0x85200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps   : 0x05200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format

Compliance test for device /dev/video0 (not using libv4l2):

Required ioctls:
	test VIDIOC_QUERYCAP: OK

Allow for multiple opens:
	test second video open: OK
	test VIDIOC_QUERYCAP: OK
	test VIDIOC_G/S_PRIORITY: OK
	test for unlimited opens: OK

Debug ioctls:
	test VIDIOC_DBG_G/S_REGISTER: OK
	test VIDIOC_LOG_STATUS: OK

Input ioctls:
	test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
	test VIDIOC_ENUMAUDIO: OK (Not Supported)
	test VIDIOC_G/S/ENUMINPUT: OK
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 Audio Inputs: 0 Tuners: 0

Output ioctls:
	test VIDIOC_G/S_MODULATOR: OK (Not Supported)
	test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
	test VIDIOC_ENUMAUDOUT: OK (Not Supported)
	test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
	test VIDIOC_G/S_AUDOUT: OK (Not Supported)
	Outputs: 0 Audio Outputs: 0 Modulators: 0

Input/Output configuration ioctls:
	test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
	test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK
	test VIDIOC_DV_TIMINGS_CAP: OK
	test VIDIOC_G/S_EDID: OK

Test input 0:

	Control ioctls:
		test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
		test VIDIOC_QUERYCTRL: OK
		test VIDIOC_G/S_CTRL: OK
		test VIDIOC_G/S/TRY_EXT_CTRLS: OK
		test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
		test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
		Standard Controls: 3 Private Controls: 2

	Format ioctls:
		test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
		test VIDIOC_G/S_PARM: OK (Not Supported)
		test VIDIOC_G_FBUF: OK (Not Supported)
		test VIDIOC_G_FMT: OK
		test VIDIOC_TRY_FMT: OK
		test VIDIOC_S_FMT: OK
		test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
		test Cropping: OK (Not Supported)
		test Composing: OK (Not Supported)
		test Scaling: OK (Not Supported)

	Codec ioctls:
		test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
		test VIDIOC_G_ENC_INDEX: OK (Not Supported)
		test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)

	Buffer ioctls:
		test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
		test VIDIOC_EXPBUF: OK

Test input 0:


Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
when i launch ffmpeg -y -f v4l2 -loglevel verbose -i /dev/video0 -vcodec copy -f mp4 -t 10 /home/pi/test.mp4
I have this log :

Code: Select all

ffmpeg version 3.2.9-1~deb9u1 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Raspbian 6.3.0-18+rpi1) 20170516
  configuration: --prefix=/usr --extra-version='1~deb9u1' --toolchain=hardened --libdir=/usr/lib/arm-linux-gnueabihf --incdir=/usr/include/arm-linux-gnueabihf --enable-gpl --disable-stripping --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libebur128 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-omx --enable-openal --enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 --enable-shared
  libavutil      55. 34.101 / 55. 34.101
  libavcodec     57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter     6. 65.100 /  6. 65.100
  libavresample   3.  1.  0 /  3.  1.  0
  libswscale      4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
[video4linux2,v4l2 @ 0x1e715c0] fd:3 capabilities:85200001
[video4linux2,v4l2 @ 0x1e715c0] Querying the device for the current frame size
[video4linux2,v4l2 @ 0x1e715c0] Setting frame size to 1920x1080
[video4linux2,v4l2 @ 0x1e715c0] ioctl(VIDIOC_G_PARM): Inappropriate ioctl for device
[video4linux2,v4l2 @ 0x1e715c0] Time per frame unknown
When i kill ffmpeg because he does not do anything, i have this log :

Code: Select all

Input #0, video4linux2,v4l2, from '/dev/video0':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: rawvideo, 1 reference frame (UYVY / 0x59565955), uyvy422, 1920x1080 (0x0), 1000k tbr, 1000k tbn, 1000k tbc
[mp4 @ 0x1e73130] Could not find tag for codec rawvideo in stream #0, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argumentStream mapping:
  Stream #0:0 -> #0:0 (copy)
    Last message repeated 1 times
Exiting normally, received signal 2.

Code: Select all

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

koop_g
Posts: 5
Joined: Sun Jan 14, 2018 2:20 pm

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

Sun Jan 14, 2018 2:50 pm

deleted
Last edited by koop_g on Wed Mar 07, 2018 12:12 pm, edited 1 time in total.

doublehp
Posts: 71
Joined: Wed May 02, 2012 1:11 am

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

Mon Jan 15, 2018 5:49 pm

To test HDMI, I use an HDMI2AV converter, then, an AV-USB decoder; they produce a crappy image, but they are very cheap:
https://fr.aliexpress.com/item/DZLST-Mi ... 0.0.vsKuhX
https://fr.aliexpress.com/item/USB2-0-E ... 0.0.vsKuhX
then, use mplayer, or novnc.

IIRC, HDCP is a protocol to let communicate HDMI devices together for special features like "every one switches off because user goes to bed", should be unrelated with how video signal is transmitted. It's usefull for devices that are permanently connected, like game consoles, TVs, DVB recorders ...

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

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

Mon Jan 15, 2018 9:35 pm

koop_g wrote:
Sun Jan 14, 2018 2:50 pm
I then connected my canon 5d mark 3 which is the goal of this project and got a black screen :? :o :shock:
and that error came after a few sec

Code: Select all

raspivid -t 0
mmal: mmal_vc_component_enable: failed to enable component: ENOSPC
mmal: camera component couldn't be enabled
mmal: main: Failed to create camera component
mmal: Failed to run camera app. Please check for firmware updates
First issue - raspivid with the B101 is not a supported platform. It has significant limitations (mainly that it will only accept 720P), and will not be updated.
koop_g wrote:I then connected it via HDMI switcher ( which kind of braking the whole proof of concept, but just to nail the problem )
and got some what of an image, I guess you can call it that
everything is green and magenta and you can see just part of what the camera is showing in the middle of the frame, all the other part of the frame is corrupted.
Most likely it's convinced your Canon to output something that is within range, but if the resolution is greater than 720P I suspect it will crop the top left out of the frame.
koop_g wrote:I can't find anywhere if my camera use HDCP( I don't even have a clue what that is )
High-bandwidth Digital Content Protection - https://en.wikipedia.org/wiki/High-band ... Protection
Basically copy protection on HDMI signals to stop you copying Blurays and the like.
koop_g wrote:what are my option now ?
what should be my next step?
please please help
Forget raspivid.
Ensure your source is 1080P30 or lower.
There are two approaches out there: the raspi_tc358743 app (https://github.com/6by9/userland/tree/hdmi_in_hack), or UV4L has some support for the TC358743 chip. Both are covered in this thread.
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.

koop_g
Posts: 5
Joined: Sun Jan 14, 2018 2:20 pm

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

Tue Jan 16, 2018 9:28 am

deleted
Last edited by koop_g on Wed Mar 07, 2018 12:13 pm, edited 1 time in total.

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

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

Tue Jan 16, 2018 11:22 am

Carefully follow these installation instructions:
https://www.linux-projects.org/uv4l/installation/

hblanken
Posts: 10
Joined: Fri May 06, 2016 11:43 am

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

Wed Jan 17, 2018 11:25 am

6by9 and mikerr orbital6 and all others you made such huge progress with the toshiba kernel.

I read above that no one was successful in getting audio out of the auvidea b101 rev 4 from HDMI board into raspberry. unfortunately the auvidea support team is not very helpful. so I had a stab at making it happen. Unsuccessfully to date, but i think we are close.Any help appreciated.

Did anyone succeed yet? Please help us with the GPIO connections.

I followed this tutorial and with adafruit everything works fine.
https://learn.adafruit.com/adafruit-i2s ... g-and-test

In their manual for B101 Auvidea specifies several pinouts - I tried to match those to adafruit.

BCLK = A-BCK = pin 12
DOUT = A-DATA = pin 38
LRCLK = A-LRCK = pin 35
SEL = ? (not available on Auvidea)
? = A-MCLK (No idea if I need to connect this.)
3.3v
Ground

Auvidea Reset and Cable Pins are unclear - Which GPIO shall I connect those?

Anyone successful in getting audio into Pi?
Thanks!

Return to “Graphics, sound and multimedia”

Who is online

Users browsing this forum: No registered users and 5 guests