Decoded raw buffer sizes inconsistent

[Nicolas Dufresne]

Le ven. 5 oct. 2018 17 h 57, <Jon.Titzell at l3t.com> a écrit :

> Hello,
>
>
>
> I am working on maintaining a plugin that writes directly to raw buffers
> and noticed that sometimes raw video buffers have an inconsistent size
> after decoding. Attempting to characterize the size led me to discover that
> it hinges on a multitude of variables; I have observed variance with
> resolution, codec, video sink, Gstreamer version, and possibly OS.
>
> I have tested Gstreamer on Windows (7 and 10) and Linux (Centos 7, Fedora
> 27, Ubuntu 16, 18, and Arch) with most versions from 1.8.3 to 1.14.1; each
> of these having minute differences in their results. I have also tested
> briefly on Windows 7 with Gstreamer 0.10.36 and could not replicate the
> issue.
>
>
>
> Here’s a specific example on Windows 10, Gstreamer 1.10.4, coding a single
> frame of a 1280x720 I420 test signal into H.264, then decoding and
> displaying the frame:
>
>
>
> gst-launch-1.0.exe –v videotestsrc num-buffers=1 \
>
>     ! video/x-raw,width=1280,height=720,format=I420 \
>
>     ! identity name=raw1 silent=false \
>
>     ! x264enc \
>
>     ! avdec_h264 \
>
>     ! identity name=raw2 silent=false \
>
>     ! d3dvideosink
>
>
>
> After running this command, the chain message reveals the buffer size in
> identity raw1 is as expected ( 1280 * 720 * 1.5 = 1,382,400 bytes ) but the
> buffer size observed in identity raw2 is completely different at 1,596,672
> bytes. Switching d3dvideosink to glimagesink or fakevideosink results in
> raw2’s buffer size becoming 1,629,056 bytes, but using fakesink, appsink,
> or filesink all result in the expected buffer size, 1,382,400 bytes.
> Changing the codec results in different results yet again, such as in this
> example: on Ubuntu 16, Gstreamer 1.13.0, coding the same test signal into
> H.265, then decoding and displaying:
>
>
>
> gst-launch-1.0 –v videotestsrc num-buffers=1 \
>
>     ! video/x-raw,width=1280,height=720,format=I420 \
>
>     ! identity name=raw1 silent=false \
>
>     ! x265enc \
>
>     ! avdec_h265 \
>
>     ! identity name=raw2 silent=false \
>
>     ! xvimagesink
>
>
>
> This resulted in a 1,624,832 byte buffer. I also tried 1920x1080 and
> 720x480, which resulted in buffer sizes of 3,444,756 and 640,640 bytes,
> respectively. I have also tested codecs that are not implemented in libav,
> such as jpeg, openjpeg, png, vp8 and vp9, but only vp9 had a similar
> ailment.
>
>
>
> If anyone can help narrow down the cause of this or how to accommodate for
> the extra buffer size in my plugin development, it would be greatly
> appreciated.
>

This is normal behaviour. The size of the raw buffer will vary depending on
the horizontal and vertical padding. This padding is used to satisfy memory
alignment requirements (or coded size, vs display size differences). When
you get two different size for the same codec, it simply means one is
likely doing a memory copy due to incompatible alignment requirements
between two elements.

The GstVideoMeta is used to store this information in the form of 2 arrays,
strides and offsets. Stride is the memory size of one line in bytes, and
offsets let you know where each planes starts.


>
> Thank you,
>
> Jon Titzell
>
> Software Engineer
>
> L3 Technologies MID
> ------------------------------------------- CONFIDENTIALITY NOTICE: This
> email and any attachments are for the sole use of the intended recipient
> and may contain material that is proprietary, confidential, privileged or
> otherwise legally protected or restricted under applicable government laws.
> Any review, disclosure, distributing or other use without expressed
> permission of the sender is strictly prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies without
> reading, printing, or saving..
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181006/528b6094/attachment-0001.html>