gst_video_decoder_negotiate_default_caps() is meant to pick a default output
format when we need one earlier because of an incoming GAP.
It tries to use the input caps as a base if available and fallback to a default
format (I420 1280x720@30) for the missing fields.
But the framerate and pixel-aspect were not explicitly passed to
gst_video_decoder_set_output_state() which is solely relying on the input format
as reference to get the framerate anx pixel-aspect-ratio.
So there is no need to manually handling those two fields as
gst_video_decoder_set_output_state() will already use the ones from
upstream if available, and they will be ignored anyway if there are not.
This also prevent confusing debugging output where we claim to use a
specific framerate while actually none was set.
The start_time and end_time in this context have already
been adjusted for the input's rate by converting them to running
time above. What is needed afterwards is to compare these
with the output's start/stop running time, which also takes
into account the rate, so we are comparing equal things.
Multiplying these with the output's rate here is only breaking
this logic. In most cases the input and output rate is the same,
so this multiplication effectively reverses the rate adjustment
that happened while converting to running time, which is why
we see the video playing with the original rate in tests.
Fixes#541
We make an allocator for temporary lines and then use this for all
the steps in the conversion that can do in-place processing.
Keep track of the number of lines each step needs and use this to
allocate the right number of lines.
Previously we would not always allocate enough lines and we would
end up with conversion errors as lines would be reused prematurely.
Fixes#350
It breaks all the calculations. While it can make sense during
initialization, there's very little API that can be called with such
timecodes without ending up with wrong results.
The old API would only assert or return an invalid timecode, the new API
returns a boolean or NULL. We can't change the existing API
unfortunately but can at least deprecate it.
CEA608_IN_CEA708_RAW is the same format as CEA708_RAW. It's only
difference is that it must contain only CEA608 and a format like this
does not exist in practice. In practice every element that handles raw
cc_data triplets must check each triplet for their actual content and
handle them accordingly.
For CC-only streams a parser could signal the existence of CEA608 and/or
CEA708 inside the caps but for metas this can only potentially be
signalled via the ALLOCATION query for negotiation purposes.
A separate format for this is not very useful and instead it should be a
format qualifier.
CEA608_S334_1A is the format defined by SMPTE S334-1 Annex A and which
is used for transferring CEA608 over SDI instead of CEA708 CDP packets.
Pull in video frame fields into local variables. Without this the
compiler must assume that they could've changed on every use and read
them from memory again.
This reduces the inner loop from 6 memory reads per pixels to 4, and the
number of writes stays at 3.
If we use the main loop it might happen that the caller (e.g. our unit
test) already shut down the loop once the result was received and in
that case the pipeline would never ever be shut down (and our unit test
would hang).
While this creates a circular reference between the pipeline and the
context, this ensures that the context stays alive for as long as any
callbacks could be called on it. The circular reference is broken once
the conversion is finished (or error, or timeout), which will then cause
everything to be freed.
Previously it was possible that a callback could be called on the
context right after it was freed already.
Also use only a single context structure, the second structure does not
simplify anything and duplicates storage.
The Y210 format was added in the middle of the formats enum and list,
introducing an ABI break.
This issue was detected thanks to the gstreamer-rs test harness.
We assume here the same data format for the user data as for the
DID/SDID: 10 bits with parity in the upper 2 bits. In theory some
standards could define this differently and even have full 10 bits of
user data but there does not seem to be a single such standard after
all these years.
