HDMI to CSI-2 via TC358743 on kernel 4.1

[koop_g]

confession: I am the the nobiest of noobs, I have no Idea what so ever the meaning for most parts in this forum
bytes and bits i2c (sounds like a cool name for a band).
for the most part I was copy pasting and agree with everything 6by9 had to say (joke)
anyways just so you can get going before some one with a real knowledge would answer I think this is an easy one for the most part.

Thank you Koop!

I ran into this when following your instructions

instructions not mine I just gathered them

pi@raspberrypi:~ $ v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums
Failed to open 1080P50EDID.txt: No such file or directory

I am sorry I forgot it, I will add this to my original post.

download the EDID file which is a hand shake file containing suggestions for your camera to monitor/chip settings[pixels, format, htz, etc.....]

Code: Select all

wget https://raw.githubusercontent.com/6by9/RPiTest/master/1080P50EDID.txt

Also, what is TNULEHIKANES ?

Any ideas?

thats a mistake FIXED

[geosapien]

Koop,

I am an RF technician with alot of free time on my hands, so my boss handed me a raspberry pi and told me to make an encoder out of it. I think i am a little greener than you are.....
Ultimately i will need to use FFMPEG and push the stream via UDP to a client server on a local network, but getting the thing to work at all is step 1.

Here is my new error...

pi@raspberrypi:~/yavta $ ./yavta --capture=1000 -n 3 --encode-to=file.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
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)(0x158efb0)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 0x1598d58Sent buffer 0x1598f30Sent buffer 0x1599108Sent buffer 0x15992e0Sent buffer 0x15994b8Sent buffer 0x1599690Sent buffer 0x1599868Sent buffer 0x1599a403 buffers requested, V4L2 returned 3 bufs.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x7246a000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 155648
Exported buffer 0 to dmabuf 8, vcsm handle 155648
Linking V4L2 buffer index 0 ptr 0x159a760 to MMAL header 0x15954c0. mmal->data 0xC0000003
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x723d4000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 159744
Exported buffer 1 to dmabuf 9, vcsm handle 159744
Linking V4L2 buffer index 1 ptr 0x159a7d0 to MMAL header 0x1595698. mmal->data 0xC0000004
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7233e000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 163840
Exported buffer 2 to dmabuf 10, vcsm handle 163840
Linking V4L2 buffer index 2 ptr 0x159a840 to MMAL header 0x1595870. mmal->data 0xC0000005
select timeout

[koop_g]

Koop,

I am an RF technician with alot of free time on my hands, so my boss handed me a raspberry pi and told me to make an encoder out of it. I think i am a little greener than you are.....
Ultimately i will need to use FFMPEG and push the stream via UDP to a client server on a local network, but getting the thing to work at all is step 1.

Here is my new error...

pi@raspberrypi:~/yavta $ ./yavta --capture=1000 -n 3 --encode-to=file.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
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)(0x158efb0)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 0x1598d58Sent buffer 0x1598f30Sent buffer 0x1599108Sent buffer 0x15992e0Sent buffer 0x15994b8Sent buffer 0x1599690Sent buffer 0x1599868Sent buffer 0x1599a403 buffers requested, V4L2 returned 3 bufs.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0x7246a000.
Importing DMABUF 8 into VCSM...
...done. vcsm_handle 155648
Exported buffer 0 to dmabuf 8, vcsm handle 155648
Linking V4L2 buffer index 0 ptr 0x159a760 to MMAL header 0x15954c0. mmal->data 0xC0000003
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0x723d4000.
Importing DMABUF 9 into VCSM...
...done. vcsm_handle 159744
Exported buffer 1 to dmabuf 9, vcsm handle 159744
Linking V4L2 buffer index 1 ptr 0x159a7d0 to MMAL header 0x1595698. mmal->data 0xC0000004
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0x7233e000.
Importing DMABUF 10 into VCSM...
...done. vcsm_handle 163840
Exported buffer 2 to dmabuf 10, vcsm handle 163840
Linking V4L2 buffer index 2 ptr 0x159a840 to MMAL header 0x1595870. mmal->data 0xC0000005
select timeout

