Commit graph

13 commits

Author SHA1 Message Date
Philippe Normand
4311de2be0 interaudiosink: Ensure adapters don't store buffers with audio meta
The interaudiosrc might take buffers of different sizes from the audio adapter,
so keeping metas consistency would be an issue. So the sink now strips the audio
metas away and the src adds them back (for non-interleaved layouts only) when
taking buffers from the adapter.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5416>
2023-09-28 15:14:38 +02:00
Alicia Boya García
654ca283a7 qtdemux: Fix premature EOS when some files are played in push mode
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/2771

This EOS branch exists so that if a seek with a stop is made, qtdemux
stops accepting bytes from the sink after the entire requested playback
range is demuxed, as otherwise we could keep download content that is
not being used.

This patch fixes two flaws that were present in that EOS check:

1) A comparison was made between track time and movie time without conversion.
This made the check trigger early in files with edit lists. This patch fixes
this by converting the track PTS to movie PTS (stream time) for the check.

2) To avoid sending a EOS prematurely when the segment stop is within a GOP and
B-frames are present, the check for EOS should only be done for keyframes. I
gather this was already the intention with the existing code, but because it
used `stream->on_keyframe` instead of the local variable `keyframe` the old
code was checking if the *previous* frame was a keyframe.

It's interesting to note that these two flaws in the old code mask each other
in most cases: the track PTS will have reached the movie end PTS, but EOS would
only be sent if the previous frame was a keyframe. A simple case where they
wouldn't mask each other, reproducing the bug, is a sequence of 3 frame GOPs
with structure I-B-P.

The following validateflow tests have been added to future-proof the
fix:

 * validate.test.mp4.qtdemux_ibpibp_non_frag_pull.default
 * validate.test.mp4.qtdemux_ibpibp_non_frag_push.default

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/5114>
2023-08-03 20:22:51 +00:00
Edward Hervey
bf0446ad73 matroska-demux: Properly handle early time-based segments
Refusing an incoming segment in < GST_MATROSKA_READ_STATE_DATA should only be
done if the incoming segment is not in GST_FORMAT_TIME.

In GST_FORMAT_TIME, we are just storing the values and returning, so we can
invert the order of the checks.

Fixes proper segment propagation in matroska/webm DASH use-cases

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4922>
2023-06-23 08:55:47 +02:00
Nicolas Dufresne
49106eab5d h265parse: Don't override upstream framerate
The framerate should only be replaced (and corrected for alternating field)
when it is parsed from the bitstream. Otherwise, the upstream framerate
from caps should be trusted and assumed correct.

Related to gst-plugins-bad!2020

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4352>
2023-06-16 08:18:49 +00:00
Philippe Normand
da02436193 oggdemux: vp8: Detect keyframe packets
decodebin3 drops data on video streams until a keyframe or header is detected,
so for Ogg/VP8 we now need to correctly flag and signal keyframes downstream.
The first buffer pushed from each src pad also has the HEADER flag set.

Fixes playback of
https://github.com/web-platform-tests/wpt/raw/master/media/test.ogv in playbin3.

Fixes #1418

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/4745>
2023-06-01 17:00:44 +00:00
Enrique Ocaña González
be4dc2d05f qtdemux: Don't emit GstSegment correcting start time when in MSE mode
When using qtdemux in a pipeline that should only work as a pure demuxer (not
for actual playback), qtdemux shouldn't emit new GstSegments to correct
the start time (jump to the future) to ensure that the user experiences no
playback delay. By doing so, it's generating the wrong segments when an append
of data from the past happens. When that happens, downstream elements such as
parsers (eg: aacparse) may clip those buffers laying before the GstSegment and
create problems on the GStreamer client app (eg: WebKit).

Getting buffers clipped out because of the wrong GstSegments started becoming
a problen when this commit was introduced:

ab6e49e9cc audioparsers: add back segment clipping to parsers that have lost it

This clipping makes test DASH shaka 35 from MVT tests[1] to fail in
WebKitGTK/WPE (at least) and can potentially cause a number of other problems
in the WebKit Media Source Extensions (MSE) code.

Note that this new behaviour of not emitting new GstSegments only makes sense
when qtdemux is being used as a pure demuxer and not as part of a regular
pipeline. This is why the variant field has been added. When equal to
VARIANT_MSE_BYTESTREAM, it will make qtdemux behave differently in push mode,
taking decisions that meet the expectations for an MSE-like processing mode.
This kind of tweaks have been done in the past for MSS streams, for instance.
That code has been refactored to use VARIANT_MSS_FRAGMENTED now, instead of
its own dedicated boolean flag.

Co-authored by: Alicia Boya García <ntrrgc@gmail.com>

...who suggested to use "variant: mse-bytestream" in the caps to identify that
mode, as proposed in her unmerged patch:

https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/467

[1] https://github.com/rdkcentral/mvt

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3990>
2023-02-18 10:38:30 +00:00
Sebastian Dröge
9c0d9882e3 gst-integration-testsuites: Update cenc_audio_esds_property_overrides expected output file
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3586>
2022-12-17 19:30:51 +02:00
Thibault Saunier
1c1b0380cb dashdemux2: Fix the way we determine current_position after seeks
Without that the current_position was off after seeks, potentially
leading to not properly push a last fragment when a `.stop` time was
set.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3159>
2022-10-27 19:45:44 +00:00
Thibault Saunier
31acfcd875 decodebin3: Do not try to plug a decoder on raw formats
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/3123>
2022-10-06 08:41:49 +00:00
Andoni Morales Alastruey
ffdc8634e8 test: update tests to include the new meta
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1458>
2022-06-03 08:29:05 +00:00
Vivia Nikolaidou
cb8da91f7a h264parse: Include coded-picture-structure info in caps
This reverts commit 652773de36 and
modifies it to rename the caps field name to coded-picture-structure.

It was previously removed because it confuses the decoder and we didn't
have a valid use case for including it in the encoded caps at this
stage. We now do have such a use case but still don't want to confuse
the decoder, so the field is renamed.

However, it is still not accurate without looking at the SEI picture
structure of each frame, so it was named coded-picture-structure. If its
value is "frame" it is most likely progressive, if it's "field" it is
most likely interlaced or mixed.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/2177>
2022-04-18 11:00:29 +00:00
Thibault Saunier
49055f1cd5 rtph264pay: Handle 'profile' field
In order to allow "level-asymmetry-allowed" we now handle a new
"profile" field, which as the same semantics as the "profile" field in
H.264 stream so that we can force payloaded stream to have the right
format when using the `gst_sdp_media_get_caps_from_media` to set caps
filter after the payloader. This allows a simple negotiation in standard
RTP negotiation based on SDPs (like webrtc) for that particular case,
closely respecting the specs.

Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/1410>
2021-12-12 10:59:00 -03:00
Thibault Saunier
098b876985 Import gst-integration-testsuites 2021-09-24 16:29:33 -03:00