[FFmpeg-devel] [RFC] An hash table container in libavutil?
Fri May 23 01:27:41 CEST 2008
This is the long story, skip to the last paragraph if you when you get
Yesterday I discovered another in av_set_string(), for example when we
ffmpeg -bt 101-1
it fails with an out of range error message (this is because the
string +101-1 is tokenized, the bt value is set to 101 then to -1,
that is the string 101-1 isn't evaluated globally but only the last
"token" is set).
I thought a good solution could be to implement a separate switch
case for FF_OPT_FLAGS strings and for numbers, in the latter case would
be fine to just evaluate the string with ff_eval2(), the only problem
is that we have to put in the list of constants and their values the
named values and the custom default/min/max values for the option.
So I thought an hash table dynamically extensible with those elements
(name + value) instead of the different arrays const_values and
const_names would be nice.
An hash table also could also improve the performance of the av_*_opt
operations, for example the static array could be loaded in an hash
table, the every look-up operation would have an execution time of O(1)
rather than the current O(n).
Such use of an hash table also would improve the interface of eval
(think for example at ratecontrol.c:get_qscale since names and values
would be connected in a immediate fashion), for example an hypotetical
ff_eval3 could then look like this:
double ff_eval3(const char *s, AVHash *constants, AVHash* funcs1,
AVHash *funcs2, void *opaque, const char **error);
I'm attaching an interface I wrote some time ago, let me know if you
think it could result useful in ffmpeg (for what regards the
av_set_string() problem, I'll try to look meaningwhile for a simpler
FFmpeg = Furious and Friendly Minimalistic Porno ExchanGer
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4244 bytes
Desc: not available
More information about the ffmpeg-devel