If the following conditions are met:
1) upstream and downstream caps are compatible
2) upstream is interlaced
3) downstream doesn't support progressive mode
then deinterlace will just do passthrough instead of failing to link.
This is done with the following scenario in mind:
videotestsrc ! "video/x-raw,interlace-mode=interleaved" ! deinterlace
name=dein_src ! tee name=t ! queue ! deinterlace name=dein_file ! filesink t. !
queue ! deinterlace name=dein_desktop ! autovideosink
In this case, dein_src will do the deinterlacing. However,
videotestsrc ! "video/x-raw,interlace-mode=interleaved" ! deinterlace
name=dein_src ! tee name=t ! queue ! deinterlace name=dein_file ! filesink t. !
queue ! deinterlace name=dein_desktop ! autovideosink t. ! queue !
"video/x-raw,interlace-mode=interleaved" ! fakesink
In this case, caps auto-negotiation will make dein_file and dein_desktop do
the deinterlacing, while dein_src will be passthrough.
https://bugzilla.gnome.org/show_bug.cgi?id=760995
In this mode we will passthrough all progressive caps but interlaced caps must be
caps where we actually support deinterlacing.
This is the only difference between auto and auto-strict, auto would
passthrough all unsupported interlaced caps.
https://bugzilla.gnome.org/show_bug.cgi?id=720388
Previously the result of the CAPS query and ACCEPT_CAPS depended on what kind
of caps were last set, and e.g. if we last had interlaced caps or not. That's
just broken.
Also previously the handling of non-sysmem caps features was rather random and
unusuable.
Now the behaviour is the following, depending on the mode property:
1) mode=disabled
Completely do passthrough of everything
2) mode=interlaced
Only accept formats we can actually deinterlace, and accept interlaced
and progressive content and always run the deinterlacer and output
progressive content
3) mode=auto (i.e. playbin)
Accept all progressive formats as passthrough, accept all formats that we
can deinterlace ourselves (which we do then), but also accept everything
else for which we then just passthrough. In auto mode, deinterlacing is best
effort: If we can, we deinterlace, if we can't we just output interlaced
content.
https://bugzilla.gnome.org/show_bug.cgi?id=720388https://bugzilla.gnome.org/show_bug.cgi?id=760553
This time, check if it's an RGB format and sets the transformation
matrix to identity. The rest of the colorimetry information is
meaningfull and shall be kept.
https://bugzilla.gnome.org/show_bug.cgi?id=759624
Use the new primaries and transfer function for Adobe RGB.
Explicitly list the colorimetry instead of using the default GStreamer
ones. The defaults for BT2020, for example, do not match.
Explicitly set the matrix of SRGB to RGB.
All code paths for handle_frame() must somehow take ownership of the frame, be
it by actually unreffing, forwarding the frame elsewhere or storing it for
later.
http://bugzilla.gnome.org/show_bug.cgi?id=760666
In file included from gstrtpL16depay.h:27:0,
from gstrtp.c:73:
gstrtpchannels.h:154:33: error: 'channel_orders' defined but not used [-Werror=unused-const-variable]
static const GstRTPChannelOrder channel_orders[] =
Especially in push mode we would completely ignore the size of the data chunk
when not stop position is given for the seek. Instead make sure that the end
offset is at most the end of the data chunk if known.
Without this we would output anything after the data chunk, possibly causing
loud noises if the media file is followed by an INFO chunk or an ID3 tag.
We use that to signal "infinity", taking the difference between that and some
other value is not going to give us any useful result for the end offsets of
segments.
Even if we have more data queued up when flushing than the size of the data
chunk, don't process and output it. If the data size is known, this likely
contains another chunk (e.g. an INFO chunk) or things like ID3 tags. Just
outputting them as if they were data is going to cause unexpected behaviour
and unpleasant audio noises.
The code is supposed to follow somehow what the comment above says, that
is to have one channel with a wave of freq 440 and the other channel
with a wave of freq 880, but an off by one error results in frequencies
of 0 and 440.
https://bugzilla.gnome.org/show_bug.cgi?id=735673
The current example does not work, it fails with:
ERROR: from element /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0: Internal data flow error.
gstwavparse.c(2178): gst_wavparse_loop (): /GstPipeline:pipeline0/GstDecodeBin:decodebin0/GstWavParse:wavparse0:
streaming task paused, reason not-negotiated (-4)
This is because negotiation with wavenc gets messed up by the missing
channel positions configuration.
The proper way to define the channel layout when using the interleave
element in code would be to set the channel-positions property, but
gst-launch-1.0 does not know how to deal with arrays; so the example
pipeline works around the issue by setting the channel-masks in the sink
pads.
Also fix a repetition in the deinterleave example description
https://bugzilla.gnome.org/show_bug.cgi?id=735673
SBC frame length calculation wasn't being rounded up to the nearest byte
(as specified in the A2DP 1.0 specification, section 12.9). This could
cause 'stereo' and 'joint stereo' mode SBC streams to have incorrectly
calculated frame lengths.
Incorrect frame length calculation causes frame coalescing to fail, as
subsequent frames in the stream aren't found in the expected locations.
https://bugzilla.gnome.org/show_bug.cgi?id=742446
The downstream caps query with a filter alraedy gives us the possible
intersection so there is no need to check it again with downstream
if it is supported. Just try to set it directly.
For someone that read the spec is clear the only *invalid*
data block type is 127. For the rest, its useful information.
Additionally. values 7-126 are currently reserved by the
spec so the situation might change in the future.
We are only interested on the first bit of the first
byte of the metadata block header to figure out whether
is marked as the last one. The shift makes it quite
clearer.
If we get anything from 7 to 126 as type when parsing
a metadata block header, we are likely dealing with a
FLAC stream version we don't fully understand. Issue
a warning if so.
Document function assumptions regarding the passed-on
type while at this.
