6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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 Jun 13, 2016 9:24 am

Slight plea: Do we have anyone on here who is familiar with kernel development, and ideally V4L2?

I'm afraid that my efforts on this have been stalled recently due to family commitments. However I've found a very helpful release from Broadcom https://android.googlesource.com/kernel ... am_camera/
Yup, they have actually released an Linux kernel driver for the Unicam peripheral, so it's no longer dependent on having restricted information!

soc_camera is in the process of being deprecated from the kernel in favour of the subdevice architecture, however that driver should give enough information for a smart person with some time to convert it into a basic subdevice with device tree support.
https://github.com/raspberrypi/linux/tr ... orm/am437x provides a reasonable basis as a driver for the subdevice framework.

I'm more than happy to provide support in that effort, but I'm too short on time tackle the whole project at the moment.
It should be possible to make it clean enough to upstream too - I can't see any significant dependencies on proprietary stuff, although we may need some of Eric's new stuff for clock management.

(I'm cross-posting this to a couple of other related threads - apologies to the mods)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Y3S
Posts: 2
Joined: Mon Apr 18, 2016 10:14 am

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

Wed Jun 15, 2016 11:12 am

As mentioned several times by other people, one problem when using raspivid together with the TC358743 is the EDID, which is send from the TC358743 to the hdmi source. The default EDID recommend 720p60 but not 1080p25, so the source device doesn’t switch to it automatically. I find out the firmware /boot/start_x.elf use the same default EDID as in raspi_tc358743.c from 6by9. When open the start_x.elf in a hex-editor, the EDID can easily be located by searching the first few bytes of the default EDID from raspi_tc358743.c. When replacing the default EDID within start_x.elf with one adapted to the RPI, using the correct resolution by the source device should work much better.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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 Jun 15, 2016 11:29 am

Y3S wrote:As mentioned several times by other people, one problem when using raspivid together with the TC358743 is the EDID, which is send from the TC358743 to the hdmi source. The default EDID recommend 720p60 but not 1080p25, so the source device doesn’t switch to it automatically. I find out the firmware /boot/start_x.elf use the same default EDID as in raspi_tc358743.c from 6by9. When open the start_x.elf in a hex-editor, the EDID can easily be located by searching the first few bytes of the default EDID from raspi_tc358743.c. When replacing the default EDID within start_x.elf with one adapted to the RPI, using the correct resolution by the source device should work much better.
And as has been said many times, using raspivid with the TC358743 is not supported.

I suspect you're going to get cropping of the image as the receiver peripheral hasn't been told about the new resolution and it will still be writing into a 1280x720 image buffer. But if that is your definition of working much better, then I'm happy for you.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

afbje
Posts: 7
Joined: Fri Mar 04, 2016 10:03 am

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

Sat Jul 09, 2016 11:16 am

I want to input 1920x1080x30fps RGB24bit data from CSI connector.
The FPGA board is connected with the CSI connector.

TC358743 driver is very near my purpose.

Can my purpose be achieved by adding some changes to this driver, and changing the usage?

I2C is connected to FPGA, so it is possible to make an easy i2c receiver.

I want to receive only 1920x1080x30fps RGB24bit data simply.
It is also unnecessary to control EDID of course.

Could you please advice to me.

eazrael
Posts: 1
Joined: Mon Jul 11, 2016 9:44 pm

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

Sat Jul 23, 2016 10:18 pm

I am currently trying to get a B101 working but haven't much success. And to be honest, I still do not get the whole picture what parts are all involved :(

I am using a RPi 3 and recompiled the latest Raspbian kernal (4.4.15) with the default Raspbian Config + TC358743 support & dependencies. I had no success with raspivid, always got the ENOSPC error, tried all hints google found like boot parameters, module load orders abd blacklist. GPU Memory is set to 256MB.

I had no success with raspi_tc358743, which looks more promising, either. The program runs without error, but never reaches "Start streaming". Output looks like:

Code: Select all

mmal: Set pack to 0, unpack to 0
mmal: Set rx_timing
mmal: Enable rawcam....
mmal: output p_fmt_commit...
mmal: buffer size is 2764800 bytes, num 8
mmal: Create connection....
mmal: Create connection....
mmal: Enable connection...
mmal: buffer size is 2764800 bytes, num 8
I recompiled raspi_tc358743 with log level to TRACE. Last output line is

Code: Select all

mmal: mmal_port_enable: vc.ril.rawcam:out:0(BGR3) port 0x476ba0, cb (nil), buffers (4/4/4,2764800/2764800/2764800)
Full output can be found at http://evilazrael.net/tmp/raspi_tc358743_verbose.txt.

I've set "dtparam=i2c_vc=on" in /boot/config.txt and updated the firmware with rpi-update. In the kernel log is nothing suspicious besides i2c-dev sometimes reports 2 timeout during module load. Did I anything wrong or missed something?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Sun Jul 24, 2016 7:49 am

eazrael wrote:I am using a RPi 3
I'm afraid that is your point of failure.
The Pi3 uses i2c-0 from the GPU for uses other than the camera, display, and HATs, so is not available from the ARM at all.

All is not lost however as i2c-1 can be redirected to GPIOs 44&45 which are the pins used for the camera on Pi3. It requires a little bit of fiddling that I just haven't had the time for. I think all the relevant dt overlays exist (https://github.com/raspberrypi/linux/bl ... verlay.dts allows modification of the GPIOs use for the i2c-1)
GPIOs aren't needed for TC358743, but can be accessed if necessary - see posts around viewtopic.php?f=43&t=109137&p=1005243#p1003461
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

haff
Posts: 1
Joined: Fri Aug 05, 2016 12:15 pm

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

Fri Aug 05, 2016 12:49 pm

@6by9 I'm working on the i.MX6 board that uses tc358743. I'm using driver by boundary devices on kernel 3.10. Currently struggling with the interlaced modes. Other modes are working fine. Some time ago you have mentioned:
6by9 wrote:The Toshiba chip sends the two fields on two different image IDs within the CSI stream. We can differentiate between 2 sets of IDs which are currently used for video vs non-video (audio in this case, though not fully handled yet).
That is the behavior I also expect, but it still doesn't work for me.

My thought is that both fields should have the same Data Type, but different Virtual Channel. Interlaced output is not supported for YUV422 16bit mode, so I'm using YUV444 24bit. This way Data ID should be 0x24 (0th virtual channel, 0x24 data type) for the top field and, for example, 0x64 (1st channel, 0x24 data type) for the bottom field. But when I specify 0x6464 (just to test 1st channel) in 0x000c register nothing happens. I receive no frames on the i.MX6 side. Have you touched this issue? Or, if it not too much hassle, can you try it on your platform?

From one side I highly doubt that tc358743 for some reason may fail to copy this one byte into MIPI header. And when I specify 0x23 instead of 0x24 I see that it does changes image. But on the other hand I have tried everything I can on i.MX6 side. Channel configuration there is reduced to configuring only 3 registers properly, and I have tried every possible configuration for them.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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 Sep 07, 2016 8:44 pm

Hi haff. Sorry, I totally missed your post.
I haven't run interlaced mode at all, so can only comment on theory. Life has overtaken getting an ARM side driver sorted, so can't easily test at the mo. It's still on the to-do list.

Do you have access to the full datasheet for the chip? Without it you're going to be struggling a bit, but it isn't publicly available.
Quoting one small part:
For interlace video, users should program their desired interlace stream DataID in
register field PacketID1.VPID0 and PacketID1.VPID1 for top and bottom field,
respectively.
Those values are described as "CSI Video Packet ID [0|1]", so it does appear to be genuine data type changing between the fields and not the virtual channel.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Tue Sep 13, 2016 1:35 am

First off, just wanted to say thank you to 6by9 for all his efforts on this, very interesting!
6by9 wrote:
eazrael wrote:I am using a RPi 3
I'm afraid that is your point of failure.
The Pi3 uses i2c-0 from the GPU for uses other than the camera, display, and HATs, so is not available from the ARM at all.

All is not lost however as i2c-1 can be redirected to GPIOs 44&45 which are the pins used for the camera on Pi3. It requires a little bit of fiddling that I just haven't had the time for. I think all the relevant dt overlays exist (https://github.com/raspberrypi/linux/bl ... verlay.dts allows modification of the GPIOs use for the i2c-1)
GPIOs aren't needed for TC358743, but can be accessed if necessary - see posts around viewtopic.php?f=43&t=109137&p=1005243#p1003461
I got 6by9's code working on my Pi3 by running the following to remap /dev/i2c-1 to GPIO 44&45. You can update the camera_i2c script with the following:

Code: Select all

gpio -g mode 2 in
gpio -g mode 3 in
gpio -g mode 44 alt2
gpio -g mode 45 alt2
Next you will need to of course change instances of /dev/i2c-0 to /dev/i2c-1 in the raspi_tc358743.c and recompile.

One thing that I have experienced is that video will display fine the first run, every run after will just display a black screen. My PC receives the HPD and enables it's external display at 1280x720, but no video on the PI. A soft-reboot does not fix the problem, only a full power off will correct the issue. I vaguely remember reading about a similar (if not the same issue) in this thread or a related thread but cannot seem to find it now - I apologize if this is a know issue.

Thanks,
Sam

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Tue Sep 13, 2016 9:28 am

samsonx wrote:I got 6by9's code working on my Pi3 by running the following to remap /dev/i2c-1 to GPIO 44&45. You can update the camera_i2c script with the following:

Code: Select all

gpio -g mode 2 in
gpio -g mode 3 in
gpio -g mode 44 alt2
gpio -g mode 45 alt2
Next you will need to of course change instances of /dev/i2c-0 to /dev/i2c-1 in the raspi_tc358743.c and recompile.
Lots of people seem to be playing with this at the moment. I merged a pull request last week to https://github.com/6by9/userland/blob/rawcam/camera_i2c that detects the board revision and does all the GPIO magic correctly for the detected revision. I'll cherry-pick it across to the hdmi_in branch.
(edit: cherry-pick done and updated the hdmi_in branch)
For the Pi3 you do still need to mod the app to open i2c1 instead of i2c0, so not quite all plain sailing.
samsonx wrote:One thing that I have experienced is that video will display fine the first run, every run after will just display a black screen. My PC receives the HPD and enables it's external display at 1280x720, but no video on the PI. A soft-reboot does not fix the problem, only a full power off will correct the issue. I vaguely remember reading about a similar (if not the same issue) in this thread or a related thread but cannot seem to find it now - I apologize if this is a know issue.
The rawcam component on the GPU does have some issues. My focus is now on getting things merged properly into the kernel instead though, so it's unlikely to change.
The main thing is generally to NOT exit with ctrl-C but allow the app to clean up properly. Memory says I had a double-free on the GPU side which does lock things up. As an alternative you could install a signal handler on ctrl-C to do the cleanup.
The code I've provided is purely my hacking around and I do not claim it is suitable for production! I'm glad people are having some fun experimenting with it though.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Kubi
Posts: 4
Joined: Fri Sep 09, 2016 6:40 am

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

Tue Sep 13, 2016 11:34 am

One thing that I have experienced is that video will display fine the first run, every run after will just display a black screen. My PC receives the HPD and enables it's external display at 1280x720, but no video on the PI. A soft-reboot does not fix the problem, only a full power off will correct the issue. I vaguely remember reading about a similar (if not the same issue) in this thread or a related thread but cannot seem to find it now - I apologize if this is a know issue.
I've discovered the same problem and solved it by extracting the initialization of the tc358743 (done via I²C) from the rest of the raspi_tc358743.c code. Now, I initialize the tc358743 only once after power up and can call the video stream part of raspi_tc358743.c multiple times.
I don't know why the initialization doesn't work if it is called twice or more, but calling it only once solved the problem for me.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Mon Sep 19, 2016 10:11 pm

6by9 wrote:Before anyone queries me on it, yes I've just updated my hdmi_in branch.
I've rebased the tree on the latest userland, and added an ISP component which can then do resizing using the hardware. If you try it at the moment the I'm afraid the released firmware has red and blue swapped - I had wrong coefficients in a colour conversion matrix. I have a firmware patch for that to pass on to Pi Towers for release.
I had tried extending the pipe to:

Code: Select all

rawcam->isp->video_splitter-+->video_render
                            +- video_encode->app
but for some reason video_splitter wasn't doing what I expected. When I next get a few minutes to work on this I'll be looking into why.
Have you had any luck using the video_encode with rawcam? I assume this component would allow for creating a mp4??

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Tue Sep 20, 2016 9:36 pm

samsonx wrote:Have you had any luck using the video_encode with rawcam? I assume this component would allow for creating a mp4??
Sorry, been busy with other stuff. It is still on the list of stuff to play with.
It would allow you to produce an H264 elementary stream. Muxing it in to a container (eg mp4) would be a secondary step.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Fri Sep 30, 2016 6:48 pm

Hello 6by9, I have been doing some work trying to get CSI2 video working with the raspi_tc358743.c code and TI's ds90uh940 IC to supply the CSI2 video. I am using the ds90uh929 and ds90uh940 to get HDMI video into the PI. I have hacked up your code and have been able to get good video at 1920x1080p30 and 1280x720p60, though for some reason 720x480p60 is giving me some strange issues. If I set the width and height to 720x480 the video is scrambled..
https://drive.google.com/open?id=0B4Na9 ... m9BLWVFVHM
and for some reason I don't understand setting the width and height to 1440x480 will give me unscrambled video but with two images wide and the height is squished.
https://drive.google.com/open?id=1J57Xe ... D95bDW3_tw

I notice I get the same appearance of the second image if I view 1280x720 HDMI video with MMAL set to 2560x720.

Any clues as to why 720x480 would look like that? I have seem similar results when the MMAL width and height do not match the incoming video, but the appearance at 1440x480 make me think that I have the correct resolution.

My end goal is the have the program detect the HDMI video input, read the resolution and setup the MMAL connection at the proper resolution, if video is lost, the connection is destroyed and video is disabled. The user can then plug potentially any HDMI source in and the MMAL connection will be created/destroyed automatically.. I have has some limited success with this but am having inconsistent results trying to kill the connection and remake the connection. Destroying the connection works sometimes, and recreating the connection a second time also works sometimes.

Here is the hacked up version of your code:

Code: Select all


#define ENCODING MMAL_ENCODING_BGR24

#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_NONE
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_NONE

#define I2C_ADDR 0x0c // DS90DU940 I2C ADDRESS

#define CSI_IMAGE_ID 0x00
#define CSI_DATA_LANES 2

uint8_t get_hdmi_freq(void)
{
   int fd;
   uint8_t freq;
   
   fd = open("/dev/i2c-1", O_RDWR);
   if (!fd)
   {
      vcos_log_error("Couldn't open I2C device");
      return;
   }
   if(ioctl(fd, I2C_SLAVE, 0x36) < 0)
   {
      vcos_log_error("Failed to set I2C address");
      return;
   }
   
   freq = i2c_rd8(fd, 0x5f); // find HDMI Frequency from 929 ic
   
   vcos_log_error("HDMI Frequecy is %d MHz", freq);
   
   close(fd);
   return freq;

}

uint16_t get_hdmi_height(void)
{
   int fd;
   uint8_t height_lsb;
   uint16_t height_msb;
   uint16_t height;
   
   fd = open("/dev/i2c-1", O_RDWR);
   if (!fd)
   {
      vcos_log_error("Couldn't open I2C device");
      return;
   }
   if(ioctl(fd, I2C_SLAVE, 0x36) < 0)
   {
      vcos_log_error("Failed to set I2C address");
      return;
   }
   
   i2c_wr8(fd, 0x49, 0x68); // select address LSB
   i2c_wr8(fd, 0x4a, 0x01); // select address MSB 
   i2c_wr8(fd, 0x48, 0x03); // start APB read

  // find HDMI width of input signal from 940 ic
   height_lsb = i2c_rd8(fd, 0x4b); // find HDMI width lsb
   height_msb = i2c_rd8(fd, 0x4c); // find HDMI width msb
   height = (height_msb << 8) | height_lsb;

   vcos_log_error("HDMI height is %d pixels", height);
   
   close(fd);
   return height;

}

void create_mmal_connection(int width, int height)
{
	int i;

	bcm_host_init();
	vcos_log_register("RaspiRaw", VCOS_LOG_CATEGORY);

	status = mmal_component_create("vc.ril.rawcam", &rawcam);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to create rawcam");
		return -1;
	}
	status = mmal_component_create("vc.ril.video_render", &render);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to create rawcam");
		return -1;
	}
	output = rawcam->output[0];
	input = render->input[0];

	status = mmal_port_parameter_get(output, &rx_cfg.hdr);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to get cfg");
		mmal_component_destroy(rawcam);
		mmal_component_destroy(render);	
	
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}
	rx_cfg.image_id = CSI_IMAGE_ID;
	rx_cfg.data_lanes = CSI_DATA_LANES;
	rx_cfg.unpack = UNPACK;
	rx_cfg.pack = PACK;
	rx_cfg.data_lanes = 2;
	rx_cfg.embedded_data_lines = 128;
	vcos_log_error("Set pack to %d, unpack to %d", rx_cfg.unpack, rx_cfg.pack);
	status = mmal_port_parameter_set(output, &rx_cfg.hdr);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to set cfg");
		mmal_component_destroy(rawcam);
		mmal_component_destroy(render);	
	
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}

	vcos_log_error("Enable rawcam....");

	status = mmal_component_enable(rawcam);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to enable");
		mmal_component_destroy(rawcam);
		mmal_component_destroy(render);	
	
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}
	status = mmal_port_parameter_set_boolean(output, MMAL_PARAMETER_ZERO_COPY, MMAL_TRUE);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to set zero copy");
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}

	output->format->es->video.crop.width = width;
	output->format->es->video.crop.height = height;
	output->format->es->video.width = VCOS_ALIGN_UP(width, 32);
	output->format->es->video.height = VCOS_ALIGN_UP(height, 16);
	output->format->encoding = ENCODING;
	vcos_log_error("output p_fmt_commit...");
	status = mmal_port_format_commit(output);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed port_format_commit");
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}

 	output->buffer_size = output->buffer_size_recommended;
 	output->buffer_num = 8; //output->buffer_num_recommended;
     vcos_log_error("buffer size is %d bytes, num %d", output->buffer_size, output->buffer_num);
	status = mmal_port_format_commit(output);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed port_format_commit");
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}

	//If video_render does ignore MMAL_BUFFER_HEADER_FLAG_CODECSIDEINFO (firmware hack!), can
   //use a mmal_connection


	status = mmal_port_parameter_set_boolean(input, MMAL_PARAMETER_ZERO_COPY, MMAL_TRUE);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to set zero copy on video_render");
		status = mmal_component_disable(rawcam);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable rawcam");
		}
		status = mmal_component_disable(render);
		if(status != MMAL_SUCCESS)
		{
			vcos_log_error("Failed to disable render");
		}
	}
	vcos_log_error("Create connection....");
   status =  mmal_connection_create(&connection, output, input, MMAL_CONNECTION_FLAG_TUNNELLING);

   if (status == MMAL_SUCCESS)
   {
	vcos_log_error("Enable connection...");
    vcos_log_error("buffer size is %d bytes, num %d", output->buffer_size, output->buffer_num);
      status =  mmal_connection_enable(connection);
      if (status != MMAL_SUCCESS)
         mmal_connection_destroy(connection);
   }


	vcos_log_error("All done. Start streaming...");

}

