More Clarity on H.265 Encode Parameters?

Looking at the exposed parameters for the accelerated H.265 compression (omxh265enc) the actions of some are clear (e.g. bitrate) but others less so… (e.g. quant-i-frames, quant-p-frames, quant-b-frames, SliceIntraRefreshEnable… )

Is there a reference that goes beyond the limited clues in the API?

My org’s taken an interest in TX1’s H2.65 encode ability. I want to demonstrate it running at its best for our objectives (e.g. high compression even if this trades off latency.)

Thanks!

I haven’t yet exhausted all the experiments I intend, but tentatively the accelerated H.265 compression (omxh265enc) seems unresponsive to bitrate goals when constant bitrate (control-rate=2) is selected.

It also seems to be numb to different settings of the quality-level parameter (range 0 - 2.)

It’s possible that other choices I’m making override or nullify my selections above… it hard to know without clearer definitions for these.

Also, like another experimenter, I’ve never see the compressor emit a “B” frame. I get I-frames at the configured iframeinterval and all P-s in-between.

Finally, I wonder if scene-change detection is configurable, or even feasible for this implementation? Without, fresh scenes are smeary and blocky until the next I-frame.

These specifics aside: how can we cast some light on this implementation?

I am also in a similar situation. I found that setting iframeinterval has no effect on omxh265enc. The iframe interval is always 60 in the encoded stream. omxh264enc does seem to honor iframeinterval setting properly.

Please run following command for explanation of encoder parameters:
gst-inspect-1.0 omxh265enc

It will list out the details of the properties which can be set.

Below are the details of encoder parameters of omxh265enc plugin:

Control-rate- To set CBR/VBR bitrate control methods
Bitrate – Target bitrate set while encoding
Iframeinterval – Intra frame occurrence frequency
Quality-level – Range 0-2 – Higher the better quality
SliceIntrarefreshEnable – Enable slice intra refresh while encoding
SliceIntrarefreshInterval – Start refreshing the slices after an interval specified by parameter SliceIntrarefreshInterval
Vbv-size – virtual buffer size
Temporal trade off – Temporally frame dropping mechanism
Bit-packetization: Flag to indicate whether the distance between two slices is in terms of number of MBs or number of bits.(It will need additional property(Slice header spacing) to be installed, so can not be used as of now)
Force-IDR - To set current frame as Intra frame while encode

Thanks

@kayccc: Unfortunately the information exposed by gst-inspect-1.0 is not enough!

I confirm rdavis’ conclusion that quality-level has literally no impact on the encoding (at least with default settings). Our test-streams result in both binary-equal (decompressed) frames and binary-equal compressed files regardless the Quality-Level used for encoding.

This is clearly either a bug or lacking documentation!

Hi dummy7232374182374_everything_meaningful_was_taken,
Please try to set qpfactor and qualitylevel in /etc/enctune.conf
https://devtalk.nvidia.com/default/topic/973295/jetson-tx1/constant-bitrate-help/post/5010964/#5010964

Thank you for the quick hint, though homeopathic.

While changing [I|P][Min|Max]QP values does change the outcome, only changing QualityLevel (from “high” to “low”, e.g.) in /etc/enctune.conf (For H265: Settings_1080P) doesn’t affect the outcome neither.

Hi dummy7232374182374_everything_meaningful_was_taken,
Please try to set preset-level:
$ gst-launch-1.0 nvcamerasrc num-buffers=90 ! ‘video/x-raw(memory:NVMM),width=(int)1920,height=(int)1080’ ! omxh264enc preset-level=1 bitrate=8000000 ! qtmux ! filesink location=p1.mp4

Preset Level 1 = Quality Level low
Preset Level 2 = Quality Level medium
Preset Level 3 = Quality Level high

Attach snapshots from videos with preset level 1 and preset level 3 for reference.


I don’t want to be rude, but you don’t understand my concern at all and it is very frustrating!!! :(

I had already figured out that PresetLevel does change the outcome.

HOWEVER: When people ask for more CLARITY on PARAMETERS we only get a dump of gst-inspect (which IS actually the insufficient documentation). Moreover: gst-inspect exposes TWO (2) separate paramters: QualityLevel AND PresetLevel. One of both (notably QualityLevel) does not have any effect on the encoded data.

So PLEASE: Communicate, publish, and document that (if?) QualityLevel is ignored and that there will be either a fix or it will be removed from module omxh265enc.

Good to hear that you make a solution. If you catch new issues of functionality, please feel free to trigger a new thread.

We are continuing to improve the documentary and thanks for your suggestion.

As noted in post #3 above itseems that the iframeinterval has no effect on omxh265enc. Can someone from Nvidia please confirm that this considered a bug and will be fixed in a newer release? Or otherwise document and publish that this will be removed from module omxh265enc?

Thanks.

Confirm it is fixed in new release.

Dear DaneLLL,
How can I get new release of omxh265enc, now when I check with

gst-inspect-1.0 omxh265enc

The source release date is 2014-02-08
Thank,

It has not been released yet.

Dear DaneLLL,
Could you please provide us information about schedule to release new omxh265enc version?
Thanks.

The next release package is in the last mile, and it will be published once everything goes well.

Thanks

Please try r28.1

Hi,

I can confirm that R28.1 does indeed support the iframeinterval parameter correctly, at least for values 30 (1 keyframe per second when shooting 30fps) and 300. Haven’t tested outside that range.

So thanks very much for solving that one!

Regards,
Timo

p.s. it is slightly annoying that the version information still reports 1.0.0.1, dated 2014-02-08; this could be due to original (upstream) gstreamer sources, however also the “Factory Details” do not seem to reveal any version information.

We cannot arbitrarily modify the revision of 3rd party code. For our BSP release revision, you can check
$ head -1 /etc/nv_tegra_release