Extra green lines on video

Products Support DragonBoard410c
#1

Hi,

I’m using the D3 Engineering camera mezzanine board with gst to stream to a media server. My issue is there appears to be extra green lines on the stream (ie a 1280x720 stream is now 1280x732). I’ve even manually tried setting the video size in several places and it doesn’t get any better. The green line is there at multiple resolutions but the number of green rows (ie thickness) changes at different resolutions. It also happens when using the videotestsrc which makes me believe it’s the v4l2h264enc ! h264parse as I’ve seen the rest of the bits work well together as well. videotestsrc ! x264enc works without the extra green lines but has constant decoding errors on the receiver side.

sudo media-ctl -d /dev/media1 -l '"msm_csiphy0":1->"msm_csid0":0[1],"msm_csid0":1->"msm_ispif0":0[1],"msm_ispif0":1->"msm_vfe0_pix":0[1]'
sudo media-ctl -d /dev/media1 -V '"ov5640 1-0078":0[fmt:UYVY8_2X8/1280x720 field:none],"msm_csiphy0":0[fmt:UYVY8_2X8/1280x720 field:none],"msm_csid0":0[fmt:UYVY8_2X8/1280x720 field:none],"msm_ispif0":0[fmt:UYVY8_2X8/1280x720 field:none],"msm_vfe0_pix":0[fmt:YUYV8_1_5X8/1280x720 field:none]

gst-launch-1.0 v4l2src device=/dev/video3 ! videoconvert ! v4l2h264enc ! h264parse ! flvmux ! rtmpsink location="rtmp://wowza:1935/live/mystream"

output of the command:

Setting pipeline to PAUSED …
Using mplane plugin for capture
libv4l2: error getting pixformat: Invalid argument
Pipeline is live and does not need PREROLL …
Setting pipeline to PLAYING …
New clock: GstSystemClock
Redistribute latency…

Any help solving this issue is greatly appreciated.

1284×761 233 KB

#2

Edit: This probably won’t work, see the thread below…

There is a way to set image windowing in the register map of the camera driver located in ./drivers/media/i2c/ov5640.c. I haven’t had the time to figure it out myself but maybe you can.

Here is a link to the datasheet for the camera: https://cdn.sparkfun.com/datasheets/Sensors/LightImaging/OV5640_datasheet.pdf

The parameters for the configuration for the image windowing settings are located on page 40. Please post back with any sort of findings on this, I’m really interested in fixing this too!

#3

That is an issue with the encoder driver itself (venus): it also happens when encoding using ffmpeg.

#4

So that means that changing the image windowing parameters in the camera driver will not really do anything to help this?
Is it correct to assume that changing these parameters will only reduce the size of the image captured, and the green line will still be there? Since the green line is being added by the encoder mechanism, and not by the camera itself.

However, another question is whether or not the green line is being caused by the frame not being aligned by 32 lines, so perhaps changing the windowing so that each frame is being properly aligned might help? Or am I way off base on this one?

#5

yep, I think that is exactly what will happen. the green line will still be there IMO.

I use a file with raw frames as input to my encoder in ffmpeg and I see the same effect that you just pointed out so I doubt that changes other than those made in the encoder software itself (venus) can have any positive impact.

I guess you could postprocess the encoded frames and crop them while venus gets fixed.

#6

Thanks for clarification on this.

I can’t get videocrop to operate on the encoded frames. I’m a little green on gstreamer pipelines so I could be using it wrong or just not know what I’m actually supposed to use there.

Thanks for the help so far.

#7

@ldts I was able to replicate the same issue on an ov5645 by adding 1280x720 into the driver’s ov5645_mode_info struct using the regmap for the sxga (1280x960) mode.

This makes me think about the camera being in play here, since I’m asking for a resolution that hasn’t been calculated properly before passing it off to the encoder.

Another question this raises is whether or not this issue happens with all 1280x720 sources?

#8

As @ldts said above, this is a limitation of the current video driver (encoder) which requires height to be a multiple of 32 lines. This limitation is mentioned in our release notes.

i believe there was a fix for this issue, but I don’t remember precisely. I will check the details on it.