GNOME Bugzilla – Bug 757419
openh264enc: add support for cabac entropy coding
Last modified: 2018-11-03 13:42:04 UTC
Created attachment 314569 [details] [review] initial patch openh264 introduced support for cabac entropy coding. Initial patch to add support for cabac to openh264enc plugin, please review
The profile should be negotiated with downstream via caps
(In reply to Sebastian Dröge (slomo) from comment #1) > The profile should be negotiated with downstream via caps For what I understand cabac generate an h264 stream with "high" profile while cavlc a "baseline" profile. I don't think we can have cavlc and high profile or cabac and baseline profile. Do you mean we need to use cabac/cavlc without a property but based on downstream caps or both? we need to mantain compatibility with openh264 version < 1.5? (no cabac there)
(In reply to Nicola from comment #2) > (In reply to Sebastian Dröge (slomo) from comment #1) > > The profile should be negotiated with downstream via caps > > For what I understand cabac generate an h264 stream with "high" profile > while cavlc a "baseline" profile. I don't think we can have cavlc and high > profile or cabac and baseline profile. AFAIK high profile allows cabac and cavlc. And high profile also includes lots of other features that are not in baseline. > Do you mean we need to use > cabac/cavlc without a property but based on downstream caps or both? If downstream wants baseline profile but the property is set, we should either ignore the property or error out. > we need to mantain compatibility with openh264 version < 1.5? (no cabac > there) Yes
Created attachment 314628 [details] [review] patch v2 here are the results with this patch: gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=1 ! fakesink will produce h264 high profile gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=0 ! fakesink will produce h264 baseline profile as before gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=1 ! video/x-h264,profile=baseline ! fakesink will produce baseline profile and entropy coding is resetted to CAVLC with this log baseline profile requested in downstream caps, entropy codec resetted to CAVLC gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=1 ! video/x-h264,profile=high ! fakesink will produce high profile with cabac entropy coding gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=0 ! video/x-h264,profile=high ! fakesink will produce high profile with cavlc entropy coding. Regarding openh264 < 1.4 1) GST_OPENH264_CABAC so the property cannot be setted 2) in negotiate method, negotiation is not allowed and so the profile is setted to baseline since cavlc is the only option
Some corrections: Regarding openh264 < 1.5 1) GST_OPENH264_CABAC is hidden so the property cannot be setted 2) in negotiate method, negotiation is not allowed and so the profile is setted to baseline since cavlc is the only option
Created attachment 314700 [details] [review] patch v3 Minor modification, test with openh264 1.4 too, here are the results gst-inspect-1.0 openh264enc .... .... entropy-coding : Entropy coding mode. CABAC mode require openh264 1.5 or better flags: readable, writable Enum "GstOpenh264encEntropyCodingMode" Default: 0, "CAVLC" (0): CAVLC - Context-adaptive variable-length coding so only CAVLC is possibile gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=1 ! fakesink 0:00:00.025827574 26595 0x163ea70 ERROR GST_PIPELINE grammar.y:454:gst_parse_element_set: could not set property "entropy-coding" in element "openh264enc0" to "1" WARNING: erroneous pipeline: could not set property "entropy-coding" in element "openh264enc0" to "1" and no downstream caps negotiation is possibile (as before this patch) gst-launch-1.0 -v videotestsrc ! openh264enc entropy-coding=0 ! video/x-h264,profile=high ! fakesink ... gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstVideoTestSrc:videotestsrc0: streaming task paused, reason not-negotiated (-4) ...
-- 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-bad/issues/319.