nareshmlx/opencv-pr huggingface dataset:
**File:** modules/videoio/src/cap_obsensor_capture.cpp
**Change Type:** modified
**Context:** PR #23237: videoio: add support for Orbbec Femto Mega RGB-D camera
**Review Line:** 39

**Code Changes:**
```diff
     static const obsensor::StreamProfile depthProfile = {640, 480, 30, obsensor::FRAME_FORMAT_Y16};
-    static const obsensor::StreamProfile gemini2depthProfile = {1280, 800, 30, obsensor::FRAME_FORMAT_Y14};
-    static const obsensor::StreamProfile astra2depthProfile = {640, 480, 30, obsensor::FRAME_FORMAT_Y14};
+    static const obsensor::StreamProfile gemini2DepthProfile = {1280, 800, 30, obsensor::FRAME_FORMAT_Y14};
+    static const obsensor::StreamProfile astra2DepthProfile = {640, 480, 30, obsensor::FRAME_FORMAT_Y14};
+    static const obsensor::StreamProfile megaColorProfile = {1280, 720, 30, obsensor::FRAME_FORMAT_MJPG};
+    static const obsensor::StreamProfile megaDepthProfile = {640, 576, 30, obsensor::FRAME_FORMAT_Y16};
 
     streamChannelGroup_ = obsensor::getStreamChannelGroup(index);
     if (!streamChannelGroup_.empty())
@@ -46,11 +48,17 @@ VideoCapture_obsensor::VideoCapture_obsensor(int index) : isOpened_(false)
```

Review comment:
MJPEG helps to save bandwidth (and connect multiple cameras). On other cameras some formats+fps are not available without compression (especially FHD+) - MJPEG or H264. BTW, MJPG is already used before this patch, see `colorProfile` on the line 35.
**File:** modules/videoio/include/opencv2/videoio.hpp
**Change Type:** modified
**Context:** PR #25874: `videoio`: fix `cv::VideoWriter` with FFmpeg encapsulation timestamps

**Code Changes:**
```diff
@@ -211,6 +211,8 @@ enum VideoCaptureProperties {
        CAP_PROP_CODEC_EXTRADATA_INDEX = 68, //!< Positive index indicates that returning extra data is supported by the video back end.  This can be retrieved as cap.retrieve(data, <returned index>).  E.g. When reading from a h264 encoded RTSP stream, the FFmpeg backend could return the SPS and/or PPS if available (if sent in reply to a DESCRIBE request), from calls to cap.retrieve(data, <returned index>).
        CAP_PROP_FRAME_TYPE = 69, //!< (read-only) FFmpeg back-end only - Frame type ascii code (73 = 'I', 80 = 'P', 66 = 'B' or 63 = '?' if unknown) of the most recently read frame.
        CAP_PROP_N_THREADS = 70, //!< (**open-only**) Set the maximum number of threads to use. Use 0 to use as many threads as CPU cores (applicable for FFmpeg back-end only).
+       CAP_PROP_PTS = 71, //!<  (read-only) FFmpeg back-end only - presentation timestamp of the most recently read frame using the FPS time base.  e.g. fps = 25, VideoCapture::get(\ref CAP_PROP_PTS) = 3, presentation time = 3/25 seconds.
+       CAP_PROP_DTS_DELAY = 72, //!<  (read-only) FFmpeg back-end only - maximum difference between presentation (pts) and decompression timestamps (dts) using FPS time base.  e.g. delay is maximum when frame_num = 0, if true, VideoCapture::get(\ref CAP_PROP_PTS) = 0 and VideoCapture::get(\ref CAP_PROP_DTS_DELAY) = 2, dts = -2.  Non zero values usually imply the stream is encoded using B-frames which are not decoded in presentation order.
 #ifndef CV_DOXYGEN
        CV__CAP_PROP_LATEST
 #endif
@@ -230,8 +232,10 @@ enum VideoWriterProperties {
```

Review comment:
It'll be great to add some references to `cv::VideoCapture` properties. It's not obvious, if the properties are needed and how to extract them from the encoded stream.
**File:** modules/videoio/include/opencv2/videoio.hpp
**Change Type:** modified
**Context:** PR #25874: `videoio`: fix `cv::VideoWriter` with FFmpeg encapsulation timestamps

