GNOME Bugzilla – Bug 772584
pbutils/h265: add support for the "format range extensions profiles" values
Last modified: 2018-11-03 11:50:39 UTC
gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)Y444" ! x265enc ! fakesink -v gstx265enc.c(785): gst_x265_enc_set_level_tier_and_profile (): /GstPipeline:pipeline0/GstX265Enc:x265enc0: Failed to find correct level, tier or profile in VPS I saw this by trying to encode UYVY with an intermediate videoconvert; i am guessing that videoconvert prefers Y444 ti I420 to preserve data, but x265 apparently doesn't work with Y444 gst-launch-1.0 videotestsrc ! "video/x-raw, format=(string)UYVY" ! queue name=encoder ! videoconvert ! queue ! x265enc ! fakesink -v
So, the problem here is that pbutils only knows how to handle profile_idc between 1 and 3 inclusive where x265 outputs a profile_idc of 4 corresponding to the, "A.3.5 Format range extensions profiles" in the H.265 spec. Now, x265 calls this one "Rext" (from https://github.com/videolan/x265/blob/master/source/encoder/level.cpp#L219) and chooses the exact configuration based on other conditions. Adding a profile_idc == 4 check makes the pipeline above succeed. The question now is what to do about detecting these profiles. Split them properly or just lump them all in together with a 'Rext' profile like x265.
The spec says "profileS", so I guess we should invent different names for them. What does ffmpeg or others do?
x265 invents names (as above). ffmpeg doesn't seem to.
Currently following pipeline will be failed. libx265 produces "main-intra" profile when all-intra encoding case but range-extensions profiles are not defined in codec-utils. gst-launch-1.0 videotestsrc ! x265enc key-int-max=1 ! fakesink This bug seems to related to bug #793876
Created attachment 373929 [details] [review] codec-utils: Add parsing H265 range extensions profiles
Created attachment 373930 [details] [review] tests: pbutils: Add test parsing H265 profiles
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/299.