Similar to qtdemux.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
In particular the Yaw value seems to get ignored by many clients.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8319>
Similar to qtmux, but for mkv and webm containers.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
In particular the Yaw value seems to get ignored by many clients.
Can be tested with:
```
gst-launch-1.0 \
videotestsrc num-buffers=90 ! \
taginject tags="image-orientation=rotate-270" ! \
capsfilter caps=video/x-raw,width=640,height=480,max-framerate=30/1 ! \
videoconvert ! \
queue ! \
vp8enc ! \
queue ! \
webmmux ! \
filesink location=./test.webm
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8319>
Sometimes the seek to the end of file to determine the duration would trigger a
reset of the source pads, that would confuse the decoder downstream and trigger
an error. So the proposed fix is to not reset pads when the segment event being
processed is the consequence of a seek performed to determine the duration.
Fixes#4212
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/937>
The videotestsrc is not build if the adder plugin is disabled. This is a
copy/paste error introduced in Commit 3de86b2b9725 ("docs: port plugins to
explicit sources").
Fix the check to actually test the 'videotestsrc' option.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8399>
For outputs with a high number of channels, macOS has a bug where
initially CoreAudio will report incorrect positions for all channels,
but after you run Audio MIDI Setup and configure the speaker layout
there, macOS will always report those few as positioned, with no option
to revert that (other than deleting some internal files).
In such scenario our code would just ignore all the unpositioned
channels. Since you can only position max. 16 channels in macOS, if you
had more on your output device, those would be unusable.
This commit makes sure that in addition to the usual positioned layout
(if there is one), we will expose caps for a no-positions layout that
always has the maximum amount of channels available.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8311>
By default, for devices with larger amounts of outputs, CoreAudio can
provide invalid channel labels/positions, simply by starting at 0 and
incrementing forward. For example, values 19 through 32 are not valid
according to the CoreAudioBaseTypes.h header, but if your device has >19
output channels, you will find CoreAudio using those values.
This is most likely a bug in CoreAudio, since in that case it should use
unpositioned labels (e.g. _Discrete_X) instead.
This commit aims to work around this by overriding all channels to be
unpositioned if the case above is detected.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8311>
After a bit of back and forth, we figure-out that for backward
compatibility we need to set the tile stride the way GStreamer
defines it. Sinks such as glimagesink/waylandsink translate it
back to the number of bytes representation used by Linux.
The change in !7355 when the other way around, breaking tiled
playback through waylandsink and glimagesink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7892>
Mirroring the demux element and isomp4mux from gst-plugins-rs.
Tested against other Gst elements and MPV. Note that the later
apparently does not show correct results for flipped values.
Can be tested with:
```
gst-launch-1.0 \
videotestsrc num-buffers=90 ! \
taginject tags="image-orientation=rotate-90" ! \
capsfilter caps=video/x-raw,width=640,height=480,max-framerate=30/1 ! \
videoconvert ! \
queue ! \
openh264enc ! \
queue ! \
h264parse ! \
mp4mux ! \
filesink location=./test.mp4
```
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8371>
There is no requirement for a base DRM format to be supported by libgstvideo
in order to be uploaded to.
The linux-dmabuf-v1 format events are DRM_FORMAT codes and don't need to
be converted before use with `gst_video_dma_drm_fourcc_to_string`.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8279>
Most settings are copied from properties on the READY → PAUSED state
change. The recently added properties violate this scheme, and are
probably unsafe to change.
Make these properties consistently MUTABLE_READY. Also remove the unused
`output_padding` field.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/7996>
After calculating a correct duration the oggdemux in some cases sets the duration to GST_CLOCK_TIME_NONE.
After that any seek will fail due to the oggdemux calculating a target time after the actual duration.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8296>
The documentation was incorrectly referring to `GST_QUERY` and `GST_BIN`
as GstDebug category names. These two don't follow the pattern of the
rest, and instead are named `query` and `bin` respectively.
This can be verified from the source code of the _do_init macro in the
same gstlog.c file, and from gstbin.c and gstquery.c calls to
GST_DEBUG_CATEGORY_INIT().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8365>
The third argument of the pad-chain-pre and pad-chain-post hooks are of type GstBuffer* and GstBufferList* respectively.
However, when I added do_chain_buffer_pre() and do_chain_buffer_post()
to gstlog.c I accidentally make them take GstFlowReturn -- almost
certainly as an artifact from duplicating the code of the _post()
variants, leading to erroneous log lines like this:
```
do_chain_buffer_pre:<vp9parse0:sink> 0:00:01.615378540, pad=<vp9parse0:sink>, res=-1073639680
```
This patch fixes that.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/8366>
