<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hello,<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> 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.<o:p></o:p> <o:p> </o:p> 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:<o:p></o:p> <o:p> </o:p> gst-launch-1.0.exe –v videotestsrc num-buffers=1 \<o:p></o:p> ! video/x-raw,width=1280,height=720,format=I420 \<o:p></o:p> ! identity name=raw1 silent=false \<o:p></o:p> ! x264enc \<o:p></o:p> ! avdec_h264 \<o:p></o:p> ! identity name=raw2 silent=false \<o:p></o:p> ! d3dvideosink<o:p></o:p> <o:p> </o:p> 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:<o:p></o:p> <o:p> </o:p> gst-launch-1.0 –v videotestsrc num-buffers=1 \<o:p></o:p> ! video/x-raw,width=1280,height=720,format=I420 \<o:p></o:p> ! identity name=raw1 silent=false \<o:p></o:p> ! x265enc \<o:p></o:p> ! avdec_h265 \<o:p></o:p> ! identity name=raw2 silent=false \<o:p></o:p> ! xvimagesink<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> 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.<o:p></o:p> <o:p> </o:p> Thank you,<o:p></o:p> Jon Titzell<o:p></o:p> Software Engineer<o:p></o:p> L3 Technologies MID<o:p></o:p> </div> ------------------------------------------- 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.. </body> </html>