did you set the timming ?

Code: Select all

v4l2-ctl --query-dv-timings

I am hoping that I didn't forget something on the way, I made this list during run and tried not to miss

[geosapien]

pi@raspberrypi:~/yavta $ v4l2-ctl --query-dv-timings
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:

[6by9]

Found some official info about the chip, maybe it would help some one to help us

TC358743

Features
HDMI-RX Interface
• HDMI 1.4
– Video Formats Support (Up to 1080P)
• RGB, YUV444: 24-bpp@60 fps
• YUV422 24-bpp @60 fps
– Audio Supports
• Internal Audio PLL to track N/CTS value transmitted by
the ACR packet
– 3D support
– Support for HDCP (High-bandwidth Digital Content
Protection)
<snip>

That's the same as quoting the sales blurb for a Ford Focus and expecting to use it to tweak the engine mapping. All the setup is done over I2C, so unless you have the full datasheet for what those I2C registers do, then you aren't going to get very far.

[6by9]

Thank you Koop!

I ran into this when following your instructions

pi@raspberrypi:~ $ v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums
Failed to open 1080P50EDID.txt: No such file or directory

Also, what is PASS TNULEHIKANES ?
Any ideas?

I've added the file into the yavta repo now. If you followed the instructions then there would have been an wget line to get it from my RPiTest repo.

[6by9]

pi@raspberrypi:~/yavta $ v4l2-ctl --query-dv-timings
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:

So your HDMI source isn't producing anything. You may find disconnecting and reconnecting the HDMI lead after having loaded the EDID file makes the source try again and produce a suitable output.
If trying to capture the output of a Pi, then it only reads the EDID as it boots, so you may well need to reboot it.

[tanshihaj]

Hi 6by9!

First of all thanks for great work, it helps me a lot.
I'm interesting in, do you have any plans to send changes in gst-omx repository to upstream gstreamer repository? I've applied these changes to 1.14.4 version of gst-omx and it seems work fine with libgstreamer1.0-0 and gstreamer1.0-plugins-base version 1.14.4 from buster repository.

[6by9]

Hi 6by9!

First of all thanks for great work, it helps me a lot.
I'm interesting in, do you have any plans to send changes in gst-omx repository to upstream gstreamer repository? I've applied these changes to 1.14.4 version of gst-omx and it seems work fine with libgstreamer1.0-0 and gstreamer1.0-plugins-base version 1.14.4 from buster repository.

Not really.

- The patch looking for OMX_BUFFERFLAG_ENDOFFRAME will be rejected as they have said that some other OMX implementations don't use it in the sensible way, and therefore it would break those. Hacking the H264 output buffer size likewise would be rejected (I might increase the default buffer size in the firmware though).
- Setting nStride and nSliceHeight I believe they have already fixed in both GStreamer and the firmware (https://github.com/raspberrypi/firmware/issues/1051. ndufresne commented, and he's one of the main GStreamer devs).
- Support for YUYV family, ARGB/ABGR, and RGB/BGR colour formats was one I was just experimenting with as I had a YUYV source. That potentially has some use upstream if they haven't already done it themselves.

The other main reason I'm not bothered is that the 4.19 kernel should be bringing along a V4L2 memory-to-memory codec implementation (which should also support 64 bit if we're lucky) so v4l2h264enc should be able to take over from omxh264enc, and v4l2h264dec instead of omxh264dec (and the associated changes for h263, mpeg4, mpeg2, jpeg, and vp8 as well). That's where I'd like to be heading, instead of hacking around other people's old code.
The V4L2 code also has some performance advantages over OMX, because it can avoid copying the data to/from GPU memory, which at 1080P amounts to at least 3MB per frame.

[tanshihaj]

Hi 6by9!

First of all thanks for great work, it helps me a lot.
I'm interesting in, do you have any plans to send changes in gst-omx repository to upstream gstreamer repository? I've applied these changes to 1.14.4 version of gst-omx and it seems work fine with libgstreamer1.0-0 and gstreamer1.0-plugins-base version 1.14.4 from buster repository.

Not really.