void destroy_mmal_conncetion(void)
{
	vcos_log_error("Stopping streaming...");

	mmal_connection_disable(connection);
	mmal_connection_destroy(connection);

	status = mmal_component_disable(rawcam);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to disable rawcam");
	}
	status = mmal_component_disable(render);
	if(status != MMAL_SUCCESS)
	{
		vcos_log_error("Failed to disable render");
	}

	mmal_component_destroy(rawcam);
	mmal_component_destroy(render);	
}

int main (void)
{

	uint8_t freq;
	uint16_t height;
	//create_mmal_connection(1280, 720);
	int running = 0;

	while (1)
	{
		freq = get_hdmi_freq();

		if (freq != 0 && running == 0) // we must have good video and we need to create the mmal connection
		{
		running = 1;
		height = get_hdmi_height();
		
			switch (height)
			{
				case 480: 
					create_mmal_connection(720, 480);
					vcos_log_error("Found good video, starting connection to mmal at 720x480");
				break;
					
				case 720:
					create_mmal_connection(1280, 720);
					vcos_log_error("Found good video, starting connection to mmal at 1280x720");
				break;

				case 1080:
					create_mmal_connection(1920, 1080);
					vcos_log_error("Found good video, starting connection to mmal at 1920x1080");
				break;
			}
		}
		else if (freq == 0 && running == 1) // we have a mmal connection but video was lost, kill the connection
		{
			vcos_log_error("We have lost video, killing connection");
			destroy_mmal_conncetion();
			running = 0; // reset the running state;
			vcos_sleep(5000); // lets wait 5 seconds to let the connection die
		}

		vcos_sleep(1000);
	}

}
Any advice would be greatly appreciated, thanks!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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 Sep 30, 2016 9:01 pm

