Section 3.4 in RFC8835 states that if a WebRTC endpoint uses an HTTP
proxy to access the Internet it MUST include the "ALPN" header. This
commit adds this header.
By default the ALPN used when connecting to the TURN/TCP server via a
proxy is set to "webrtc". It can be changed by adding an alpn url
option for the http-proxy. For example:
http://user:pass@my.http.proxy.com:8080?alpn=c-webrtc
This will add the header "ALPN: c-webrtc" to the HTTP proxy CONNECT
request.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4212>
These 10bit formats are identical to NV12_16L32S, but 64bytes of data is being
prefixed with 16bytes data with four pixels of lower 2bits per byte. For
MT2110T, the lower two bits set so each bytes contains a column of 4 pixels,
also describe as tiled lower 2 bits. MT2110T has been chosen as a name to match
the vendor chosen name. This format is unlikely to exist for other vendors.
For MT2110R, the 2 low bits are in raster order.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3444>
There is currently no way for applications to know if the stream has
been properly terminated by the server or if the network connection
was disconnected as EOS is sent in both cases.
Adding a property so connection errors can be reported as errors
allowing applications to distinguish between both scenarios.
Fix#2828
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5115>
This new property allows setting of PES stream number for AAC audio
and AVC video streams.
The stream number is subject to the following constraints:
1. it must be between 0 and 15 for video
2. it must be between 0 and 31 for audio
Currently the PES stream number is hard-coded to zero for these
stream types.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4822>
Add support for 10/12/14/16 bit depths . This consists of multiple parts.
First is the parsing of caps, which pulls out the bitness and endianness
from the video/x-bayer format.
Second, gst_bayer2rgb_split_and_upsample_horiz() is split into two similar
functions, one for 8bit bayer handling and another for 16bit bayer handling.
The content is basically identical, except one uses 8bpp and the other 16bpp
inputs and outputs, and they each use different ORC code to match. The 16bpp
variant also handles endian swapping. There is now a wrapper called
gst_bayer2rgb_split_and_upsample_horiz() which selects the correct function
based on bpp from the parser.
Third, gst_bayer2rgb_process() is extended to handle both 8bit and 16bit
bayer data. Yet again there are matching ORC functions to handle the 16bit
data. This time however the 16bit handling of data is slightly special. The
ORC is not able to emit opcodes for 'x2 mergelq', so the trick here is to
store the BG and GR longs into separate 'dtmp' temporary buffer, and then
do one more ORC post-processing step, compensate for the less-than-16bpp
bitness using left shift, and reorder them into the destination frame
using 'mergelq' .
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-bayer,width=512,height=512,format=bggr16le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Example usage:
```
$ gst-launch-1.0 videotestsrc ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
bayer2rgb ! \
video/x-raw,format=RGBA64_LE ! \
videoconvert ! \
autovideosink
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
Add support for conversion to 10/12/14/16 bit bayer pattern.
The implementation is rather simplistic, just take the ARGB
input, generate 16-bit data out of it instead of 8-bit, shift
them as required by the output bitness, and apply endian swap.
Example usage:
```
$ gst-launch-1.0 videotestsrc num-buffers=1 ! \
video/x-raw,width=512,height=512,format=ARGB ! \
rgb2bayer ! \
video/x-bayer,format=bggr12le ! \
filesink location=/tmp/bayer12.raw
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4686>
This patch adds an element to stream video data to an uvc video gadget.
The element handles the uvc events STREAMON, STREAMOFF, SETUP and DATA.
to start, stop and configure the video buffer flow by the use of pad
probes. It works with linux kernels of versions higher than v6.1.
The element makes use of the v4l2sink proxy property v4l2sink::device
to locate the corresponding device to parse the configfs for additional
data.
The code in uvc.c is basically derived from /lib/uvc.c in
https://git.ideasonboard.org/uvc-gadget.git.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1304>
The signal triggers an asynchronous task on the PC thread but in some cases it
can be useful for apps to be notified when the task completed. This method of
the PeerConnection spec also returns a Promise so the interface is now more
coherent with the spec.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3960>
Raw 608 caps can now contain a "field" field. On the input side it
signifies that the input raw 608 is attached to either field 0 or 1,
on the output side it allows selecting whether to extract the raw 608
data for field 0 or 1 for field-aware formats.
In addition, it is also allowed to use ccconverter to "convert" 608
field 0 to 608 field 1 (and conversely), this is passthrough as the
change only needs to happen in the caps.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4031>
Add AVTP Raw Video Format de-payload support. The element supports only
GRAY16_LE output format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
Add AVTP Raw Video Format payload support. The element supports only GRAY16_LE
input format, so:
- active pixels (no vertical blanking),
- progressive mode,
- 8 and 16-bit pixel depth,
- mono pixel format,
- grayscale colorspace.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1335>
If we know there's only one stream we care about and we
don't have to synchronise audio and video, or send RRs,
we might just as well not hook up all the RTCP bits and
use fewer threads and sockets and simplify the pipeline.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3531>
Windows supports various IPC methods but that's completely
different form that of *nix from implementation point of view.
So, instead of adding shared memory functionality to existing
shm plugin, new WIN32 shared memory source/sink elements
are implemented in this commit.
Each videosink (server) and videosrc (client) pair will communicate
using WIN32 named pipe and thus user should configure unique/proper
pipe name to them (e.g., \\.\pipe\MyPipeName).
Once connection is established, videosink will create named shared memory
object per frame and client will be able to consume the object
(i.e., memory mapped file handle) without additional copy operation.
Note that implementations under "protocol" directory are almost
pure C/C++ with WIN32 APIs except for a few defines and debug functions.
So, applications can take only the protocol part so that the application
can send/receive shared-memory object from/to the other end
even if it's not an actual GStreamer element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3441>
The legacy emulation in DRM/KMS drivers badly interact with GStreamer and
may cause the framerate to be halved. With this property, users can disable
vsync (which is handled internally by the emulation) in order to regain the
full framerate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3303>
