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
This moves all the conversion related code to a single place, allows
less code-duplication inside compositor and makes the glmixer code less
awkward. It's also the same pattern as used by GstAudioAggregator.
This is only used for caching reasons and should never actually be in
the public API. If this is ever a bottleneck later, caching around a
class private struct could be implemented.
The aggregated_frame is now called prepared_frame and passed to the
prepare_frame and cleanup_frame virtual methods directly. For the
currently queued buffer there is a method on the video aggregator pad
now.
Previously we assumed that the texture ID is going to be valid even
after unmapping the frame, as it was immediately unmapped before even
being used. Now we only unmap once we're done with the texture.
During element shutdown, the srtp encryption session
object can be cleaned up. In that case, return GST_FLOW_FLUSHING
from the chain function. Also properly return GST_FLOW_ERROR
upstream during actual errors.
https://bugzilla.gnome.org/show_bug.cgi?id=790508
Unless we only have sparse streams. In this case we will consider them.
It fixes a bug happening when first observed timestamp comes from a
sparse stream and other streams don't have a valid timestamp, yet. Thus
leading the timestamp from sparse stream to be the start of the
following segment. In this case, if the timestamp is really bigger than
non-sparse stream (audio/video), it will lead the pipeline to clip
samples from the non-parse stream.
https://bugzilla.gnome.org/show_bug.cgi?id=744469
Store a PTS of a highlight event directly into the event structure,
rather than the GST_EVENT_TIMESTAMP that will probably be removed
in GStreamer 2.0, and is hardly used.
https://bugzilla.gnome.org/show_bug.cgi?id=761477
Scene detection determines, how many scenes have changed in a video.
It compared the previous frame with present frame to find out the score and a
threshold is calculated for the same.
I have added an intermediate condition which helps in improving the positive
detections.
https://bugzilla.gnome.org/show_bug.cgi?id=735094
So far msdk produced dmabuf fds are non-mappable.
If user wants to download the content of underlined surfaces,
dmabufcapsfeature negotiated pipeline will fail. So if the input surface
is dmabuf and downstream doesn't have support for dmabuf capsfeatures,
we do the vpp (no passthrough) and produce the mappable videomemory
buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=794946
prpose_allocation:
-- always instantiate a pool for for upstream
-- use async_depth + 1 as min buffer count
decide_allocation:
-- always create a new bufferpool for source pad.
Each of the msdk element has to create it's own mfxsurfacepool
which is an msdk contraint. For eg: Each Msdk component (vpp, dec and
enc)
will invoke the external Frame allocator for video-memory usage
So sharing the pool between gst-msdk elements might not be a good idea.
https://bugzilla.gnome.org/show_bug.cgi?id=793705
We were assuming that NULL pool meant that downstream didn't reply.
Update the pool index 0 instead of adding at the end. Otherwise we ended
up letting basesrc decide, which would pick the blocksize as a size
(4096) instead of the image size.
https://bugzilla.gnome.org/show_bug.cgi?id=795327
This server uses an unknown 003.889 protocol version. This patch fixes
the version validation in order to simply fallback to 3.3 as suggested
by the spec.