samsonx wrote:Hello 6by9, I have been doing some work trying to get CSI2 video working with the raspi_tc358743.c code and TI's ds90uh940 IC to supply the CSI2 video. I am using the ds90uh929 and ds90uh940 to get HDMI video into the PI. I have hacked up your code and have been able to get good video at 1920x1080p30 and 1280x720p60, though for some reason 720x480p60 is giving me some strange issues. If I set the width and height to 720x480 the video is scrambled..
https://drive.google.com/open?id=0B4Na9 ... m9BLWVFVHM
and for some reason I don't understand setting the width and height to 1440x480 will give me unscrambled video but with two images wide and the height is squished.
https://drive.google.com/open?id=1J57Xe ... D95bDW3_tw

I notice I get the same appearance of the second image if I view 1280x720 HDMI video with MMAL set to 2560x720.
Impressive work to get a different HDMI to CSI chip running on this. Is the chip available on some dev board, or is this your own design?

I haven't looked at your code in detail, but 720 is not a multiple of 32, whilst 1440 is. The stride (format->es->video.width) must be a multiple of 32, and indeed it should be with the VCOS_ALIGN_UP call that is made. I wonder if something is off with that as something slightly wrong is being set for the stride.
I'm a little surprised that doubling the stride to 1440 works, as the CSI2 layer has line start and end markers, and I'd expect it to step forward by the defined stride value at the end of each line.

