Move NV21 colorspace treatment from VideoCapture java to C++

media/video/capture/android/imageformat_list.h

Index: media/video/capture/android/imageformat_list.h
diff --git a/media/video/capture/android/imageformat_list.h b/media/video/capture/android/imageformat_list.h
new file mode 100644
index 0000000000000000000000000000000000000000..a20b0f2f480441fafbf69c9733f6b6bd750ed97f
--- /dev/null
+++ b/media/video/capture/android/imageformat_list.h
@@ -0,0 +1,22 @@
+// Copyright 2013 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// This file intentionally does not have header guards, it's included
+// inside a macro to generate enum and a java class for the values.
+
+#ifndef DEFINE_ANDROID_IMAGEFORMAT
+#error "DEFINE_ANDROID_IMAGEFORMAT should be defined."
+#endif
+
+// Android graphics ImageFormat mapping, see reference in:
+// http://developer.android.com/reference/android/graphics/ImageFormat.html
+
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_JPEG, 0)

[Ami GONE FROM CHROMIUM, 2013/09/12 17:03:16]

If you used the same values that the SDK uses (i.e. JPEG is 256, UNKNOWN is 0,
and so on) then VideoCapture.getColorspace() would become a simple
return mImageFormat;
instead of the switch that it is today.

[mcasas, 2013/09/13 08:42:51]

Do you mean hardcoding the ImageFormat.xyz values??? If I were to do so I
wouldn't need all this JNI bricolage :) :)

[Ami GONE FROM CHROMIUM, 2013/09/13 17:29:00]

You are already hard-coding values of -1..5.  I'm just suggesting that instead
of inventing your own values for these things here, you should use the same ones
the SDK uses; benefits of doing so include:
1) VideoCapture.getColorspace() becomes a simple getter instead of a translator
2) Lower likelihood of e.g. confusing 0==UNKNOWN in the SDK with 0==JPEG here,
and so on.
Not sure what you mean by that; I think you'll still need the JNI bridging.
(but, of course, if you can avoid that in a way I'm missing, that'd be even
better)

[mcasas, 2013/09/16 08:43:02]

Done not making up new numbers for the imageformats, but I don't think the java
VideoCapture::getColorspace() should be a simple getter: this whole .template
autogeneration is there to ensure that java and c++ use the same values for the
same colorspaces. Note that the ImageFormat constant values _may_ change among
Android API's :(

[bulach, 2013/09/16 08:45:02]

hey Ami, Miguel,

I think I should clarify a bit more here... :)

1) Sharing the same value across java and c++ is indeed convoluted, each
solution we tried was lacking in some aspect.

2) using the same value as the SDK is fine, but not having the map could be
risky: how stable the SDK values are? if the values are stable, then yes, just
using them directly here would be nice! we could potentially have "asserts" in
the java getter (it gets compiled out on Release) to ensure the values are the
same?

3) hopefully this mapping is not in the critical path :) so this provides the
"safest" mechanism of sharing such values.. this pattern is used in other places
too:(https://code.google.com/p/chromium/codesearch#search/&q=java_cpp_template.gypi&sq=package:chromium&type=cs)

+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_NV16, 1)
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_NV21, 2)
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_RGB_565, 3)
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_YUY2, 4)
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_YV12, 5)
+
+DEFINE_ANDROID_IMAGEFORMAT(ANDROID_IMAGEFORMAT_UNKNOWN, -1)