**Code Changes:**
```diff
@@ -211,6 +211,8 @@ enum VideoCaptureProperties {
        CAP_PROP_CODEC_EXTRADATA_INDEX = 68, //!< Positive index indicates that returning extra data is supported by the video back end.  This can be retrieved as cap.retrieve(data, <returned index>).  E.g. When reading from a h264 encoded RTSP stream, the FFmpeg backend could return the SPS and/or PPS if available (if sent in reply to a DESCRIBE request), from calls to cap.retrieve(data, <returned index>).
        CAP_PROP_FRAME_TYPE = 69, //!< (read-only) FFmpeg back-end only - Frame type ascii code (73 = 'I', 80 = 'P', 66 = 'B' or 63 = '?' if unknown) of the most recently read frame.
        CAP_PROP_N_THREADS = 70, //!< (**open-only**) Set the maximum number of threads to use. Use 0 to use as many threads as CPU cores (applicable for FFmpeg back-end only).
+       CAP_PROP_PTS = 71, //!<  (read-only) FFmpeg back-end only - presentation timestamp of the most recently read frame using the FPS time base.  e.g. fps = 25, VideoCapture::get(\ref CAP_PROP_PTS) = 3, presentation time = 3/25 seconds.
+       CAP_PROP_DTS_DELAY = 72, //!<  (read-only) FFmpeg back-end only - maximum difference between presentation (pts) and decompression timestamps (dts) using FPS time base.  e.g. delay is maximum when frame_num = 0, if true, VideoCapture::get(\ref CAP_PROP_PTS) = 0 and VideoCapture::get(\ref CAP_PROP_DTS_DELAY) = 2, dts = -2.  Non zero values usually imply the stream is encoded using B-frames which are not decoded in presentation order.
 #ifndef CV_DOXYGEN
        CV__CAP_PROP_LATEST
 #endif
@@ -230,8 +232,10 @@ enum VideoWriterProperties {
```

Review comment:
I mean slightly different thing. The VideoWriter user should get values for the new properties somehow. I see 2 sources: - get something for cv::VideoCapture and promote it to writer (good case). For the case we need a reference to VideoCapture props. - dig in IP camera settings or encoder settings manually (bad case). The case means that we cannot implement generic code that works for all streams.
**File:** modules/videoio/include/opencv2/videoio.hpp
**Change Type:** modified
**Context:** PR #25874: `videoio`: fix `cv::VideoWriter` with FFmpeg encapsulation timestamps

**Code Changes:**
```diff
@@ -211,6 +211,8 @@ enum VideoCaptureProperties {
        CAP_PROP_CODEC_EXTRADATA_INDEX = 68, //!< Positive index indicates that returning extra data is supported by the video back end.  This can be retrieved as cap.retrieve(data, <returned index>).  E.g. When reading from a h264 encoded RTSP stream, the FFmpeg backend could return the SPS and/or PPS if available (if sent in reply to a DESCRIBE request), from calls to cap.retrieve(data, <returned index>).
        CAP_PROP_FRAME_TYPE = 69, //!< (read-only) FFmpeg back-end only - Frame type ascii code (73 = 'I', 80 = 'P', 66 = 'B' or 63 = '?' if unknown) of the most recently read frame.
        CAP_PROP_N_THREADS = 70, //!< (**open-only**) Set the maximum number of threads to use. Use 0 to use as many threads as CPU cores (applicable for FFmpeg back-end only).
+       CAP_PROP_PTS = 71, //!<  (read-only) FFmpeg back-end only - presentation timestamp of the most recently read frame using the FPS time base.  e.g. fps = 25, VideoCapture::get(\ref CAP_PROP_PTS) = 3, presentation time = 3/25 seconds.
+       CAP_PROP_DTS_DELAY = 72, //!<  (read-only) FFmpeg back-end only - maximum difference between presentation (pts) and decompression timestamps (dts) using FPS time base.  e.g. delay is maximum when frame_num = 0, if true, VideoCapture::get(\ref CAP_PROP_PTS) = 0 and VideoCapture::get(\ref CAP_PROP_DTS_DELAY) = 2, dts = -2.  Non zero values usually imply the stream is encoded using B-frames which are not decoded in presentation order.
 #ifndef CV_DOXYGEN
        CV__CAP_PROP_LATEST
 #endif
@@ -230,8 +232,10 @@ enum VideoWriterProperties {
```

