GNOME Bugzilla – Bug 628764
[videorate] add new option for max frame rate
Last modified: 2011-06-15 17:42:45 UTC
In some situations there is good to work with variable frame rate. But we need to be sure we have not too match frames. So we will have for example 1-15 fps and every thing over should be dropped.
Created attachment 169478 [details] [review] vfr-max-mode.patch v1 This my patch what add this option.
Created attachment 169481 [details] [review] git ready patch
i didn't noticed new videomaxrate plugin. There is no need of this patch anymore
Maybe the videomaxrate plugin should be merged into videorate. That said, videomaxrate works a bit differently, it give you a max average frame rate (so it doesn't guarantee that the time between two frames is less than framerate/1). If you use the naive approach (just drop frames but not duplicate), you end up with the risk that if you start with 11fps but want 10fps, it may instead drop 50% of the frames (because the time between two incoming frame is always a bit more than 1/10s) and you end up with 6 fps.
Merging videorate and videomaxrate makes sense IMHO
(In reply to comment #4) > Maybe the videomaxrate plugin should be merged into videorate. That said, > videomaxrate works a bit differently, it give you a max average frame rate (so > it doesn't guarantee that the time between two frames is less than > framerate/1). If you use the naive approach (just drop frames but not > duplicate), you end up with the risk that if you start with 11fps but want > 10fps, it may instead drop 50% of the frames (because the time between two > incoming frame is always a bit more than 1/10s) and you end up with 6 fps. I can't reproduce what you write in thew praxis. Here i use this pipeline, but i still get about 9-10fps on output gst-launch v4l2src -v ! videorate ! video/x-raw-yuv,width=320,high=240,framerate=11/1 ! ffmpegcolorspace ! videorate vfr-max-mode=1 ! video/x-raw-yuv,framerate=10/1 ! fpsdisplaysink my patch work just fine for me. Can you please take a look in it?
For some reason, it just works as you claim. But I have a gut feeling that there is something wrong in there, but maybe I'm just wrong. If others like it, the "vfr-max-mode" property probably needs a better name like "no-duplicates" or "drop-only" or something. The other thing that annoys me with using videorate is that it introduces an extra frame of useless latency (since in the live case, we can just drop the next frame anyway).
Created attachment 187022 [details] [review] videorate: optionally only drop frames to ensure max frame rate Patch as provided above, adjusted with minor decorative edits and renaming of property as suggested above. AFAICS, this method should arrange for the desired frame rate, of course provided the input frame rate at least sufficiently reaches that desired frame rate.
Created attachment 187023 [details] [review] videorate: optionally ensure max average framerate To allow for variation in taste, this patch essentially merges videomaxrate (max average framerate approach) into videorate.
commit eba4a948fb28216390bd66fe0e890086007196b3 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Mon May 2 11:43:38 2011 +0200 videorate: optionally ensure maximum average output frame rate See #628764. commit 1e092720248afd8f1273690a6ec431a4ae4cb56e Author: Alexey Fisher <bug-track@fisher-privat.net> Date: Fri Apr 29 14:58:02 2011 +0200 videorate: optionally only drop frames to ensure maximum frame rate This adds option to arrange for maximal allowed variable frame rate. Fixes #628764.