After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 751554 - GstVideoEncoder could expose a "max-keyframe-distance" property
GstVideoEncoder could expose a "max-keyframe-distance" property
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-06-26 17:39 UTC by Mathieu Duponchelle
Modified: 2018-11-03 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mathieu Duponchelle 2015-06-26 17:39:46 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 ?
Comment 1 Olivier Crête 2015-06-26 18:19:55 UTC
++++ !!! I'm massively in favour of this and other efforts to standardise our encoder properties where possible
Comment 2 Sebastian Dröge (slomo) 2015-06-28 10:12:10 UTC
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.
Comment 3 Mathieu Duponchelle 2015-06-28 14:37:47 UTC
(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 :)
Comment 4 Sebastian Dröge (slomo) 2015-06-28 14:38:55 UTC
Oh, usually our keyframe distance properties are in frames, not seconds ;)
Comment 5 Mathieu Duponchelle 2015-06-28 14:55:24 UTC
OK, but yeah that's the point of that new property :)
Comment 6 Nicolas Dufresne (ndufresne) 2015-06-30 01:38:19 UTC
And how do you implement that when you don't know the framerate (e.g. RTP) ?
Comment 7 Tim-Philipp Müller 2015-06-30 13:42:21 UTC
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).
Comment 8 GStreamer system administrator 2018-11-03 11:38:53 UTC
-- 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.