Reducing file size in video with gstreamer

[an_actual_toaster]

Hi All,

I have an interesting problem that I think can be solved using only gstreamer, but I’m unsure how.

I am using my Jetson to constantly record 30 minute segments of video onto a hard drive. I’ve noticed that the file size seems to be much larger when recording during the evening (in lowlight situations) compared to when recording during daylight.

For example, a 30 minute recording taken during the day is 700MB. A 30 minute recording taken at lowlight is ~5GB

I’ve looked into the files to see what was happening, and I’ve found the issue. Here is a screenshot from each video file:

As you can see, during low light situations, there is some artifacting going on that makes compression much harder to do, causing the file size to be much larger.

I’m not doing anything fancy with gstreamer, right now I am simply using a v4l2src liike so (in python):

        self.pipeline.add(self.v4l2src)
        self.pipeline.add(self.clockoverlay)
        self.pipeline.add(self.nvvidconv)
        self.pipeline.add(self.omxh265enc)
        self.pipeline.add(self.mp4mux)
        self.pipeline.add(self.filesink)

The artifacting also happens when I stream in this manner:
gst-launch-1.0 v4l2src device=/dev/video2 ! 'video/x-raw, width=2560, height=1440' ! nvvidconv ! omxvp8enc ! rtpvp8pay ! udpsink host=192.168.1.111 port=5000 sync=false async=false

Anyone have any idea how to remove this low light effect so that my file sizes aren’t so huge at night?

[DaneLLL]

Hi,
We have deprecated omx plugins. Please try nvv4l2h265enc and set the property:

  control-rate        : Set control rate for v4l2 encode
                        flags: readable, writable, changeable only in NULL or READY state
                        Enum "GstV4l2VideoEncRateControlType" Default: 1, "constant_bitrate"
                           (0): variable_bitrate - GST_V4L2_VIDENC_VARIABLE_BITRATE
                           (1): constant_bitrate - GST_V4L2_VIDENC_CONSTANT_BITRATE
  qp-range            : Qunatization range for P, I and B frame,
                         Use string with values of Qunatization Range
                         in MinQpP-MaxQpP:MinQpI-MaxQpI:MinQpB-MaxQpB order, to set the property.
                        flags: readable, writable
                        String. Default: null

In low light the scene has more noise which triggers higher bitrate in encoding. Encoding rate is more stable while the scene is clear.

[an_actual_toaster]

Hi @DaneLLL, thanks for the input

EDIT: I’ve got it streaming over the network!

Seems like using qp-range to affect low light behaviour is quite difficult. Do you know of any working parameters that can reduce the effect?

Here is my pipeline:
gst-launch-1.0 v4l2src device=/dev/video2 ! 'video/x-raw, width=2560, height=1440' ! nvvidconv ! nvv4l2h265enc control-rate=1 qp-range="24,24:28,28:30,30" ! rtph265pay ! udpsink host=192.168.1.111 port=5000 sync=false async=false

But there still seems to be a lot of confetti-esque artifacting that drives up the compression size

[DaneLLL]

Hi,
Video quality and bitrate are tradeoff. You would need to adjust the properties to find balance between quality and bitrate. The property qp-range works in VBR mode. Please set control-rate=0 along with it.

[an_actual_toaster]

Hi @DaneLLL

I don’t think it is a h265 compression issue though - when I simply view the video with the following pipeline:

gst-launch-1.0 nvarguscamerasrc ! 'video/x-raw(memory:NVMM), width=3280, height=2464, format=NV12, framerate=(fraction)21/1' ! nvvidconv ! xvimagesink

There is still come level of confetti/artifacting, here is a gif of a screen recording that I took:

anonymous

Is this just something that is always going to happen because of how the IMX219 works?

[an_actual_toaster]

Bump,

Has anyone experienced anything similar?

[DaneLLL]

Hi,
Generally we see more noise in low-light condition. It looks to be the behavior of the sensor(imx219?).

For further improvement, you may consider to check and try other Bayer sensors from our partners. Please check
Jetson Ecosystem | NVIDIA Developer