[Bug 703093] videomeasure: port to 1.0

[GStreamer (GNOME Bugzilla)]

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

Mathieu Duponchelle <mduponchelle1 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mduponchelle1 at gmail.com

--- Comment #20 from Mathieu Duponchelle <mduponchelle1 at gmail.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #18)
> I spent few minutes to make a comparison. I think stating that IQA covers
> videomeasurement is an over statement. Here's what I found:
> 
> - IQA pretends but don't really seem to support 1+N streams

That is not the case. If you read a little better you'll see it does output
messages for each pad, the implementation is very straightforward that's easy
enough to figure.

> - IQA is strictly DSSIM and does not help adding anything else

I don't know what help you'd expect, you get n video frames and the ability to
post messages, if you have more suggestions don't hesitate.

> - IQA does not support non RGB output

That's not the problem here, but OK

> 
> Without addressing that, why do we trash this effort ? -bad is like the
> staging area, I believe both solution can coexist until we have a full
> featured solution.

I never said *anything* about trashing one solution or another, I just
implemented this one year ago, dssim works measurably (no pun intended) better
than what we had previously in the videomeasure element, as the correlation
against annotated datasets is significantly higher, while being 15 times
faster.

Inheriting from videoaggregator and wrapping dssim means the actual code is
less than 400 lines, which also counts as a win in my book.

Now I proposed this against *-bad*, intentionally because I had neither
proof-tested it extensively, nor tried to implement different metrics in there.
The fact that input is restricted to RGBA because of dssim is indeed
inconvenient, anyway I'm pretty sure all the state of the art algorithms can be
implemented against RGBA images.

Anyway, here's my personal opinion:

All contributions to -bad should be welcome with open arms, as in the case of
an API breakage (gst 2.0), porting the -bad plugins isn't an obligation, right?

I tend to think the solution I picked has the advantage of simplicity, and
ideally will implement more metrics, now there is the constraint of input
formats, which isn't easily solvable, and I don't have anything against people
doing their own thing, as long as they let me do mine too!

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