Your CSI2 image ID of 0 sounds a little odd, but then again there is no defined ID for RGB24 (TC358743 repurposes YUV444 IIRC), so that may just work.

I know I've been saying it for a while and not delivered, but there is the intent to do CSI2 rx properly via V4L2 rather than rawcam. There is a TC358743 driver for V4L2, so it may be beneficial to you to have a look at how that is implemented, and hopefully I'll actually get my side running soon.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Fri Sep 30, 2016 9:55 pm

Thanks, certainly wouldn't have gotten this far without your help! I am using TI Dev boards now (rather expensive unfortunately) but plan on making a board (electrical background and not software) if I can get the software to work properly.

CSI_IMAGE_ID threw me for a loop for a while as video was quite unreliable (almost never worked, and not sure how it ever did for that matter) until I changed the value to 0x00. The only reference I could find in the data sheet for the 940 ic was for a CSI Virtual Channel identifier which was set to 0x00 by default - could be a coincidence, but I assumed this must be the CSI image ID.

Also, I can easily change the encoding of the CSI data, available options are:

Code: Select all

RGB888 image data – using 24-bit container for RGB 24-bpp (default mode)
RGB666 image data
RGB565 image data
YUV4:2:0 image data, Legacy YUV420 8-bit
YUV4:2:0 image data
YUV4:2:2 image data
RAW Bayer, 8-bit image data D[0:7] of Serializer
RAW data; Alignment is configured with CSIIA_{0x6C}_0x09 [4]
RAW Bayer, 10-bit image data D[0:9] of Serializer inputs are used as RAW data; Alignment is configured with CSIIA_{0x6C}_0x09 [4]
RAW Bayer, 12-bit image data D[0:11] of Serializer inputs are used as RAW data; Alignment is configured with CSIIA_{0x6C}_0x09 [4]
YUV420 8-bit (CSPS) 0x1C 00 1001 YUV4:2:0 image data, YUV420 Chroma Shifted Pixel Sampling
Interesting point on the stride being divisible by 32, I may try creating a custom resolution of 704x480 and putting it in the EDID of the 929 board and see if that works out of curiosity. Can you think of a workaround that would allow 720 to work? I tried:

