boolean return value is not sufficient for representing the reason
of error in most cases. For instance, any errors around new_sequence()
would mean negotiation error, not just *ERROR*.
And some subclasses will allocate buffer/memory/surface on new_picture()
but it could be failed because of expected error, likely flushing
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2528>
Theoretically the version number is incremented every time there's a new
section, but in a world of streaming we can't easily make that
assumption.
An example of a broken use case is when we're cat-ing two mpeg-ts files
together, which is equivalent of capturing a DVB stream while switching
channels. A set-top box would know that we switched the channels and
reset the demuxer, but in practice this might not happen.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2468>
Initially we tried to use the internal color conversion used in i965
and Gallium drivers when decoding. But this approach has showed
limitations and problems.
This patch removes completely the possible color conversion at
decoding, since it show problems with deinterlacing, for example:
gst-launch-1.0 filesrc location=interlaced.mpg2 ! parsebin ! vampeg2dec ! vadeinterlace ! xvimagesink
Allowing only the surface formats when decoding is more stable.
For color conversion is better to do it explicitly with vapostproc.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2531>
Our code does not support rendering twice the same wl_buffer in a row, so it
tries to skip that case, but for this it relied on the GstBuffer pointer,
while the cache actually works at the GstMemory level now. To avoid this
compare the GstWlBuffer instead.
This fixes crash when use in zero-copy with videorate element.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2526>
Latency setting relies on src pad caps, but they aren't set when the
function is called, and latency is never updated.
In order to fix it, this patch uses TSG framerate first, and if it's
not set yet, sinkpad caps are used to get the framerate.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2514>
... and various code cleanup.
* Move spreaded decoding API calls into one method
Previously, decoding flow of most codecs are
- Call DecoderBeginFrame() on start_picture()
- Call {Get,Release}DecoderBuffer() on decode_slice()
- Call SubmitDecoderBuffers() and DecoderEndFrame() on end_picture()
Such spreaded API calls make it hard to keep track of status
of decoding. Now it will be done at once in a new method.
* Drop a code for non-zero wBadSliceChopping
When bitstream buffer provided by driver is not sufficient
to write compressed bitstream data, host decoder needs to make use
of wBadSliceChopping so that driver can understand there are
multiple bitstream buffer. But it's a bit unrealistic and
not tested. Since FFMpeg's DXVA implemetaion doesn't support it,
we might be able to ignore the case for now.
* Make code more portable
Consider common logic of GstCodecs -> DXVA translation for all D3D APIs
(i,e., D3D9, D3D11, and D3D12).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2525>
Skip the closedcaption element tests if the
closedcaption option is disabled at compile
time (i.e. -Dclosedcaption=disabled).
v2: rename pangocairo_dep to avoid conflict
with later definition in ext/ttml/meson.build
as suggested by @tpm.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1388>
The max_num_reorder_frames number can change the way we bumping the
pictures in the DPB. The smaller it is, the lower latency we will
get. So it is important for live mode streams, but it is not given
in VUI parameters sometimes. We now improve the policy to infer it:
1. Never guess it in the "strict" compliance.
2. For baseline and constrained baseline profiles, which do not have
B frames, set it to 0.
3. For -intra only profiles, set it to 0.
4. Otherwise, not guess it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2501>
In ext/aes/meson.build, the aes_dep will return
not-found if -Daes=disabled, regardless of whether
openssl is found or not. Thus, we don't need a
separate check for the option. This will also
ensure that aes_dep is always defined and we can
use it in the tests/check/meson.build unit.
Fixes#1660
v2: handle -Daes=disabled, too.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2522>
AAC codec_data is a just collection of AAC profile, samplerate, and
channels. We can know samplerate and channels from parsed
SampleEntry data. Although the AAC profile is unknown there,
let's assume it as AAC-LC like we've been doing for the version 1
atom.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/1082>
.. when computing the high id.
After a flush for instance, sq->srcresult is reset to OK,
yet it doesn't make sense to pick a non-existing position
id as the high id when a queue doesn't contain any items
in that situation either.
It is in any case completely OK to let the not-linked stream
get consumed without throttling at this stage, as any
first packet arriving on other single queues will get assigned
a higher position id.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/885>
In the h264, the Baseline profile is widely misused. A lot of streams declare
that they are the Baseline, but in fact they just conform to ConstrainedBaseline.
The features such as FMO and ASO are not used at all.
If the decoder does not strictly conforms to the SPEC, we can just use Baseline
or Main profile to decode it to avoid lots of streams failure.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/2428>