- The patch looking for OMX_BUFFERFLAG_ENDOFFRAME will be rejected as they have said that some other OMX implementations don't use it in the sensible way, and therefore it would break those. Hacking the H264 output buffer size likewise would be rejected (I might increase the default buffer size in the firmware though).
- Setting nStride and nSliceHeight I believe they have already fixed in both GStreamer and the firmware (https://github.com/raspberrypi/firmware/issues/1051. ndufresne commented, and he's one of the main GStreamer devs).
- Support for YUYV family, ARGB/ABGR, and RGB/BGR colour formats was one I was just experimenting with as I had a YUYV source. That potentially has some use upstream if they haven't already done it themselves.

The other main reason I'm not bothered is that the 4.19 kernel should be bringing along a V4L2 memory-to-memory codec implementation (which should also support 64 bit if we're lucky) so v4l2h264enc should be able to take over from omxh264enc, and v4l2h264dec instead of omxh264dec (and the associated changes for h263, mpeg4, mpeg2, jpeg, and vp8 as well). That's where I'd like to be heading, instead of hacking around other people's old code.
The V4L2 code also has some performance advantages over OMX, because it can avoid copying the data to/from GPU memory, which at 1080P amounts to at least 3MB per frame.

Thank you for explanation. Well it seems we are waiting for Raspbian Buster with new kernel.

[tanshihaj]

I have a two questions related with tc358743 kernel module.

1. Is it possible to use two tc358743 at the same time connected to csi0 and csi1? For example connect one to csi0 & i2c0 and another one to csi1 and i2c1? Does it require tc358743 driver source code changes?
2. If I want to connect tc358743 to i2c1 & csi0 (not the default i2c0 & csi1) changing tc358743 device tree overlay will be sufficient?

[6by9]

I have a two questions related with tc358743 kernel module.

1. Is it possible to use two tc358743 at the same time connected to csi0 and csi1? For example connect one to csi0 & i2c0 and another one to csi1 and i2c1? Does it require tc358743 driver source code changes?
2. If I want to connect tc358743 to i2c1 & csi0 (not the default i2c0 & csi1) changing tc358743 device tree overlay will be sufficient?

I'm assuming you're on a Compute Module (3) as a standard Pi doesn't have access to csi0. In which case it has already been covered in https://www.raspberrypi.org/forums/view ... 8&t=227354

Yes, you can run two tc358743 boards from the same CM with only device tree changes. The required second overlay is quoted in https://www.raspberrypi.org/forums/view ... 4#p1395310 and is using csi0 and i2c1 on GPIOs 44&45 by default.

[geosapien]

Sorry it took me a while to post. Here is my error at the final step



pi@raspberrypi:~/yavta $ v4l2-ctl --set-edid=file=1080P50EDID.txt --fix-edid-checksums

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
pi@raspberrypi:~/yavta $ v4l2-ctl --query-dv-timings
Active width: 1920
Active height: 1080
Total width: 2640
Total height: 1125
Frame format: progressive
Polarities: -vsync -hsync
Pixelclock: 148500000 Hz (50.00 frames per second)
Horizontal frontporch: 0
Horizontal sync: 720
Horizontal backporch: 0
Vertical frontporch: 0
Vertical sync: 45
Vertical backporch: 0
Standards:
Flags:
pi@raspberrypi:~/yavta $ ./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0
-bash: ./yavta: No such file or directory
pi@raspberrypi:~/yavta $ cd ..

[geosapien]

ignore the earlier post, i forgot to run make.

Here is my new message after i run ./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0


pi@raspberrypi:~/yavta $ ./yavta --capture=1000 -n 3 --encode-to=file.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) 1920x1080 (stride 3840) field none buffer size 4177920
QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
Framerate is 50
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x5f9fb0)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 0x603d58Sent buffer 0x603f30Sent buffer 0x604108Sent buffer 0x6042e0Sent buffer 0x6044b8Sent buffer 0x604690Sent buffer 0x604868Sent buffer 0x604a40Unable to request buffers: Cannot allocate memory (12).

[tanshihaj]

ignore the earlier post, i forgot to run make.

