3 add note about the extra copy in gl
source | link

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing. (edit: sorry! there's one more copy unless you're using Mesa master because hadn't implemented an important fastpath)

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen) whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing.

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen) whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing. (edit: sorry! there's one more copy unless you're using Mesa master because hadn't implemented an important fastpath)

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen) whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

2 deleted 2 characters in body
source | link

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing.

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen). whether whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing.

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen). whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing.

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen) whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.

1
source | link

Since you didn't mention enabling the open source stack, I suspect you're using the bcm video drivers and gstreamer's GL will be using Mesa software rendering instead of hardware. To get a fair comparison you'd need to enable the open source display stack in raspi-config (or use debian or fedora instead)

With glimagesink, gstreamer uploads the decompressed frame into a GL texture, then draws it to the screen. Because it's GL, you get vblank synchronization like any other GL app. Your copies of the video data are (texture, framebuffer) if you're full screen pageflipping or (texture, framebuffer, screen) if you're windowed. Probably add another copy if you're windowed and compositing.

With ximagesink (unless they've added usage of the Present extension, which I highly doubt), you won't get vblank synchronization. Your copies will be (shm, screen). whether or not you're full screen. Add another copy if you're compositing.

Normally glimagesink would be more of a win, not just for vblank synchronization feature, but because it uploads YUV data to textures and uses a shader to colorspace convert during the draw, so the upload is smaller and you use less memory bandwidth than the X11 case and a whole lot less CPU for colorspace conversion.