GStreamer issueshttps://gitlab.freedesktop.org/groups/gstreamer/-/issues2021-09-24T13:21:05Zhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/162gl: add selection of backing pixel formats/config attributes2021-09-24T13:21:05ZBugzilla Migration Usergl: add selection of backing pixel formats/config attributes## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#744187)](https://bugzilla.gnome.org/show_bug.cgi?id=744187)**
## Description
All the GL platforms (egl, glx, cgl, wgl, etc) allow the possibility of selecting the p...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#744187)](https://bugzilla.gnome.org/show_bug.cgi?id=744187)**
## Description
All the GL platforms (egl, glx, cgl, wgl, etc) allow the possibility of selecting the pixel format for the window that is rendered into as well as miscellaneous context config options. We should expose that.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/161Vertical position of subtitles playbin and subtitleoverlay2021-09-24T13:21:05ZBugzilla Migration UserVertical position of subtitles playbin and subtitleoverlay## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#744056)](https://bugzilla.gnome.org/show_bug.cgi?id=744056)**
## Description
Created attachment 296209
01- patch for subtitleoverlay
Two nights ago I wen...## Submitted by Luis de Bethencourt `@luisbg`
**[Link to original bug (#744056)](https://bugzilla.gnome.org/show_bug.cgi?id=744056)**
## Description
Created attachment 296209
01- patch for subtitleoverlay
Two nights ago I went to an event hosted by a spanish academy where they projected a spanish film at a pub. Since most of the people in the room are learning spanish, they had english subtitles for educational purposes. And since the venue wasn't designed for this (group of chairs in flat floor) most people had their view of the bottom of the screen blocked. After some failed starts somebody changed a setting in the video player to move the subtitles to the top of the screen, and everybody could read them and was happy.
This made me think doing this in playbin is not possible. I don't think there are any GStreamer players that offer this feature.
I attach a solution for this :)
(some people call it opera-style subtitles since the same solution has been used in the opera)
**Patch 296209**, "01- patch for subtitleoverlay":
[0001-subtitleoverlay-add-vertical-position-property.patch](/uploads/735bf7bb46506ac352ff8164e64c43f3/0001-subtitleoverlay-add-vertical-position-property.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/155support for alsa compress API2021-09-24T13:21:03ZBugzilla Migration Usersupport for alsa compress API## Submitted by Qais Yousef
**[Link to original bug (#743192)](https://bugzilla.gnome.org/show_bug.cgi?id=743192)**
## Description
As per the thread on gstreamer mailing list [1], I'm looking at adding support for alsa compress API....## Submitted by Qais Yousef
**[Link to original bug (#743192)](https://bugzilla.gnome.org/show_bug.cgi?id=743192)**
## Description
As per the thread on gstreamer mailing list [1], I'm looking at adding support for alsa compress API. Any direction on what's the advised method of adding this support? To start up I'm wondering whether the support should be an extension of existing alsasink component or whether to add it as a separate component (which I think is the better option).
Thanks,
Qais
[1] http://gstreamer-devel.966125.n4.nabble.com/ALSA-Compress-Offload-support-td4670153.htmlhttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/153GstEncodingProfile should take multiple presets2021-09-24T13:21:02ZBugzilla Migration UserGstEncodingProfile should take multiple presets## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#742831)](https://bugzilla.gnome.org/show_bug.cgi?id=742831)**
## Description
The encoding API provided by GstEncodingProfile only allows for a single GstPreset to be at...## Submitted by Arun Raghavan `@arun`
**[Link to original bug (#742831)](https://bugzilla.gnome.org/show_bug.cgi?id=742831)**
## Description
The encoding API provided by GstEncodingProfile only allows for a single GstPreset to be attached to it. This means that we must know, before hand, what encoder will be used, which defeats the point of the encoding API.
Ideally, we should allow the provision of multiple presets to the GstEncodingProfile, probably with an associated GstElementFactory name. This would allow us to select the appropriate preset based on what is available on the system, and apply that.
Even better would be for the saved preset itself to have the associated factory name -- that way we would just walk down the list of provided presets and try to apply them till one works.
Relatedly, the GstEncoding*Profile should probably use properties for initialisation and getting/setting parameters.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/151rtsp: Add ONVIF metadata support2021-09-24T13:21:01ZBugzilla Migration Userrtsp: Add ONVIF metadata support## Submitted by Sergio
**[Link to original bug (#741745)](https://bugzilla.gnome.org/show_bug.cgi?id=741745)**
## Description
Some IP Cameras follow Onvif protocols (a standard for surveillance cameras). These usually have h.264 cod...## Submitted by Sergio
**[Link to original bug (#741745)](https://bugzilla.gnome.org/show_bug.cgi?id=741745)**
## Description
Some IP Cameras follow Onvif protocols (a standard for surveillance cameras). These usually have h.264 codecs. When trying to decode using playbin or uridecodebin there is an error showing:
Missing element: VND.ONVIF.METADATA RTP depayloader
Using the following pipeline works:
$ gst-launch-1.0.exe rtspsrc location=rtsp://user:pass@0.0.0.0/rtspStream ! rtph264depay ! h264parse ! avdec_h264 ! autovideosink
However, if the camera's resolution is modified, the pipeline fails to detect the correct resolution. Possibly the correct resolution information is found in the metadata.
VLC does successfully decode the rtsp stream.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/147video: overlay composition blending in software should cache scaled/converted...2021-09-24T13:20:59ZBugzilla Migration Uservideo: overlay composition blending in software should cache scaled/converted overlay rectangles## Submitted by Lazar Claudiu
Assigned to **Tim Müller `@tpm`**
**[Link to original bug (#740625)](https://bugzilla.gnome.org/show_bug.cgi?id=740625)**
## Description
gdkpixbufoverlay should convert its source image to the require...## Submitted by Lazar Claudiu
Assigned to **Tim Müller `@tpm`**
**[Link to original bug (#740625)](https://bugzilla.gnome.org/show_bug.cgi?id=740625)**
## Description
gdkpixbufoverlay should convert its source image to the required pixel format only once and cache the buffer for subsequent use.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/144video: implement x offset parameter in GstVideoFormatUnpack functions for all...2021-09-24T13:20:57ZBugzilla Migration Uservideo: implement x offset parameter in GstVideoFormatUnpack functions for all formats## Submitted by Tim Müller `@tpm`
**[Link to original bug (#740228)](https://bugzilla.gnome.org/show_bug.cgi?id=740228)**
## Description
+++ This bug was initially created as a clone of [Bug 739281](https://bugzilla.gnome.org/show_b...## Submitted by Tim Müller `@tpm`
**[Link to original bug (#740228)](https://bugzilla.gnome.org/show_bug.cgi?id=740228)**
## Description
+++ This bug was initially created as a clone of [Bug 739281](https://bugzilla.gnome.org/show_bug.cgi?id=739281) +++
Two issues:
a) our GstVideoFormatUnpack functions for the various video formats seem to completely ignore the x parameter.
b) GstVideoFormatPack does not seem to have an x parameter; this is unfortunate, since it means we need to unpack/pack a lot of pixels we don't actually need at all (e.g. when blending pixels of a logo somewhere we'd need to unpack/pack from x=0 to x=logo_xpos+logo_width instead of from x=logo_xpos to x=logo_xpos+logo_width (unless we manually adjust row pointers we pass I guess, which won't work well for complex formats)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/142rtspconnection: Need to implement to get current queued messages and amount o...2021-09-24T13:20:55ZBugzilla Migration Userrtspconnection: Need to implement to get current queued messages and amount of bytes## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#740024)](https://bugzilla.gnome.org/show_bug.cgi?id=740024)**
## Description
Currently, rtspconnection supports to get maximum bytes and the number of messages in the que...## Submitted by Hyunjun Ko `@zzoon`
**[Link to original bug (#740024)](https://bugzilla.gnome.org/show_bug.cgi?id=740024)**
## Description
Currently, rtspconnection supports to get maximum bytes and the number of messages in the queue by the function gst_rtsp_watch_get_send_backlog.
But it's not supporred to get current status of the queue.
I think it's needed by user, especially, who needs to know the current status like amount of bytes queued.
If users get it, user could control flow data manually by adjusting bitrate or something like that.
If a function gst_rtsp_watch_get_current_backlog is implemented, it would be good.
What do you think about this?
### Blocking
* [Bug 738990](https://bugzilla.gnome.org/show_bug.cgi?id=738990)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/136video: Add a linear/affine transformation matrix meta2021-09-24T13:20:53ZBugzilla Migration Uservideo: Add a linear/affine transformation matrix meta## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#738914)](https://bugzilla.gnome.org/show_bug.cgi?id=738914)**
## Description
+++ This bug was initially created as a clone of [Bug 679522](https://bugzilla.gnome.org...## Submitted by Sebastian Dröge `@slomo`
**[Link to original bug (#738914)](https://bugzilla.gnome.org/show_bug.cgi?id=738914)**
## Description
+++ This bug was initially created as a clone of [Bug 679522](https://bugzilla.gnome.org/show_bug.cgi?id=679522) +++
In Quicktime/MP4 we can get an arbitrary transformation matrix that should be applied to the video before displaying. In other contexts we also get that, or sometimes just a rotation angle which could be expressed like this too.
There should probably be a meta that contains such an arbitrary 3x3 transformation matrix, can be negotiated inside the pipeline and implemented by sinks or other elements.
Additionally there might be constraints on what elements are implementing, e.g. some might only implement n*90° rotations and flips (videoflip element), which might be something that should be possible to negotiate.
Also an open question is what should happen with transformations that produce a non-rectangle output (e.g. rotations or shears). I would say they should create a bigger frame with black borders, but what also would be valid is cropping everything that goes over the frame size.
### Blocking
* [Bug 679522](https://bugzilla.gnome.org/show_bug.cgi?id=679522)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/130Feature Submission: Added XSync support to xvimagesink2021-09-24T13:20:51ZBugzilla Migration UserFeature Submission: Added XSync support to xvimagesink## Submitted by Stirling Westrup
**[Link to original bug (#735404)](https://bugzilla.gnome.org/show_bug.cgi?id=735404)**
## Description
Created attachment 284445
Patch to implement xsync support in xvimagesink
There is an X S...## Submitted by Stirling Westrup
**[Link to original bug (#735404)](https://bugzilla.gnome.org/show_bug.cgi?id=735404)**
## Description
Created attachment 284445
Patch to implement xsync support in xvimagesink
There is an X Server extension called XSync which allows for synchronizing X operations against an external clock. Under Linux the default 'SERVERTIME' clock is a monotonic clock shared by all servers on a linux box, allowing for synchronization between independent X Servers running on a single machine.
To make use of this feature, I've added 'xsync' and 'xsync-clock' properties to xvimagesink. If xsync is true, then whenever xvimagesink would normally synchronize frames, it will attempt to do so using the XSync clock named in 'xsync-clock'
I've added this features in order to help support videowall software that needs multiple X Servers to show frames at the same moment.
This is my first attempt at modifying the internals of a complex sink like xvimagesink, and I may have made some mistakes, but the code currently appears to operate as expected.
**Patch 284445**, "Patch to implement xsync support in xvimagesink":
[xsync.patch](/uploads/5ee6d7bf3a765506d947ad97fe44c073/xsync.patch)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/128textoverlay: support forced updating text when new text buffer comes in2021-09-24T13:20:50ZBugzilla Migration Usertextoverlay: support forced updating text when new text buffer comes in## Submitted by cjunwang
**[Link to original bug (#734219)](https://bugzilla.gnome.org/show_bug.cgi?id=734219)**
## Description
some text producer element, such as closed caption decoder "cea708dec", output text buffer whose duratio...## Submitted by cjunwang
**[Link to original bug (#734219)](https://bugzilla.gnome.org/show_bug.cgi?id=734219)**
## Description
some text producer element, such as closed caption decoder "cea708dec", output text buffer whose duration is not fixed. That means when text buffer display, it's not determined yet when text will be destroyed. https://bugzilla.gnome.org/show_bug.cgi?id=704881
To support this kind of instant buffer, added a property "force-update-text", to allow update text when new text buffer come and existed buffer duration is not finished. It is extremely useful to show scrollable closed caption text.
This property's default value is false. so it would not influence current logics.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/127videopool: allocate page-aligned buffers2021-09-24T13:20:50ZBugzilla Migration Uservideopool: allocate page-aligned buffers## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#733952)](https://bugzilla.gnome.org/show_bug.cgi?id=733952)**
## Description
In order to improve interop with GPU resources, it would help to make sure video buffer ...## Submitted by Gwenole Beauchesne `@gb`
**[Link to original bug (#733952)](https://bugzilla.gnome.org/show_bug.cgi?id=733952)**
## Description
In order to improve interop with GPU resources, it would help to make sure video buffer allocations are page-aligned. This is in view to using userptr (kernel >= 3.16) and expose that to the GPU for further processing.
There are two ways to implement that:
1. At the video pool level, in the alloc_buffer() implementation.
2. At the system allocator level, through an additional settable param.
Approach (1) is trivial, while approach (2) is more generic and has the potential to be used in other scenarios beyond video buffers.
What is the preferred approach? Thanks.
### Blocking
* [Bug 733949](https://bugzilla.gnome.org/show_bug.cgi?id=733949)https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/123audioencoder: Baseclass should call set_format() before propose_allocation()2021-09-24T13:20:47ZBugzilla Migration Useraudioencoder: Baseclass should call set_format() before propose_allocation()## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#732874)](https://bugzilla.gnome.org/show_bug.cgi?id=732874)**
## Description
This was introduce during porting https://bugzilla.gnome.org/show_bug.cgi?id=680614...## Submitted by Nicolas Dufresne `@ndufresne`
**[Link to original bug (#732874)](https://bugzilla.gnome.org/show_bug.cgi?id=732874)**
## Description
This was introduce during porting https://bugzilla.gnome.org/show_bug.cgi?id=680614.
The downside is that it makes it counter intuitive, as propose_allocation() should happen after set_format(). To implement propose_allocation(), encoder have to get the caps from the pad, and then most likely parse these caps into GstVideoInfo structure. Without this patch, it would simply have cached the input_state, and read the information from there.
I do think this is in the ABI now, but would at least be nice to revisit for 2.0.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/122pbutils need different descriptions for MPEG4 Video profiles2021-09-24T13:20:47ZBugzilla Migration Userpbutils need different descriptions for MPEG4 Video profiles## Submitted by an unknown user
**[Link to original bug (#732153)](https://bugzilla.gnome.org/show_bug.cgi?id=732153)**
## Description
In Transmageddon I know offer people to transcode to either MPEG4 video simple and advanced-simpl...## Submitted by an unknown user
**[Link to original bug (#732153)](https://bugzilla.gnome.org/show_bug.cgi?id=732153)**
## Description
In Transmageddon I know offer people to transcode to either MPEG4 video simple and advanced-simple. It would be great if pbutils could return something else than just MPEG-4 Video for both. For instance it would be perfect if Advanced-simple profile returned something like "MPEG-4 Video (xvid)" for instance.
Currently the Transmageddon UI just list MPEG-4 Video twice due to that is what is being returned by pbutils.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/121gl: avoid using an extra FBO pass for formats that requires a shader at uploa...2021-09-24T13:20:46ZBugzilla Migration Usergl: avoid using an extra FBO pass for formats that requires a shader at upload time## Submitted by Julien Isorce `@cap`
**[Link to original bug (#730927)](https://bugzilla.gnome.org/show_bug.cgi?id=730927)**
## Description
Currently "videotestsrc ! video/x-raw, format=I420 ! glimagesink" uses a
shader to do the ...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#730927)](https://bugzilla.gnome.org/show_bug.cgi?id=730927)**
## Description
Currently "videotestsrc ! video/x-raw, format=I420 ! glimagesink" uses a
shader to do the color convertion, it's fine but we use a FBO for that which
can be avoided. Indeed we could draw directly to the window surface.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/114use glMapBuffer and friends2021-09-24T13:20:43ZBugzilla Migration Useruse glMapBuffer and friends## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#726412)](https://bugzilla.gnome.org/show_bug.cgi?id=726412)**
## Description
This allows the possiblity for the GL implementation to give us a pointer to GPU memory...## Submitted by Matthew Waters `@ystreet`
**[Link to original bug (#726412)](https://bugzilla.gnome.org/show_bug.cgi?id=726412)**
## Description
This allows the possiblity for the GL implementation to give us a pointer to GPU memory that we can write to.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/113playbin: detect if video-sink supports deinterlacing2021-09-24T13:20:43ZBugzilla Migration Userplaybin: detect if video-sink supports deinterlacing## Submitted by Matthieu Bouron
**[Link to original bug (#725341)](https://bugzilla.gnome.org/show_bug.cgi?id=725341)**
## Description
The idea here is to make playbin able to detect if the video-sink supports deinterlacing and inse...## Submitted by Matthieu Bouron
**[Link to original bug (#725341)](https://bugzilla.gnome.org/show_bug.cgi?id=725341)**
## Description
The idea here is to make playbin able to detect if the video-sink supports deinterlacing and insert whether or not the deinterlace element (and its relative bin). This should improve the situation of hardware decoders vs interlaced content when the decoder does not do the deinterlacing himself.
Two solutions have been proposed:
* introduce a deinterlace interface, and implement it in the sink. The interface can add the possibility to choose a particular deinterlacing method from what the element supports.
* use the element Klass, but there is no convention yet to do something like Video/Sink + Filter/Effect/Video/Deinterlace. Maybe Video/Sink/[Filter list ...] ?
The main issue I see here is, if overlaying is required (thinking about subtitles), it should only be done after deinterlacing, so the sink might also need the overlay feature if we don't insert the deinterlace element.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/112tags: Add PODCAST, EPISODE and RSSFEED tags2021-09-24T13:20:42ZBugzilla Migration Usertags: Add PODCAST, EPISODE and RSSFEED tags## Submitted by Alice Wonder
**[Link to original bug (#725244)](https://bugzilla.gnome.org/show_bug.cgi?id=725244)**
## Description
Feature Request: Three new tags related to podcasting.
First Tag:
PODCAST
The type sh...## Submitted by Alice Wonder
**[Link to original bug (#725244)](https://bugzilla.gnome.org/show_bug.cgi?id=725244)**
## Description
Feature Request: Three new tags related to podcasting.
First Tag:
PODCAST
The type should be a string.
In xiph/ape comments PODCAST would be the key in the key=value pair.
In id3v2 PODCAST would be the description in a TXXX frame.
This tag is intended to contain the human readable name of the podcast an audio or video is part of.
Currently the album field is frequently used for this. For example, iTunes will over-write the TALB frame of an MP3 with the podcast name and rhythmbox will but the podcast name in the album node of their database xml file. Most of the time this is probably okay but there are case uses where it is not:
Example A: Podcast covering the local music scene may occasionally do a promotional for a local band where they podcast one of their songs. In this case, the ALBUM field should be the recording album the song is from.
By keeping podcast and album separate, it is possible for audio and video files where it is appropriate for them to differ to have both.
Also having a podcast tag in an audio file gives media players that organize media, such as rhythmbox, a means to identify that the media file is part of a podcast upon import into the media library so that it can be given the correct type attribute in the database (e.g. podcast-post oppose to song in the case of rhythmbox)
---
Second Tag:
EPISODE
The type should be a string.
in xiph/ape comments EPISODE would be the key.
In id3v2 EPISODE would be the description in a TXXX frame.
This would be used to indicate the episode number within a podcast, but does not have to be exclusive to use with podcasting.
The uses I see are a non-negative integer if no season is given. If a season is given, SnEm should be used where n is the season designation and m is the episode number within the season.
An EPISODE value of 0 can be used for informational media about the podcast or the season if season information is given. In cases where the media file is not actually part of the podcast production itself, such as the Example A given earlier, then an EPISODE tag should not be used.
In the event that there is a factual correction to an episode, a letter can be appended after the episode number in the correction to note it is an addendum.
For podcasts that use the EPISODE tag, the default sort order should be by EPISODE number rather than by post-date. I know of several cases where an audio-encoding problem in an episode was corrected resulting in a re-posting of an old episode at a later date, causing sort by post-date to fail unless the podcaster uses a fraudulent post-date in the RSS feed for the re-posting.
The EPISODE=m or EPISODE=SnEm
is my notion of how that tag should be used, but I am not sure its use should be restricted to that format and I don't think it matters much to the GStreamer library what the format is as long as it is a string. Let the clients worry about how to sort it.
---
Third Tag:
RSSFEED
The type should be a string but it also should be a valid URI.
In id3v2 RSSFEED would be the description in a WXXX frame.
This would be used to indicate the RSS feed that the podcast is a part of.
It's primary purpose to me involves cases where a media file is downloaded outside the context of the podcast that it is a part of, something I commonly do.
It will make it easy for the listener to subscribe to the feed at a later point in time if they so choose.
A secondary purpose, if a podcast decided to change its name (say due to a trademark infringement or just for artistic reasons) it would be possible for clients that choose to do so to update the PODCAST tag (and / or entry in their database) for all media with the RSSFEED value that matches.
-=-=-=-=-=-=-=-=-
I do not see these tags being used in the wild, but I have been using them myself to re-tag podcasts I manually download, and I will be using them in a podcast hosting service I am working on.
I also hope to patch the Rhythmbox media player used in GNOME so that I don't have to continually manually update the .xml file Rhythmbox uses every time I manually download a podcast episode I am not subscribed to. These tags being recognized by the GStreamer backend that Rhythmbox uses will make a patch the Rhythmbox and the podcast plugin easier to write and I suspect more likely to be accepted by upstream than if I used GST_TAG_EXTENDED_COMMENT to get the information.
Thank you for your consideration,
Michael A. Peters (a.k.a Alice Wonder) - a huge fan of GStreamer (and Lewis Carroll).Sebastian DrögeSebastian Drögehttps://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/111colorbalance: add colorbalance meta API2021-09-24T13:20:42ZBugzilla Migration Usercolorbalance: add colorbalance meta API## Submitted by Matthieu Bouron
**[Link to original bug (#724131)](https://bugzilla.gnome.org/show_bug.cgi?id=724131)**
## Description
Hello there,
Here is a patch that adds a colorbalance meta API to -base, which uses a minima...## Submitted by Matthieu Bouron
**[Link to original bug (#724131)](https://bugzilla.gnome.org/show_bug.cgi?id=724131)**
## Description
Hello there,
Here is a patch that adds a colorbalance meta API to -base, which uses a minimal meta containing contrast, brightness, hue and saturation (stored as double) like in the videobalance element.https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/110gl: Add support for glCompressedTexImage2D2021-09-24T13:20:41ZBugzilla Migration Usergl: Add support for glCompressedTexImage2D## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723781)](https://bugzilla.gnome.org/show_bug.cgi?id=723781)**
## Description
http://www.opengl.org/sdk/docs/man/xhtml/glCompressedTexImage2D.xml
http://software.int...## Submitted by Julien Isorce `@cap`
**[Link to original bug (#723781)](https://bugzilla.gnome.org/show_bug.cgi?id=723781)**
## Description
http://www.opengl.org/sdk/docs/man/xhtml/glCompressedTexImage2D.xml
http://software.intel.com/en-us/articles/android-texture-compression
http://withimagination.imgtec.com/index.php/powervr/pvrtc-the-most-efficient-texture-compression-standard-for-the-mobile-graphics-world
Should first investigate if it has to be done in separate gldec/glenc elements or if it could be done in glupload directly.