Here is my new message after i run ./yavta --capture=1000 -n 3 --encode-to=file.h264 -f UYVY -m -T /dev/video0


pi@raspberrypi:~/yavta $ ./yavta --capture=1000 -n 3 --encode-to=file.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) 1920x1080 (stride 3840) field none buffer size 4177920
QUERY_DV_TIMINGS returned 1920x1080 pixclk 148500000
Framerate is 50
Video format: UYVY (59565955) 1920x1080 (stride 3840) field none buffer size 4177920
vc.ril.isp:in:0(UYVY)(0x5f9fb0)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 0x603d58Sent buffer 0x603f30Sent buffer 0x604108Sent buffer 0x6042e0Sent buffer 0x6044b8Sent buffer 0x604690Sent buffer 0x604868Sent buffer 0x604a40Unable to request buffers: Cannot allocate memory (12).

Can you show us content of /boot/cmdline.txt?

[geosapien]

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

it is all one line

[cyphercolt]

Hey 6by9! I've gotten pretty far in my project after reading through most of the info on the 21 pages here (and Googling around).
My goal is to put the RTMP Streaming load on my Pi instead of running it on my PC, also lets me push a higher bitrate without eating all my PC resources.

I'm now trying to get a good FPS rate on my Twitch Stream, currently stuck at 8 fps in 720p.

So this is the current command I'm using to launch my Twitch Stream using GStreamer:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/[MYSTREAMKEYREDACTED]" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! videoconvert ! identity sync=true ! x264enc speed-preset=superfast  quantizer=25 tune=zerolatency bitrate=2000 key-int-max=15 ! video/x-h264,profile=main ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

It's only Producing 8fps, but when I run your Yavta capture test command it looks smooth as butter.
The Audio outputs perfectly fine, no jittering with the low FPS for some reason.
The resolution output to Twitch is 720p which is fine.

My goal here is a solid 30fps, and hopeful 60fps.

Here's my EDID timings which I set with the set / query command you posted in a previous page:

Code: Select all

        Active width: 1280
        Active height: 720
        Total width: 1650
        Total height: 750
        Frame format: progressive
        Polarities: -vsync -hsync
        Pixelclock: 74250000 Hz (60.00 frames per second)
        Horizontal frontporch: 0
        Horizontal sync: 370
        Horizontal backporch: 0
        Vertical frontporch: 0
        Vertical sync: 30
        Vertical backporch: 0
        Standards:
        Flags:

I've restarted the project 3 times now (finally "Backed up" my Pi before making changes so it's faster to restart without running a bunch of updates) This is the best FPS I could achieve so far. I was wondering if Yavta can be used in conjunction with GStreamer to send that high FPS video through, and the Audio pushed in through GStreamer?

Any help is appreciated! I'm pretty sure I've found everything I can on Google after 4 days of experimenting.

Thanks!

[6by9]

Hey 6by9! I've gotten pretty far in my project after reading through most of the info on the 21 pages here (and Googling around).
My goal is to put the RTMP Streaming load on my Pi instead of running it on my PC, also lets me push a higher bitrate without eating all my PC resources.

I'm now trying to get a good FPS rate on my Twitch Stream, currently stuck at 8 fps in 720p.

So this is the current command I'm using to launch my Twitch Stream using GStreamer:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/[MYSTREAMKEYREDACTED]" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! videoconvert ! identity sync=true ! x264enc speed-preset=superfast  quantizer=25 tune=zerolatency bitrate=2000 key-int-max=15 ! video/x-h264,profile=main ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

It's only Producing 8fps, but when I run your Yavta capture test command it looks smooth as butter.
The Audio outputs perfectly fine, no jittering with the low FPS for some reason.
The resolution output to Twitch is 720p which is fine.

Software video encode, particularly with a software format convert first is unlikely to work well as it will overload the cpus.
If you update to the 4.19 kernel (available through rpi-update) and Gstreamer 1.14 or higher, then you can use v4l2h264enc instead of x264enc to do hardware accelerated video encoding, and you shouldn't need the video convert either. You may be able to use omxh264enc on a standard stretch image, but it's not quite as efficient.
Yavta is using MMAL to get to the hardware acceleration, and Gstreamer has no interface to MMAL.