Review comment:
Right I was thinking of streams provided by external encoders (`cudacodec::VideoWriter`) not of the encapsulation of RTSP streams. For the first parameter (`VIDEOWRITER_PROP_PTS_INDEX`), if the frame rate is provided in the rtsp stream it is equivalent to dividing the current position of the video file (`CAP_PROP_POS_MSEC`) by the duration of the frame (i.e. 1000.0/`VideoCapture::get(CAP_PROP_FPS)` if the frame rate is fixed. If the frame rate isn't fixed then we would need to create an extra property inside `cv::VideoCapture` to provide this information? I am not sure if the second parameter (`VIDEOWRITER_PROP_B_FRAME_PRESENTATION_DELAY`) is available inside FFmpeg but if it is (for all versions) we would need to create this extra property inside `cv::VideoCapture` as well.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 81

**Code Changes:**
```diff
+        # Do top-k sampling of 50
+        topk_indices = np.argpartition(probs, -50, axis=-1)[:, -50:]
+        topk_probs = np.take_along_axis(probs, topk_indices, axis=-1)
+
+        # Normalize top-k probabilities
+        topk_probs /= np.sum(topk_probs, axis=-1, keepdims=True)
+
+        # Select a token from the top-k probabilities
+        sampled_indices = [np.random.choice(topk_indices[i], p=topk_probs[i]) for i in range(len(topk_probs))]
+        sampled_indices = np.array(sampled_indices).reshape(-1, 1)
+
```

Review comment:
Do we really need softmax and normalization to just get top-k predictions? I think their order is not changed from raw logits.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference

**Code Changes:**
```diff
@@ -0,0 +1,125 @@
+'''
+This is a sample script to run GPT-2 inference in OpenCV using ONNX model.
+The script loads the GPT-2 model and runs inference on a given prompt.
+Currently script only works with fixed size window, that means
+you will have to specify prompt of the same length as when model was exported to ONNX.
+
+
+Exporting GPT-2 model to ONNX.
+To export GPT-2 model to ONNX, you can use the following procedure:
```

Review comment:
`import cv2 as cv`
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference

**Code Changes:**
```diff
@@ -0,0 +1,125 @@
+'''
+This is a sample script to run GPT-2 inference in OpenCV using ONNX model.
+The script loads the GPT-2 model and runs inference on a given prompt.
+Currently script only works with fixed size window, that means
+you will have to specify prompt of the same length as when model was exported to ONNX.
+
+
+Exporting GPT-2 model to ONNX.
+To export GPT-2 model to ONNX, you can use the following procedure:
```

Review comment:
maybe just `readNet`?
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 38

**Code Changes:**
```diff
+
+
+
+from copy import deepcopy
+import numpy as np
+import tiktoken
+import argparse
+import cv2 as cv
+
+def parse_args():
+    parser = argparse.ArgumentParser(description='Use this script to run GPT-2 inference in OpenCV',
```

Review comment:
External dependency. Add instruction of how to install and which version.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 31

**Code Changes:**
```diff
+
+    pip install tiktoken==0.7.0
+
+2. Run the script:
+
+    python gpt2_inference.py --model=<path-to-onnx-model> --max_seq_len=<max-output-lenght> --batch_size=<use-one-used-while-exportinh> --prompt=<use-promt-of-the-same-length-used-while-exporting>
+'''
+
+
+
+from copy import deepcopy
```

Review comment:
``` --prompt=<use-promt-of-the-same-length-used-while-exporting> ``` Can sample support simple padding in case of shorter prompt? Otherwise user cannot understand how to fill the same length.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 31

**Code Changes:**
```diff
+
+    pip install tiktoken==0.7.0
+
+2. Run the script:
+
+    python gpt2_inference.py --model=<path-to-onnx-model> --max_seq_len=<max-output-lenght> --batch_size=<use-one-used-while-exportinh> --prompt=<use-promt-of-the-same-length-used-while-exporting>
+'''
+
+
+
+from copy import deepcopy
```

Review comment:
how to know head of time which prompt legth user used?
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 31

**Code Changes:**
```diff
+
+    pip install tiktoken==0.7.0
+
+2. Run the script:
+
+    python gpt2_inference.py --model=<path-to-onnx-model> --max_seq_len=<max-output-lenght> --batch_size=<use-one-used-while-exportinh> --prompt=<use-promt-of-the-same-length-used-while-exporting>
+'''
+
+
+
+from copy import deepcopy
```

Review comment:
If model exported with some input shape we can accept prompt with less or equal length and pad in case of shorter prompt. There is an option to obtain input shape in OpenCV like this: https://github.com/opencv/opencv/blob/6a11847d579e95bc5cca64d951684d4b578870ae/modules/dnn/src/model.cpp#L51
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 81

**Code Changes:**
```diff
+        # Do top-k sampling of 50
+        topk_indices = np.argpartition(probs, -50, axis=-1)[:, -50:]
+        topk_probs = np.take_along_axis(probs, topk_indices, axis=-1)
+
+        # Normalize top-k probabilities
+        topk_probs /= np.sum(topk_probs, axis=-1, keepdims=True)
+
+        # Select a token from the top-k probabilities
+        sampled_indices = [np.random.choice(topk_indices[i], p=topk_probs[i]) for i in range(len(topk_probs))]
+        sampled_indices = np.array(sampled_indices).reshape(-1, 1)
+
```

Review comment:
`np.random.choice` expect probabilities (sum to 1). otherwise you are correct
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 31

**Code Changes:**
```diff
+
+    pip install tiktoken==0.7.0
+
+2. Run the script:
+
+    python gpt2_inference.py --model=<path-to-onnx-model> --max_seq_len=<max-output-lenght> --batch_size=<use-one-used-while-exportinh> --prompt=<use-promt-of-the-same-length-used-while-exporting>
+'''
+
+
+
+from copy import deepcopy
```

Review comment:
Let's use `max_input_length` as an additional parameter: https://github.com/search?q=repo%3Ahuggingface%2Ftransformers%20max_input_length&type=code
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference

**Code Changes:**
```diff
@@ -0,0 +1,125 @@
+'''
+This is a sample script to run GPT-2 inference in OpenCV using ONNX model.
+The script loads the GPT-2 model and runs inference on a given prompt.
+Currently script only works with fixed size window, that means
+you will have to specify prompt of the same length as when model was exported to ONNX.
+
+
+Exporting GPT-2 model to ONNX.
+To export GPT-2 model to ONNX, you can use the following procedure:
```

Review comment:
You can remove numpy from the list. It's already there as OpenCV dependency.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference

**Code Changes:**
```diff
@@ -0,0 +1,125 @@
+'''
+This is a sample script to run GPT-2 inference in OpenCV using ONNX model.
+The script loads the GPT-2 model and runs inference on a given prompt.
+Currently script only works with fixed size window, that means
+you will have to specify prompt of the same length as when model was exported to ONNX.
+
+
+Exporting GPT-2 model to ONNX.
+To export GPT-2 model to ONNX, you can use the following procedure:
```

Review comment:
It makes sense to use command line parameter for seed. Zero is good default value.
**File:** samples/dnn/gpt2_inference.py
**Change Type:** added
**Context:** PR #25868: Add sample for GPT2 inference
**Review Line:** 117

**Code Changes:**
```diff
+    if len(tokens) > input_token_size:
+        tokens = tokens[:input_token_size]
+    elif len(tokens) < input_token_size:
+        tokens2pad = input_token_size - len(tokens)
+        # append <space> token to the prompt
+        tokens += [220] * tokens2pad
+
+
+    output_buffer = gpt2_inference(net, tokens, max_length, num_return_sequences)
+
+    for i in range(num_return_sequences):
```

Review comment:
EOS I tried this. Your prompt followed by EOS make model output sentences that are not related to your prompt (as you indicatited end of context by EOS)
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
Please add table with author and compatibility notes like here: https://github.com/opencv/opencv/blob/4.x/doc/tutorials/calib3d/camera_calibration/camera_calibration.markdown
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
Please remove extra empty lines here and below in the document.
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
the older Orbbec 3D which --> the older Orbbec 3D cameras which
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
If you can put your real name here?
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
It's not necessary in my opinion.
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
You can remove the 4th item now.
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
Can you add toggle to show the two pictures, same as the switch to show the two code version?
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
Can be removed too in my opinion.
**File:** doc/tutorials/app/orbbec_uvc.markdown
**Change Type:** added
**Context:** PR #25907: Add tutorial on using Orbbec 3D cameras (UVC)

**Code Changes:**
```diff
@@ -0,0 +1,126 @@
+Using Orbbec 3D cameras (UVC) {#tutorial_orbbec_uvc}
+====================================================
+
+@tableofcontents
+
+@prev_tutorial{tutorial_orbbec_astra_openni}
+@next_tutorial{tutorial_intelperc}
+
+|    |    |
```

Review comment:
measurement limits --> depth range; potentially enhancing the visualization's relevance to a specific depth range --> removing invalid pixels on the depth map.
**File:** cmake/checks/cpu_rvv.cpp
**Change Type:** modified
**Context:** PR #25883: Upgrade RISC-V Vector intrinsic and cleanup the obsolete RVV backend.

**Code Changes:**
```diff
@@ -1,17 +1,16 @@
 #include <stdio.h>
 
-#if defined(__riscv)
-#  include <riscv_vector.h>
-#  define CV_RVV 1
+#if !defined(__riscv) || !defined(__riscv_v)
+#error "RISC-V or vector extension(RVV) is not supported by the compiler"
 #endif
 
```

Review comment:
Let's make this file compatible with T-Head toolchain too. It uses old intrinsics, doesn't define `__riscv_v_intrinsics`, but have `__riscv_v` and `__THEAD_VERSION__` macros. Perhaps even simple `#include <riscv_vector.h>` would be enough to check that it works. Otherwise our CPU detection mechanism will not find RVV and would disable RVV 0.7.1 HAL: https://github.com/opencv/opencv/blob/53a5b85d9f6e2a58066f966d901c0e93ea1ebcf0/CMakeLists.txt#L1040-L1046
**File:** cmake/checks/cpu_rvv.cpp
**Change Type:** modified
**Context:** PR #25883: Upgrade RISC-V Vector intrinsic and cleanup the obsolete RVV backend.

**Code Changes:**
```diff
@@ -1,17 +1,16 @@
 #include <stdio.h>
 
-#if defined(__riscv)
-#  include <riscv_vector.h>
-#  define CV_RVV 1
+#if !defined(__riscv) || !defined(__riscv_v)
+#error "RISC-V or vector extension(RVV) is not supported by the compiler"
 #endif
 
```

Review comment:
Ok, do you mean ... ```cpp #include <stdio.h> #if defined(__riscv) # include <riscv_vector.h> # define CV_RVV 1 #endif #if defined CV_RVV && !defined __THEAD_VERSION__ #if !defined(__riscv_v_intrinsic) || (__riscv_v_intrinsic < 12000) #error "RISC-V Vector Intrinsic v0.12 or higher is required." #endif int test() { const float src[] = { 0.0f, 0.0f, 0.0f, 0.0f }; uint64_t ptr[2] = {0x0908060504020100, 0xFFFFFFFF0E0D0C0A}; vuint8m1_t a = __riscv_vreinterpret_v_u64m1_u8m1(__riscv_vle64_v_u64m1(ptr, 2)); vfloat32m1_t val = __riscv_vle32_v_f32m1((const float*)(src), 4); return (int)__riscv_vfmv_f_s_f32m1_f32(val); } #elif defined CV_RVV && defined __THEAD_VERSION__ int test() { const float src[] = { 0.0f, 0.0f, 0.0f, 0.0f }; uint64_t ptr[2] = {0x0908060504020100, 0xFFFFFFFF0E0D0C0A}; vuint8m1_t a = vreinterpret_v_u64m1_u8m1(vle64_v_u64m1(ptr, 2)); vfloat32m1_t val = vle32_v_f32m1((const float*)(src), 4); return (int)vfmv_f_s_f32m1_f32(val); } #else #error "RISC-V vector extension(RVV) is not supported" #endif int main() { printf("%d\n", test()); return 0; } ```
**File:** cmake/checks/cpu_rvv.cpp
**Change Type:** modified
**Context:** PR #25883: Upgrade RISC-V Vector intrinsic and cleanup the obsolete RVV backend.

**Code Changes:**
```diff
@@ -1,17 +1,16 @@
 #include <stdio.h>
 
-#if defined(__riscv)
-#  include <riscv_vector.h>
-#  define CV_RVV 1
+#if !defined(__riscv) || !defined(__riscv_v)
+#error "RISC-V or vector extension(RVV) is not supported by the compiler"
 #endif
 
```

Review comment:
Yes, it should work. Perhaps we could also simplify the file a bit to reduce macros depth: ```.cpp #if !defined(__riscv) || !defined(__riscv_v) #error "Not RISC-V or no RVV ..." #endif #if !defined(__THEAD_VERSION__) && defined(__riscv_v_intrinsic) && __riscv_v_intrinsic < 12000 #error "Wrong intrinsics ..." #endif #include <riscv_vector.h> #ifdef (__THEAD_VERSION__) int test() { // ... old version } #else { // ... new version } #endif int main() {...} ```