GNOME Bugzilla – Bug 751554
GstVideoEncoder could expose a "max-keyframe-distance" property
Last modified: 2018-11-03 11:38:53 UTC
From IRC: <Mathieu_Du> Hm I've got an interesting issue here, so youtube says "key-int-max" should be half the framerate, I'd like to have that in the preset, seems a bit involved tho <__tim> you can't really specify that currently <Mathieu_Du> Yep that's understandable <Mathieu_Du> Alternate solution would be to have a key-int-max / framerate ratio in x264enc, but that might be a little too specific ? <Mathieu_Du> (as a new prop) <__tim> max-keyframe-distance in nanosecs perhaps [snip] __tim> the encoder base class can probably "enforce" that even if the encoder supports forcing keyframes [snip] <__tim> the encoder can still set key-int-max based on that property <__tim> the base class handling is just a fallback really So yep, being able to specify a maximum keyframe distance in nanoseconds would be a valuable addition, and putting that in the baseclass would indeed allow enforcability, what do you folks think ?
++++ !!! I'm massively in favour of this and other efforts to standardise our encoder properties where possible
We need to check if any subclass already uses this property name, and if so choose a different one. Probably prefix it with some namespace thing. How would you support the youtube requirement with this though? You still need to know the framerate, and that doesn't seem like something that is easily possible via presets currently.
(In reply to Sebastian Dröge (slomo) from comment #2) > How would you support the youtube requirement with this though? You still > need to know the framerate, and that doesn't seem like something that is > easily possible via presets currently. Well half the framerate translates pretty easily to 0.5 second :)
Oh, usually our keyframe distance properties are in frames, not seconds ;)
OK, but yeah that's the point of that new property :)
And how do you implement that when you don't know the framerate (e.g. RTP) ?
I think if some subclass already uses a property named like that it's not a problem, it will just override the base class property. vtenc has similar properties called "max-keyframe-interval-duration" and "max-keyframe-interval", see http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/sys/applemedia/vtenc.c?id=b88e4304f1ddb4441cc076762010d150b72a4252 I think specifying the interval/distance in time is more natural and versatile than in frames though, and I'd claim that most people actually want to specify it in time. Nicolas: it depends on the encoder API. If it provides a way to specify the max interval in time, then it's not a problem. Otherwise the base class can probably just use the force-keyframe API to make sure a new keyframe is forced when needed (it knows when the last keyframe came out; it knows about pending frames inside the encoder (and can probably assume that it's all a single GOP, no? Details tbd).
-- 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/201.