Code: Select all

        output->format->es->video.width = VCOS_ALIGN_UP(720, 16);
with no change. And in fact I tried:

Code: Select all

	output->format->es->video.crop.width = 720;
	output->format->es->video.crop.height = 240;
	output->format->es->video.width = VCOS_ALIGN_UP(1440, 32);
	output->format->es->video.height = VCOS_ALIGN_UP(720, 16);
Which does give a good single image that fills the width of the screen, though only 240 pixels tall.

On the MMAL creation/destroy issue: one thing that came to mind was the CSI2 interface is active at all times on the 940 board, do you think this could cause an issue with enabling and disabling the MMAL connection? Perhaps I will need to first disable the CSI2 video from the 940 board before destroying the connection?

I will take a look at the V4L implementation of the TC358743 (Is this the one your referring to: http://lxr.free-electrons.com/source/dr ... tc358743.c ?)

Again, thanks for the help.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Sat Oct 01, 2016 9:14 pm

Virtual Channel ID is not the same as the image ID.
Image ID is the data type value to be treated as "image data" vs metadata.
If you read the CSI2 spec, then Table 16 / page 84 lists the IDs for use with various RGB formats. RGB888 is listed as 0x24, hence that is what was set up for TC358743 (although you do appear to be able to set the data type ID via I2C registers). The datasheet for your chip may have further detail on how it handles it.
Is that datasheet in the public domain, or only accessible under NDA to those who bought the dev board and/or chips? I couldn't see much about it with a quick Google.

Virtual channels allow multiple streams on the same channel. I would need to check the SoC docs to remind myself if and how that is supported on BCM283x. I'm not aware of many devices that really use it.

Stride issues - if you run "vcgencmd set_logging level=0xc0" before you run your program, and "sudo vcdbg log msg" afterwards, then you will get a load more logging out from the GPU. There may be something more useful in there, particularly there should be a line "set buf params ptr %p-%p, stride %d" every time a buffer is programmed into the peripheral. Is that stride value sensible? It is quite plausible that I've made a blunder.
If you'v got an EDID that sets up 720x480, then I can try that against TC358743 and see what I can get to work properly.

The create/destroy issue is a nasty race condition that I haven't invested the time in to debug as I am still intending to shift this into the Linux kernel. There appear to be two paths that try to return buffers to the client, and both manage to run and screw up buffer management lists under some conditions.
The critical thing generally is to disable the output port of the rawcam component before destroying it - I really ought to add a signal handler to the test app, but have never got there. Ctrl-C the app and it will almost always fail. Let it run to completion, and it will generally run multiple times.

In this case, if there are things that you can't discuss on a public forum then do PM me. But please do share whatever you can for the benefit of others.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Sat Oct 01, 2016 10:24 pm

Here is the toshiba EDID modified to only contain 720x480p60 if you have time to give it a try:

Code: Select all

"\x00\xFF\xFF\xFF\xFF\xFF\xFF\x00\x52\x62\x88\x88\x00\x88\x88\x88"
"\x1C\x15\x01\x03\x80\x00\x00\x78\x0A\xEE\x91\xA3\x54\x4C\x99\x26"
"\x0F\x50\x54\x00\x00\x00\x01\x01\x01\x01\x01\x01\x01\x01\x01\x01"
"\x01\x01\x01\x01\x01\x01\x8C\x0A\xD0\x8A\x20\xE0\x2D\x10\x10\x3E"
"\x96\x00\x13\x8E\x21\x00\x00\x1E\x00\x00\x00\xFC\x00\x54\x6F\x73"
"\x68\x69\x62\x61\x2D\x48\x32\x43\x0A\x20\x00\x00\x00\xFD\x00\x3B"
"\x3D\x0F\x2E\x0F\x00\x0A\x20\x20\x20\x20\x20\x20\x00\x00\x00\x10"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xC8"
I ran the logging as you said and am seeing this for the stride value:

Code: Select all

259040.031: set buf params ptr fd3f18a0-fd4f44a0, stride 2208
which does not seem sensible to me, but perhaps I am not understanding what it means, I have the full log but cannot attach it, I can PM it to you if you would like.

The datasheets for DS90UH940 and DS90UH929 are public domain:
http://www.ti.com/lit/ds/symlink/ds90uh940-q1.pdf
http://www.ti.com/lit/ds/snls458/snls458.pdf

Thanks again!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Sun Oct 02, 2016 6:43 am

2208 = 736 * 3.
736 being 720 rounded up to a multiple of 32. 3 as rgb888 is 24 bits (3 bytes) per pixel. That sounds reasonable to me.

I'll try your edid on the tosh chip when I get a chance and see if there is something obvious going on.
Cheers for the datasheet link - the Toshiba one is restricted for some daft reason. You'd think they would want you to buy and use their chip, but seemingly not.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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

Sun Oct 02, 2016 5:34 pm

Reading the 940 datasheet, 8.4.5 "MIPI CSI-2 Output Data Formats" lists the CSI-2 data types that are the required values for the image_id field.
As expected, RGB888 maps through to 0x24. I couldn't say why that wasn't working for you.

Reading further I see the top 2 bits of that field contain the virtual channel value. As I've said, I've almost never seen those seriously used. I've almost always seen 0x2A or 0x2B or Bayer raw 8 and raw 10, but that's because I'm normally dealing with Bayer sensors.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Sun Oct 02, 2016 6:02 pm

6by9 wrote:Reading the 940 datasheet, 8.4.5 "MIPI CSI-2 Output Data Formats" lists the CSI-2 data types that are the required values for the image_id field.
As expected, RGB888 maps through to 0x24. I couldn't say why that wasn't working for you.

Reading further I see the top 2 bits of that field contain the virtual channel value. As I've said, I've almost never seen those seriously used. I've almost always seen 0x2A or 0x2B or Bayer raw 8 and raw 10, but that's because I'm normally dealing with Bayer sensors.
Very odd as if I set it to 0x24 I just get a black screen when viewing 1280x720, setting to 0x00 gives me good video every time. Perhaps I should try some of the other encodings and see what happens. Is there one that you recommend?

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Thu Oct 06, 2016 1:53 am

The BGR888 format that the data tends to be received from the Toshiba chip in isn't widely supported on the GPU, so there's some magic required. The Foundation demo is using the camera ISP hardware as format conversion to get it into YUV that can be used by the rest of the system.
Hi 6by9, I see you mentioned that BGR888 (MMAL_ENCODING_BGR24) isnt widely supported by the GPU, but YUV is.. which of the following formats would be ideal to use with the GPU?

Code: Select all

#define MMAL_ENCODING_I420             MMAL_FOURCC('I','4','2','0')
#define MMAL_ENCODING_I420_SLICE       MMAL_FOURCC('S','4','2','0')
#define MMAL_ENCODING_YV12             MMAL_FOURCC('Y','V','1','2')
#define MMAL_ENCODING_I422             MMAL_FOURCC('I','4','2','2')
#define MMAL_ENCODING_I422_SLICE       MMAL_FOURCC('S','4','2','2')
#define MMAL_ENCODING_YUYV             MMAL_FOURCC('Y','U','Y','V')
#define MMAL_ENCODING_YVYU             MMAL_FOURCC('Y','V','Y','U')
#define MMAL_ENCODING_UYVY             MMAL_FOURCC('U','Y','V','Y')
#define MMAL_ENCODING_VYUY             MMAL_FOURCC('V','Y','U','Y')
#define MMAL_ENCODING_NV12             MMAL_FOURCC('N','V','1','2')
#define MMAL_ENCODING_NV21             MMAL_FOURCC('N','V','2','1')
#define MMAL_ENCODING_ARGB             MMAL_FOURCC('A','R','G','B')
#define MMAL_ENCODING_RGBA             MMAL_FOURCC('R','G','B','A')
#define MMAL_ENCODING_ABGR             MMAL_FOURCC('A','B','G','R')
#define MMAL_ENCODING_BGRA             MMAL_FOURCC('B','G','R','A')
#define MMAL_ENCODING_RGB16            MMAL_FOURCC('R','G','B','2')
#define MMAL_ENCODING_RGB24            MMAL_FOURCC('R','G','B','3')
#define MMAL_ENCODING_RGB32            MMAL_FOURCC('R','G','B','4')
#define MMAL_ENCODING_BGR16            MMAL_FOURCC('B','G','R','2')
#define MMAL_ENCODING_BGR24            MMAL_FOURCC('B','G','R','3')
#define MMAL_ENCODING_BGR32            MMAL_FOURCC('B','G','R','4')
I tried:

Code: Select all

#define ENCODING MMAL_ENCODING_YUYV  
#define CSI_IMAGE_ID 0x1e
but get the following error with trying to start the CSI stream:

Code: Select all

mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: output p_fmt_commit...
mmal: buffer size is 4177920 bytes, num 8
mmal: Create connection....
mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0xde2c30 (EINVAL)
mmal: mmal_connection_create: format not set on input port
mmal: mmal_connection_destroy_internal: connection vc.ril.rawcam:out:0/vc.ril.video_render:in:0 could not be cleared
mmal: All done. Start streaming...
Is it even worth trying different encodings or should BGR888 just be OK? I am a bit bewildered by all of the different encoding formats and trying to line them up with the DS90UH940 datasheet.

Thanks!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7903
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 Oct 06, 2016 9:37 am

samsonx wrote:Hi 6by9, I see you mentioned that BGR888 (MMAL_ENCODING_BGR24) isnt widely supported by the GPU, but YUV is.. which of the following formats would be ideal to use with the GPU?

I tried:

Code: Select all

#define ENCODING MMAL_ENCODING_YUYV  
#define CSI_IMAGE_ID 0x1e
but get the following error with trying to start the CSI stream:

Code: Select all

mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0xde2c30 (EINVAL)
mmal: mmal_connection_create: format not set on input port
Is it even worth trying different encodings or should BGR888 just be OK? I am a bit bewildered by all of the different encoding formats and trying to line them up with the DS90UH940 datasheet.
http://fourcc.org/yuv.php and http://fourcc.org/rgb.php for a description of each encoding.
Each component does advertise the list of encodings supported on each port via MMAL_PARAMETER_SUPPORTED_ENCODINGS - see https://github.com/raspberrypi/userland ... til.c#L409 where that is used to detect old vs new firmware RGB888/BGR 888 swap fix.

I420 is the almost universally supported format on the GPU. That is YUV 4:2:0 (chroma subsampled by 2 both horizontally and vertically) as three consecutive planes. That doesn't work with streamed formats from things such as image sensors as they then have to buffer an entire image internally.
YUYV is YUV 4:2:2 (chroma subsampled horizontally only), and then the chroma is interleaved with the luma. That removes almost all the buffering requirements, but again isn't a brilliantly supported format on the GPU (camera output ports, and image_encode input ports are I think the only ones).

Whether BGR888 is right for your application is something that only you can decide. What are you wanting to do with the received data?

In my "work in progress" pile is the vc.ril.isp component. That wraps the Image Sensor Pipeline hardware block of the SoC which is normally used for the camera. I haven't pushed any of my more recent updates to be released, but I thought the released code should have RGB888/BGR888 to I420 working. I had tried pushing an update to raspi_tc358743 that plumbed in that component and produced I420, but reverted it as others said it was failing.
There is another use case that vc.ril.isp could be useful for, so I'm working on it at the moment (spare time only - I'm not employed by Pi Towers). I'll fish out the tc358743 board and see if I can get it working properly, and get my updates released.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Mon Oct 10, 2016 2:11 am

