[libcamera-devel] Magenta boarder appears. HLS streaming of 1920x1080 image from IMX327

[tetsuya.nomura at soho-enterprise.com]

Dear Dave-san

 

Thank you for your prompt reply.

It is reasonable the size is restricted by the unit of macro block.

I’ll check the size again.

 

Best Regards,

 

NOMUR

 

From: Dave Stevenson <dave.stevenson at raspberrypi.com> 
Sent: Monday, September 20, 2021 7:23 PM
To: tetsuya.nomura at soho-enterprise.com
Cc: libcamera devel <libcamera-devel at lists.libcamera.org>
Subject: Re: [libcamera-devel] Magenta boarder appears. HLS streaming of 1920x1080 image from IMX327

 

Hi Nomura

 

On Mon, 20 Sept 2021 at 05:56, <tetsuya.nomura at soho-enterprise.com <mailto:tetsuya.nomura at soho-enterprise.com> > wrote:

Dear Sirs.

 

According to the advice below, I'm sending the script file which I'm seeing the magenta boarder on the image.

https://twitter.com/libcamera/status/1439571268207058949

 



 

The image sensor is IMX327 and driven as IMX290 (dtoverlay=imx290)

I’m not sure it is related but when I set the vertical size to 1088, the boarder disappeared.

Could you confirm the size reported as being encoded by the codec please? Use ffprobe or similar to analyse the stream.

Most video codecs work on macroblocks, which are typically 16x16. 1080 is not a multiple of 16, so it has to pass a cropping rectangle to reflect the active/valid portions within the encoded data.

 

When setting smaller image size such as 1280x720, I don’t see the magenta boarder

720 is a multiple of 16, as is 1088. 

The OS is the current latest LiteOS.

 

It would be great if you give me the advice to solve the symptom.

 

gst-launch-1.0 -v -e \

   libcamerasrc \

   ! video/x-raw,width=1920,height=1080 \

   ! omxh264enc \

   ! queue \

   ! h264parse \

   ! queue \

   ! mpegtsmux \

   ! hlssink max-files=8 \

     target-duration=1 \

     location=/mnt/ram/segment%05d.ts \

     playlist-location=/mnt/ram/output.m3u8 

OpenMax IL is considered deprecated on the Pi. It certainly won't be supported on 64 bit versions of the OS. Use of v4l2h264enc is recommended instead, and it also supports DMABUFs for zero copy of image data.

 

As above, something in the path isn't passing the cropping information, and changing to v4l2h264enc may solve it. IL certainly enforces the source buffer being a multiple of 16 lines in height. The V4L2 encoder doesn't.

 

  Dave

 

Best Regards,

 

NOMURA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20210920/0e76ae8a/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 63106 bytes
Desc: not available
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20210920/0e76ae8a/attachment-0001.jpg>