[cyphercolt]

Hey 6by9! I've gotten pretty far in my project after reading through most of the info on the 21 pages here (and Googling around).
My goal is to put the RTMP Streaming load on my Pi instead of running it on my PC, also lets me push a higher bitrate without eating all my PC resources.

I'm now trying to get a good FPS rate on my Twitch Stream, currently stuck at 8 fps in 720p.

So this is the current command I'm using to launch my Twitch Stream using GStreamer:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/[MYSTREAMKEYREDACTED]" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! videoconvert ! identity sync=true ! x264enc speed-preset=superfast  quantizer=25 tune=zerolatency bitrate=2000 key-int-max=15 ! video/x-h264,profile=main ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

It's only Producing 8fps, but when I run your Yavta capture test command it looks smooth as butter.
The Audio outputs perfectly fine, no jittering with the low FPS for some reason.
The resolution output to Twitch is 720p which is fine.

Software video encode, particularly with a software format convert first is unlikely to work well as it will overload the cpus.
If you update to the 4.19 kernel (available through rpi-update) and Gstreamer 1.14 or higher, then you can use v4l2h264enc instead of x264enc to do hardware accelerated video encoding, and you shouldn't need the video convert either. You may be able to use omxh264enc on a standard stretch image, but it's not quite as efficient.
Yavta is using MMAL to get to the hardware acceleration, and Gstreamer has no interface to MMAL.