6by9 wrote: Whether BGR888 is right for your application is something that only you can decide. What are you wanting to do with the received data?

In my "work in progress" pile is the vc.ril.isp component. That wraps the Image Sensor Pipeline hardware block of the SoC which is normally used for the camera. I haven't pushed any of my more recent updates to be released, but I thought the released code should have RGB888/BGR888 to I420 working. I had tried pushing an update to raspi_tc358743 that plumbed in that component and produced I420, but reverted it as others said it was failing.
There is another use case that vc.ril.isp could be useful for, so I'm working on it at the moment (spare time only - I'm not employed by Pi Towers). I'll fish out the tc358743 board and see if I can get it working properly, and get my updates released.
Hi 6by9, thanks for the useful links about the encoding types!

The end goal is to be able to preview HDMI video, as well as save the video to disk as mp4 and potentially even steam the video to rtsp (or other) -- I am not sure the PI is up to doing all three at once, but that would be ideal.

I have started to play around with MMAL components and connections to see if I can get the vc.ril.resize component piped in-between the rawcam and render components... sounds reasonable but think there is an issue related to the encoding expected by the vc.ril.resize component.. Do you have experience using vc.ril.resize? I would like to use the resizer to scale the rawcam output to a different resolution and then display that with the render component.

I have created the resizer component and setup its format and have an issue when enabling the rawcam to resizer connection..

