Discrepancy in byte count when reading from appsink with NV16_10LE32 and NV16 formats

Hello GStreamer developers,

I have a question regarding reading bytes from an appsink in a GStreamer
pipeline. I have set up a pipeline using the "videotestsrc" source with two
different video formats: "NV16_10LE32" and "NV16". Here are the pipelines I
am using:

1. With NV16_10LE32 format:
videotestsrc is-live=true !
video/x-raw,width=1920,height=1080,framerate=30/1,format=(string)NV16_10LE32
! appsink name=videosourcesink


2. With NV16 format:
videotestsrc is-live=true !
video/x-raw,width=1920,height=1080,framerate=30/1,format=(string)NV16 !
appsink name=videosourcesink


I have implemented a callback function for the appsink, where I attempt to
read the bytes from the received buffer. Here is the callback function
implementation:

```
GstFlowReturn
VDRE2GStreamerCaptureEncodingSourceTask::on_new_sample_from_videoSource_sink(GstElement
*elt, ProgramData *data)
{
  GstSample *sample;
  GstBuffer *app_buffer, *buffer;
  GstElement *source;
  GstFlowReturn ret;
  GstMapInfo map;

  // ...

  sample = gst_app_sink_pull_sample(GST_APP_SINK(elt));
  buffer = gst_sample_get_buffer(sample);

  app_buffer = gst_buffer_copy(buffer);
  gst_buffer_map(app_buffer, &map, GST_MAP_WRITE);

  g_print("Array size: %ld \n", map.size);

  // ...

  gst_buffer_unmap(app_buffer, &map);
  gst_object_unref(source);
  gst_sample_unref(sample);

  return ret;
}
```

My issue is as follows: when using the NV16_10LE32 (4:2:2 10 bits per
component packed to 16) format, where a frame size of* 8294400* bytes is
expected (resolution 1920x1080), I am getting a size of *5529600 *bytes
instead. However, when I switch to the NV16 (4:2:2 8 bits per component)
format, where a size of 4147200 bytes is expected, I get the correct result.

My question is: What could be causing this discrepancy in the byte count
between the NV16_10LE32 and NV16 formats? Is there something wrong with my
implementation or the pipeline configuration?

I appreciate your help and guidance in resolving this issue. If you need
any additional information or further details, I would be happy to provide
them.

Thank you,
Israel