This lets users call gst_pad_get_current_caps on newly-added
pads to easily determine what to plug them into.
We cannot copy sticky events unconditionally in core,
see #719437https://bugzilla.gnome.org/show_bug.cgi?id=796387
If connection-speed property is in use, this value should be used as the
current download rate since subclasses might read it to figure out
which playlist variant they will use.
https://bugzilla.gnome.org/show_bug.cgi?id=784592
This new element allows decoding and overlaying CEA-708 Closed Caption
streams over video.
* Supports CDP and cc_data closedcaption/x-cea-708 streams
* Uses pango to render CC stream
* Support GstVideoOverlayComposition meta if downstream supports is
Tested on various test files.
Remains to be fixed/improved:
* Switch to GstByteReader (for code safety)
* Switch to GString (instead of manual pango string construction)
* Move pango/rendering code outside of main 708 decoder file (so
that actual CC parser/decoder can be (re)used in other scenarios).
Initial patches and improvements by:
* CableLabs RUIH-RI Team <ruihri@cablelabs.com>
* Steve Maynard <steve@secondstryke.com>
* cjun.wang" <cjun.wang@samsung.com>
https://bugzilla.gnome.org/show_bug.cgi?id=704881
zvbi switched to a lot more flexible CC detection in VBI.
The problem is that it returns a *lot* of non-VBI lines as containing
CC which isn't the case.
Current code from zapping/zvbi as of 2018-03-14. Files copied
are all LGPL v2+.
Changes from original zvbi code:
* Switch to gst-debug logging system
* Use glib for endianness detection
* Fix compilation warnings
Allows extracting GstVideoCaptionMeta from a stream and outputs
it to a standalone stream.
Part of a new 'ext' closedcaption plugin, since more features are
going to be added, which will depend on external dependencies such
as pango.
On debian system headers trigger compiler warnings like these,
don't error out on them:
/usr/include/directfb/direct/os/linux/glibc/waitqueue.h:95:1: note: previous definition of ‘direct_waitqueue_signal’ was here
In case the wasapi buffer levels got low in shared mode we would still wait until
more buffer is available until writing something in it, which means we could never
catch up and recover.
Instead only wait for a new buffer in case the existing one is full and always write
what we can. Also don't loop until all data is written since the base class can handle
that for us and under normal circumstances this doesn't happen anyway.
This only works in shared mode, as in exclusive mode we have to exactly
fill the buffer and always have to wait first.
This fixes noisy (buffer underrun) playback with the wasapisink under load.
https://bugzilla.gnome.org/show_bug.cgi?id=796354
The calculation for the frame count in the non-aligned case resulted in
a one too low buffer frame count.
This resulted in:
1) exclusive mode not working as the frame count has to match
exactly there.
2) Buffer underruns in shared mode as the current write() code doesn't
handle catching up to low buffer levels (fixed in the next commit)
To fix just use the wasapi API to get the buffer size which will always
be correct.
https://bugzilla.gnome.org/show_bug.cgi?id=796354
S_FALSE is a valid return value which does not indicate an error.
For example IAudioClient_Stop() returns S_FALSE when it is already stopped.
Use the FAILED macro instead which just checks if an error occured or not.
This fixes spurious warnings when using the wasapisink element.
https://bugzilla.gnome.org/show_bug.cgi?id=796280
This is a new warning introduced by gcc 8
We already check just before that we have enough space, just do a regular
memcpy with the full string size.
camswclient.c:87:3: error: ‘strncpy’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
'cuDeviceComputeCapability' was deprecated as of CUDA 5.0
gstnvenc.c: In function ‘gst_nvenc_create_cuda_context’:
gstnvenc.c:290:9: error: ‘cuDeviceComputeCapability’ is deprecated [-Werror=deprecated-declarations]
&& cuDeviceComputeCapability (&maj, &min, cdev) == CUDA_SUCCESS) {
^
https://bugzilla.gnome.org/show_bug.cgi?id=796203
Regardless of LIVE or VOD, "a manifest has next period but
currently EOSed" state is meaning that it's time to advance period.
Previous behavior of adpativedemux, however, was able to period
advancing only for VOD case, since the adaptivedemux tried to
update and wait new manifest without respecting existence of the next period.
https://bugzilla.gnome.org/show_bug.cgi?id=781183
Explicitly cast to void* because GCC 8 is (rightfully) upset that this is
"writing to an object of type ‘...’ with no trivial copy-assignment".
Caused by the new "class-memaccess" warning
The new property "output-order" can be set to either "display" order
which is the default where frames will be outputting in display order,
or "decoded-order" which will be outputting the frames in decoded order.
The "decoded order" output is generally useful for debugging. But there
are few
customers who use it for low-latency streaming. For eg if the customer
already knows that the stream doesn't have b-frames (which means no
algorithm requires for display order calculation), then they can use
"decoded-order"
output to skip some of the DPB logic to avoid the frame accumulation at
start-up.
The root cause of the above issue is a bit of unclarity in h264 spec +
lazy implementation of many H264 encoders; This is well handled in
gstreamer-vaapi using "low-latency" property:
https://bugzilla.gnome.org/show_bug.cgi?id=762509https://bugzilla.gnome.org/show_bug.cgi?id=795783
For packetized input, inform the msdk that the buffer has
a complete frame or complementary field pairs. For decoding,
this means that the decoder can proceed with this buffer without
waiting for the start of the next frame, which effectively reduces
decoding latency.
https://bugzilla.gnome.org/show_bug.cgi?id=795783
Currently we use an async depth of 4 as default (based on
recommendations
in msdk apps), which indicates how many asynchronous operations an
application performs
before the application explicitly synchronizes the result. As a result,
we
queue four frames in decoder which might not be good approach for
live streaming.
This patch reset the async-depth to 1 as default so that we do sync for
each frame we decode without queuing. Customer can play with already
exposed "async-depth" property for other use cases
https://bugzilla.gnome.org/show_bug.cgi?id=795783