Code: Select all

mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable resizer....
mmal: output p_fmt_commit...
mmal: buffer size is 1036800 bytes, num 8
mmal: Setting resizer input port format
mmal: Setting resizer output port format
mmal: rawcam encoding is 861030210
mmal: resizer input encoding is 808596553
mmal: resizer output encoding is 808596553
mmal: render input encoding is 808596553
mmal: Create connections....
mmal: Create connection rawcam output to resizer input....
mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x11a1cb0 (EINVAL)
mmal: mmal_connection_create: format not set on input port
mmal: mmal_connection_destroy_internal: connection vc.ril.rawcam:out:0/vc.ril.resize:in:0 could not be cleared
mmal: Create connection resizer output to render input....
mmal: Enable connection[0]...
mmal: buffer size is 1036800 bytes, num 8
If I change the rawcam component to MMAL_ENCODING_I420 indeed the connection between the rawcam and resizer is made without error but then I get a an error when trying to enable the connection is enabled.

Code: Select all

mmal: Set pack to 0, unpack to 0
mmal: Enable rawcam....
mmal: Enable resizer....
mmal: output p_fmt_commit...
mmal: buffer size is 1187720960 bytes, num 8
mmal: Setting resizer input port format
mmal: Setting resizer output port format
mmal: rawcam encoding is 808596553
mmal: resizer input encoding is 808596553
mmal: resizer output encoding is 808596553
mmal: render input encoding is 808596553
mmal: Create connections....
mmal: Create connection rawcam output to resizer input....
mmal: Create connection resizer output to render input....
mmal: Enable connection[0]...
mmal: buffer size is 1187720960 bytes, num 8
mmal: mmal_vc_port_enable: failed to enable port vc.ril.resize:in:0(I420): ENOMEM
mmal: mmal_port_enable: failed to enable connected port (vc.ril.resize:in:0(I420))0x10bbcb0 (ENOMEM)
mmal: mmal_connection_enable: output port couldn't be enabled
mmal: Enable connection[1]...
mmal: buffer size is 1187720960 bytes, num 4
When you mentioned plumbing in a connection that would convert the encoding to I420, which did you use, vc.video_convert? I can't seem to find much documentation on about the various types of components.

