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.)
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
@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!
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.
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.
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?
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.