Gstreamer sink filesize doesn't make sense with framerate

When I increase the framerate of a compressed gstreamer videotestsrc stream, the filesizes go down. I am on a TX1.

Pipeline:

gst-launch-1.0 videotestsrc ! 'video/x-raw, format=I420, width=1504,height=1504,is-live=true, framerate=120/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/120.mp4 -e
<u>Filename   Framerate  Filesize    CaptureTime</u>
30.mp4     30 fps     153.6 Mb    20.2 Sec
60.mp4     60 fps     89.3  Mb    20.1 Sec
90.mp4     90 fps     59.9  Mb    21.1 Sec
120.mp4    120 fps    43.9 Mb     20.0 Sec

Can someone help me understand why this is the case?

Please try

gst-launch-1.0 videotestsrc is-live=true ! 'video/x-raw, format=I420, width=1504,height=1504, framerate=120/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/120.mp4 -e

Thanks for the suggestion. I didn’t realize the is-live cap could be placed outside the cap string. However, I got essentially the same result.

<u>Filename   Framerate  Filesize    CaptureTime</u>
120.mp4    120 fps    44.3 Mb     20.2 Sec

Not sure if this is helpful, but the console output of the pipeline is below:

gst-launch-1.0 videotestsrc is-live=true ! 'video/x-raw, format=I420, width=1504,height=1504, framerate=120/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/120.mp4 -e
Setting pipeline to PAUSED ...
Inside NvxLiteH264DecoderLowLatencyInitNvxLiteH264DecoderLowLatencyInit set DPB and MjstreamingInside NvxLiteH265DecoderLowLatencyInitNvxLiteH265DecoderLowLatencyInit set DPB and MjstreamingPipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
Framerate set to : 120 at NvxVideoEncoderSetParameterNew clock: GstSystemClock
NvMMLiteOpen : Block : BlockType = 8 
===== MSENC =====
NvMMLiteBlockCreate : Block : BlockType = 8 
===== NVENC blits (mode: 1) into block linear surfaces =====

Hi Dan_Goodrick,

Our test result looks good:

Filename   Framerate  Filesize    CaptureTime
30.mp4      30 fps    86.9 MB      19 sec
60.mp4      60 fps    100.4 MB     19 sec
90.mp4      90 fps    100.4 MB     19 sec
120.mp4     120 fps   100.3 MB     19 sec

Test pipeline:

gst-launch-1.0 videotestsrc num-buffers=600 ! 'video/x-raw, format=I420, width=1504,height=1504,is-live=true, framerate=30/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/30.mp4 -e
gst-launch-1.0 videotestsrc num-buffers=1200 ! 'video/x-raw, format=I420, width=1504,height=1504,is-live=true, framerate=60/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/60.mp4 -e
gst-launch-1.0 videotestsrc num-buffers=1800 ! 'video/x-raw, format=I420, width=1504,height=1504,is-live=true, framerate=90/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/90.mp4 -e
gst-launch-1.0 videotestsrc num-buffers=2400 ! 'video/x-raw, format=I420, width=1504,height=1504,is-live=true, framerate=120/1' ! omxh265enc control-rate=2 bitrate=40000000 ! 'video/x-h265, stream-format=(string)byte-stream' ! h265parse ! queue ! matroskamux ! filesink location=Documents/120.mp4 -e

Please try again with my test pipeline and update your result. Thanks!

I would expect the higher frame rate videos to be larger - but the 60, 90 and 120 fps captures are the same size.

The bitrate is 40M bits per second for all cases. If it is 30fps, each frame in average is 40M/30. If it is 120fps, each frame in average is 40M/120.

Of course - the bandwidth is getting saturated so the quality goes down. I should have realized that.