Thanks!

samsonx
Posts: 16
Joined: Tue Sep 13, 2016 12:25 am

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

Tue Oct 11, 2016 2:24 am

A little bit of progress on this using mmal_get_parameter(MMAL_PARAMETER_SUPPORTED_ENCODINGS). I do see there is is a mismatch is supported encodings between the resizer component and rawcam. Does anyone have some advice for a component that can convert one of rawcams supported outputs to the resizers supported inputs?

Code: Select all

mmal: rawcam supported encodings:
mmal: MMAL_ENCODING_YUYV
mmal: MMAL_ENCODING_YVYU
mmal: MMAL_ENCODING_UYVY
mmal: MMAL_ENCODING_VYUY
mmal: MMAL_ENCODING_BGR24
mmal: MMAL_ENCODING_RGB24
mmal: resizer input supported encodings:
mmal: MMAL_ENCODING_RGBA
mmal: MMAL_ENCODING_BGRA
mmal: MMAL_ENCODING_RGB16
mmal: MMAL_ENCODING_I420
mmal: resizer output supported encodings:
mmal: MMAL_ENCODING_RGBA
mmal: MMAL_ENCODING_BGRA
mmal: MMAL_ENCODING_RGB16
mmal: MMAL_ENCODING_I420
mmal: render supported encodings:
mmal: MMAL_ENCODING_I420
mmal: MMAL_ENCODING_NV12
mmal: MMAL_ENCODING_I422
mmal: MMAL_ENCODING_I422
mmal: MMAL_ENCODING_RGB16
mmal: MMAL_ENCODING_RGB24
mmal: MMAL_ENCODING_BGR24
mmal: MMAL_ENCODING_BGRA
mmal: MMAL_ENCODING_RGBA
If anyone is interested, here is the method I used to print the supported encodings for a port (thanks 6by9 :) ):

Code: Select all

void display_supported_encodings(MMAL_PORT_T *port)
{
	
	#define MAX_ENCODINGS_NUM 20
	typedef struct {
		MMAL_PARAMETER_HEADER_T header;
		MMAL_FOURCC_T encodings[MAX_ENCODINGS_NUM];
	} MMAL_SUPPORTED_ENCODINGS_T;

	
   MMAL_SUPPORTED_ENCODINGS_T sup_encodings = {{MMAL_PARAMETER_SUPPORTED_ENCODINGS, sizeof(sup_encodings)}, {0}};
   if (mmal_port_parameter_get(port, &sup_encodings.header) == MMAL_SUCCESS)
   {
      int i;
      int num_encodings = (sup_encodings.header.size - sizeof(sup_encodings.header)) /
          sizeof(sup_encodings.encodings[0]);
      for (i=0; i<num_encodings; i++)
      {
         switch (sup_encodings.encodings[i])
         {
			case MMAL_ENCODING_I420:
				vcos_log_error("MMAL_ENCODING_I420");
			break;
			case MMAL_ENCODING_I420_SLICE:
				vcos_log_error("MMAL_ENCODING_I420_SLICE");
			break;
			case MMAL_ENCODING_YV12:
				vcos_log_error("MMAL_ENCODING_YV12");
			break;
			case MMAL_ENCODING_I422:
				vcos_log_error("MMAL_ENCODING_I422");
			break;
			case MMAL_ENCODING_I422_SLICE:
				vcos_log_error("MMAL_ENCODING_I422_SLICE");
			break;
			case MMAL_ENCODING_YUYV:
				vcos_log_error("MMAL_ENCODING_YUYV");
			break;
			case MMAL_ENCODING_YVYU:
				vcos_log_error("MMAL_ENCODING_YVYU");
			break;
			case MMAL_ENCODING_UYVY:
				vcos_log_error("MMAL_ENCODING_UYVY");
			break;
			case MMAL_ENCODING_VYUY:
				vcos_log_error("MMAL_ENCODING_VYUY");
			break;
			case MMAL_ENCODING_NV12:
				vcos_log_error("MMAL_ENCODING_NV12");
			break;
			case MMAL_ENCODING_NV21:
				vcos_log_error("MMAL_ENCODING_NV21");
			break;
			case MMAL_ENCODING_ARGB:
				vcos_log_error("MMAL_ENCODING_ARGB");
			break;
			case MMAL_ENCODING_RGBA:
				vcos_log_error("MMAL_ENCODING_RGBA");
			break;
			case MMAL_ENCODING_ABGR:
				vcos_log_error("MMAL_ENCODING_ABGR");
			break;
			case MMAL_ENCODING_BGRA:
				vcos_log_error("MMAL_ENCODING_BGRA");
			break;
			case MMAL_ENCODING_RGB16:
				vcos_log_error("MMAL_ENCODING_RGB16");
			break;
			case MMAL_ENCODING_RGB24:
				vcos_log_error("MMAL_ENCODING_RGB24");
			break;
			case MMAL_ENCODING_RGB32:
				vcos_log_error("MMAL_ENCODING_RGB32");
			break;
			case MMAL_ENCODING_BGR16:
				vcos_log_error("MMAL_ENCODING_BGR16");
			break;
			case MMAL_ENCODING_BGR24:
				vcos_log_error("MMAL_ENCODING_BGR24");
			break;
			case MMAL_ENCODING_BGR32:
				vcos_log_error("MMAL_ENCODING_BGR32");
			break;
		 }
      }
   }
}

Return to “Graphics, sound and multimedia”