When max is GST_CLOCK_TIME_NONE in the query, it should not
be set in the query handler, this otherwise could lead to
impossible situations, where the minimum latency ended up
greater than the maximum.
https://bugzilla.gnome.org/show_bug.cgi?id=796603
The flush function immediately returned when pitch->next_buffer_offset
was 0.
This is clearly wrong, as next_buffer_offset can be 0 when a single
input buffer has been received, and no output buffer has been produced
before receiving EOS.
Simply remove that condition.
https://bugzilla.gnome.org/show_bug.cgi?id=796603
The transform from mediacodec applies to the texture coords, but
GStreamer affine meta applies to the video geometry, which is the
opposite - so invert it to get display correct for decoders
that require transforming
According to msdk spec, there are two ways to enable filters:
1: Filters can be enabled by adding a filter ID
to mfxExtVPPDoUse. In this case, default filter parameters are used
2: Add filter configuration structures directly to mfxVideoParam.
Using 1 with 2 is optional but legal. Unfortunately it won't work
with some specific use cases like Detail/EdgeEnhancement.
Let's stick with option2 which works fine for all VPP operations.
https://bugzilla.gnome.org/show_bug.cgi?id=796468
Since we do the MSDK initializing in set_caps(), a FALSE
return may still cause the invokation of set_caps() again
and this will leads to buffer allocation and other mess-up.
So make sure the msdk initialized correctly before trying
to do any buffer allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=796465
Make sure all the enabled filter structures are added in the
mfxVideoParm before doing the VPPQuery so that msdk
can do the input param validation
https://bugzilla.gnome.org/show_bug.cgi?id=796465
Update the license blurb in camconditionalaccess.[hc] from GPL to LGPL.
The plugin is LGPL and the GPL header in those two files was just a
copy/paste mistake.
It is completely legal to have packets with zero sizes.
Zero-sized packet indicates header with only Start Code.
One eg: is user data packet. The patch allows having
GstMpegVideoPacket with zero sizes.
https://bugzilla.gnome.org/show_bug.cgi?id=796477
Using NV12 layout in dmabuf mode giving mis-aligned
VPP output with the media-driver. Keep the NV12 support
(so that we can file the bug agianst msdk or mediadriver),
but lower the ordering so that BGRA picks as default.
NV12 issue can be reproduced with explicit capfilter:
vidoetestsrc ! msdkvpp ! video/x-raw\(memory:DMABuf\),format=NV12 ! glimagesink
Added a utility method to replace the MemID (interanl VASurfaceID)
associated with the mfxFrameSurface. This is usefull for dmabuf-import
where we need to replace the memID dynamically
https://bugzilla.gnome.org/show_bug.cgi?id=794817
Exporting DRM_PRIME fd to VASurface requires direct
invocation of VA api VACreateSurface with
VASurfaceAttribExternalBufferDescriptor and other
necessary surface attributes.
https://bugzilla.gnome.org/show_bug.cgi?id=794817
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.