So now it's going to be obvious I'm "just above" noob with linux.
I did get the 4.19 Kernel through rpi-update days ago
( Linux rbpi1 4.19.30-v7+ #1208 SMP Thu Mar 21 22:32:04 GMT 2019 armv7l GNU/Linux )

Now GStreamer was a simple install with the apt-get for me, however 1.14 is a bit more complex as it doesn't have some magic script.
I attempted to install GStreamer 1.14.4 following instructions from the Linuxfromscratch website. I also installed the good, the bad, and the ugly plugins through Linuxfromscratch as well, all 1.14.4. When I run my new command I get the following: (not sure if the pipeline is good yet but baby steps!)

"WARNING: erroneous pipeline: no element "v4l2h264enc" "

I thought v4l2h264enc is part of the good plugins package. - Not trying to get you to hold my hand, but any hints would be appreciated! Worst case I'll re-image my pi and try again.

Note:
I used the following command to remove the previous version of GStreamer before installing 1.14.4:
rm -rf /usr/bin/gst-* /usr/{lib,libexec}/gstreamer-1.0

My new pipeline which I'll definitely be modifying. v4l2h264enc controls taken from a Google search:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/live_424407399_xTrHueE5rjBdKrk2zhdG51chDNwVuJ" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! identity sync=true ! v4l2h264enc extra-controls="controls,h264_profile=4,h264_level=10,video_bitrate=256000;" ! video/x-h264,profile=high ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

I'm off to work so I'll spend more time on it tonight, if you have a chance to drop a hint or know what I missed please do!

[6by9]

Software video encode, particularly with a software format convert first is unlikely to work well as it will overload the cpus.
If you update to the 4.19 kernel (available through rpi-update) and Gstreamer 1.14 or higher, then you can use v4l2h264enc instead of x264enc to do hardware accelerated video encoding, and you shouldn't need the video convert either. You may be able to use omxh264enc on a standard stretch image, but it's not quite as efficient.
Yavta is using MMAL to get to the hardware acceleration, and Gstreamer has no interface to MMAL.

So now it's going to be obvious I'm "just above" noob with linux.
I did get the 4.19 Kernel through rpi-update days ago
( Linux rbpi1 4.19.30-v7+ #1208 SMP Thu Mar 21 22:32:04 GMT 2019 armv7l GNU/Linux )

Now GStreamer was a simple install with the apt-get for me, however 1.14 is a bit more complex as it doesn't have some magic script.
I attempted to install GStreamer 1.14.4 following instructions from the Linuxfromscratch website. I also installed the good, the bad, and the ugly plugins through Linuxfromscratch as well, all 1.14.4. When I run my new command I get the following: (not sure if the pipeline is good yet but baby steps!)

"WARNING: erroneous pipeline: no element "v4l2h264enc" "

I thought v4l2h264enc is part of the good plugins package. - Not trying to get you to hold my hand, but any hints would be appreciated! Worst case I'll re-image my pi and try again.

Note:
I used the following command to remove the previous version of GStreamer before installing 1.14.4:
rm -rf /usr/bin/gst-* /usr/{lib,libexec}/gstreamer-1.0

My new pipeline which I'll definitely be modifying. v4l2h264enc controls taken from a Google search:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/live_424407399_xTrHueE5rjBdKrk2zhdG51chDNwVuJ" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! identity sync=true ! v4l2h264enc extra-controls="controls,h264_profile=4,h264_level=10,video_bitrate=256000;" ! video/x-h264,profile=high ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

I'm off to work so I'll spend more time on it tonight, if you have a chance to drop a hint or know what I missed please do!

I cheat on GStreamer installs as someone had written a script that tries to do everything for you and had posted the link previously - https://gist.githubusercontent.com/spha ... r-build.sh
I've broken it apart as I'm rebuilding moderately regularly.

Use "sudo apt purge gst-<package name>" to tell apt to remove the old GStreamer, don't do it manually or it will try to update it when the next update comes along.

v4l2h264enc (and v4l2g264dec) only appears as an available component should it find a suitable V4L2 device to support it. "ls /dev/video*" should list video10, video11, and video12 if your 4.19 install has done the relevant magic. /dev/video0 is the Auvidea card.

[cyphercolt]

Software video encode, particularly with a software format convert first is unlikely to work well as it will overload the cpus.
If you update to the 4.19 kernel (available through rpi-update) and Gstreamer 1.14 or higher, then you can use v4l2h264enc instead of x264enc to do hardware accelerated video encoding, and you shouldn't need the video convert either. You may be able to use omxh264enc on a standard stretch image, but it's not quite as efficient.
Yavta is using MMAL to get to the hardware acceleration, and Gstreamer has no interface to MMAL.

So now it's going to be obvious I'm "just above" noob with linux.
I did get the 4.19 Kernel through rpi-update days ago
( Linux rbpi1 4.19.30-v7+ #1208 SMP Thu Mar 21 22:32:04 GMT 2019 armv7l GNU/Linux )

Now GStreamer was a simple install with the apt-get for me, however 1.14 is a bit more complex as it doesn't have some magic script.
I attempted to install GStreamer 1.14.4 following instructions from the Linuxfromscratch website. I also installed the good, the bad, and the ugly plugins through Linuxfromscratch as well, all 1.14.4. When I run my new command I get the following: (not sure if the pipeline is good yet but baby steps!)

"WARNING: erroneous pipeline: no element "v4l2h264enc" "

I thought v4l2h264enc is part of the good plugins package. - Not trying to get you to hold my hand, but any hints would be appreciated! Worst case I'll re-image my pi and try again.

Note:
I used the following command to remove the previous version of GStreamer before installing 1.14.4:
rm -rf /usr/bin/gst-* /usr/{lib,libexec}/gstreamer-1.0

My new pipeline which I'll definitely be modifying. v4l2h264enc controls taken from a Google search:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/live_424407399_xTrHueE5rjBdKrk2zhdG51chDNwVuJ" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! identity sync=true ! v4l2h264enc extra-controls="controls,h264_profile=4,h264_level=10,video_bitrate=256000;" ! video/x-h264,profile=high ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! voaacenc bitrate=32000 ! aacparse ! queue ! mux.

I'm off to work so I'll spend more time on it tonight, if you have a chance to drop a hint or know what I missed please do!

I cheat on GStreamer installs as someone had written a script that tries to do everything for you and had posted the link previously - https://gist.githubusercontent.com/spha ... r-build.sh
I've broken it apart as I'm rebuilding moderately regularly.

Use "sudo apt purge gst-<package name>" to tell apt to remove the old GStreamer, don't do it manually or it will try to update it when the next update comes along.

v4l2h264enc (and v4l2g264dec) only appears as an available component should it find a suitable V4L2 device to support it. "ls /dev/video*" should list video10, video11, and video12 if your 4.19 install has done the relevant magic. /dev/video0 is the Auvidea card.

I do indeed have 4.19:
ls /dev/video*
/dev/video0 /dev/video10 /dev/video11 /dev/video12

Well then I hate myself for spending an hour and a half making the gstreamer build, thanks for that tip for the uninstall as well. I'm gonna vpn and ssh in from my phone and finish this on my break... I'm too excited to get this working! (I have a friend who wants to do the same streaming setup as me, not sure I want to share my secrets after almost a week of work without making them go through the pain first)

I'll post here if I got it working.

Thanks a bunch!

[cyphercolt]

Reducing thread bloat removing the quotes.

I broke apart the script and ran it on ssh line by line, and got it to install.
The only thing is "faac" doesn't seem to be included with it all of a sudden, and I've lost audio.

I have 720P60 looking amazing though!

I'll keep trying to find another audio encoder to use and post back if I do get something working, but otherwise I "voaacenc" and "aacparse" are not useable. (the quality of the sound was not that amazing anyway)

Thanks again for all the help!

[cyphercolt]

Reducing thread bloat removing the quotes.

I broke apart the script and ran it on ssh line by line, and got it to install.
The only thing is "faac" doesn't seem to be included with it all of a sudden, and I've lost audio.

I have 720P60 looking amazing though!

I'll keep trying to find another audio encoder to use and post back if I do get something working, but otherwise I "voaacenc" and "aacparse" are not useable. (the quality of the sound was not that amazing anyway)

Thanks again for all the help!

Disregard that, I discovered gst-inspect-1.0 | grep aac and found there's "avenc_aac" which is is working now.

Final Pipeline:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/live_424407399_xTrHueE5rjBdKrk2zhdG51chDNwVuJ" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! identity sync=true ! v4l2h264enc extra-controls="controls,h264_profile=4,h264_level=10,video_bitrate=256000;" ! video/x-h264,profile=high ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! audioconvert ! avenc_aac ! aacparse ! queue ! mux.

1280x720 - 60fps on twitch, 1.5sec latency. I'm very impressed!

[cyphercolt]

Reducing thread bloat removing the quotes.

I broke apart the script and ran it on ssh line by line, and got it to install.
The only thing is "faac" doesn't seem to be included with it all of a sudden, and I've lost audio.

I have 720P60 looking amazing though!

I'll keep trying to find another audio encoder to use and post back if I do get something working, but otherwise I "voaacenc" and "aacparse" are not useable. (the quality of the sound was not that amazing anyway)

Thanks again for all the help!

Disregard that, I discovered gst-inspect-1.0 | grep aac and found there's "avenc_aac" which is is working now.

Final Pipeline:

Code: Select all

gst-launch-1.0 flvmux streamable=true name=mux ! rtmpsink location="rtmp://live.justin.tv/app/[STREAMKEY]" v4l2src ! "video/x-raw,framerate=30/1,format=UYVY" ! identity sync=true ! v4l2h264enc extra-controls="controls,h264_profile=4,h264_level=10,video_bitrate=256000;" ! video/x-h264,profile=high ! h264parse ! queue ! mux. alsasrc device=hw:1 ! audio/x-raw,rate=48000,channels=2 ! identity sync=true ! audioconvert ! avenc_aac bitrate=48000 ! aacparse ! queue ! mux.

1280x720 - 60fps on twitch, 1.5sec latency. I'm very impressed!

I gave it a reboot and lost all my plugins... Whyyyyyyyyyyyy do you do this to me pi... (I obviously missed an important step) - Any ideas there?

[6by9]

I gave it a reboot and lost all my plugins... Whyyyyyyyyyyyy do you do this to me pi... (I obviously missed an important step) - Any ideas there?

export LD_LIBRARY_PATH=/usr/local/lib/
For some reason the script is set to put the libraries in a place that isn't on the normal search path - one of the main reasons not to blindly follow scripts.