[Bug 703093] videomeasure: port to 1.0

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=703093

--- Comment #19 from LRN <lrn1986 at gmail.com> ---
IQA can be made to work with some refactoring. Don't try to have a single class
that can do multiple metrics, have multiple classes, like GstIQADSSIM,
GstIQAPSNR, one per metric; that way GstVideoAggregator and its inflexibility
won't be a problem - GstIQAGMS will just have different caps template, one that
accepts YUV instead of RGB.

1+N won't happen that way, but my intention behind having 1+N in videomeasure
was mostly due to performance concerns (SSIM includes a blur pass over each
video stream before comparison; 1+N allows us to do blur of the original stream
once for 1+1 comparison, then re-use it for all other 1+(N-1) comparisons).
Other algorithms don't seem to need that, and DSSIM can't do that, so this is
not something i'd fight about.

I *would* like IQA to be able to push measurements as events, and have a
dedicated element for catching these and dumping them into CSV files. That way
it would be possible to do measurements *entirely* with gst-launch, no need to
write an application to listen for bus messages (where IQA currently sends its
measurements) or dump them to stdout with -m and then have to parse the output.
These approaches are not mutually exclusive, IQA can do both (events and bus
messages).

Stride problems will remain in IQADSSIM, i'll let IQA maintainer handle that.
I'll try to ensure that IQAGMS doesn't have these.

RGB-only output...depends on how much code different IQA classes will have in
common. If they will have common output code, they might all output RGB (a heat
map currently). The code for GMS that i have outputs GRAY8 (just 0..1 mapped
into 0..255, no fancy heatmaps; this can be changed, if needed).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.